Loading...

Follow VersionOne Agile & DevOps Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

We have been spending some time on the blog these past few weeks interviewing some of the “greats” of agile — people who have shaped the agile movement with their ideas and leadership. Hearing from these agile coaches, teachers, speakers and authors helps reveal where the industry is headed next, and has shed light on the value of the findings of the State of Agile Report, put on by VersionOne annually.

Today CollabNet VersionOne shares Q&A with Scott Ambler, agile coach and one of the developers of the Disciplined Agile Delivery (DAD or DA) framework. Scott shares some of the reasons DA has caught on (the State of Agile Report saw an increase in DA users from 1 to 5 percent in the last year). He also discusses misperceptions about agile and makes a prediction for next year’s report.

Here’s the full interview:

Question: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Scott: I would agree with that. Being able to safely react to change is key into today’s marketplace. Traditional strategies just don’t get the job done any more.

Question: What is the greatest misperception about the agile methodology?

Scott: That would be a very long list. I think that the biggest misperception is that Scrum is sufficient for agility. Anyone who says that they’re doing Scrum doesn’t really know what they’re talking about, because to make Scrum work they would also have to have adopted strategies from XP, Agile Modeling, RUP, and many other sources. They’re very likely doing something much closer to Discipline Agile Delivery (DAD) than Scrum, but sadly don’t realize it due to all the marketing rhetoric around Scrum.

Question: The 12th Annual State of Agile report highlights that the use of Disciplined Agile (DA) has grown from 1% last year to 5% this year, why the increase?

Scott: As organizations continue to adopt agile across a wider range of situations, particularly in the enterprise space, they’re starting to discover that they need something a bit more robust than the agile strategies that are geared for simpler situations. DA has done a lot of the heavy lifting when it comes to figuring out how to apply agile in the enterprise, and as people start to realize that they’ve hit the limits of Scrum, they start looking around for something a bit more comprehensive.

Question: If you had to make one prediction for next year’s State of Agile report, what do you guess the new findings will reveal about where agile is going?

Scott: I think you’ll see that DA adoption continues to rise. DA already addresses a lot of the issues that organizations are struggling with, such as, how does architecture fit in? how do you govern agile teams effectively? how do you address regulatory compliance? and many other issues. You can figure out all these things on your own or you can adopt DA and get a very big leg up.

Question: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Scott: You need both. Grassroots adoption on its own hits a glass ceiling pretty quickly. Similarly, a top-down approach on its own is pretty much guaranteed to be ignored by the people in the trenches. You need a combined approach where the team-level issues are addressed as well as the organization-level issues.

Question: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Waterfall works well in very straightforward, well-defined spaces. For example, if you were to do an infrastructure upgrade (say moving from Windows 7 to Windows 10) then traditional works fine.

Thank you Scott for providing these insights!

Please check out the previous two posts in this series:

“Q&A with Scaled Agile Expert Dean Leffingwell” and “Sanji Augustine Discusses Business Agility, High-Performing Teams and Opportunities in China and Africa”

The post Q&A with Creator of Disciplined Agile Delivery (DA), Scott Ambler appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

CollabNet VersionOne has been interviewing some of the agile movement’s greatest leaders. The publication of the State of Agile Report each year gets us thinking about the adoption of agile, which organizations are using it and how they are applying the methodology. The survey looks into why folks are using agile and how it is helping teams develop better software at speed.

Last time we spoke with Dean Leffingwell from Scaled Agile.

This week, we’ve posed many of the same questions to Sanjiv Augustine, president of LitheSpeed and author of Managing Agile Projects and Scaling Agile: a Lean Jumpstart.  Sanjiv shares anecdotes from his experience as a global consultant and provides a fresh perspective on some agile clichés such as the Scrum standup meeting.

Let’s see what he has to say:

Question: How did you first learn about agile and what about the practice appealed to you initially?

Sanjiv: I learned about agile methods in the year 2000. My then boss needed someone to manage eXtreme Programming (XP) teams, and hired me to align management with XP. The practice that made immediate sense was timeboxed iterations (Sprints in Scrum). I saw the power of timeboxing to drive throughput and delivery, and still believe short timeboxes are one of the best practices in agile methods.

Question: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Sanjiv: One of the greatest benefits is to break up the log jam caused by waterfall and siloed organizations. When you break that log jam, value is delivered faster, and organizational silos will no longer stand in the way of bringing value to customers. Certainly managing the changing priorities is a benefit, but more of a secondary benefit and an outcomes of this structural change. Establishing this end-to-end value stream with our customers drives true business agility.

Question: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Sanjiv: It’s really not an either/or, the best success comes when you have both grassroots and top-down movement. The top down approach implies ‘thou shalt do xyz …,” and that’s not the best way. The best transformations happen when management can say, we want to help you, provide what you need to make this happen. Management and executives must commit to the process of course, but team members also need to have it in their hearts and minds to adopt agile methods. Thus, there must be team momentum as well.

So, the best-case scenario happens when you combine team momentum with top executive buy in, that way all pieces are working together – the commitment and air cover as well as the enablement.

Question: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Sanjiv: I don’t think of agile methods as a single thing. The truth is, any agile method can be teased apart into a number of different practices and it is possible to apply certain agile practices without others.

For example, agile teams are cross-functional and high performing. You can create this with physical meetings where team members share a location or you can use tools like Slack, video conferencing or IM. This team aspect is important for Scrum. Applying this high-performance team discipline is possible even if you have a waterfall process. For example, we’ve worked with Capital One in the past, and their waterfall teams apply many Scrum practices. You can walk into a waterfall team space and find they are doing similar practices as agile teams — whiteboards and all. It’s just that the delivery process and timeline is different.

That said, agile processes are not a good fit when you don’t have good buy in from the business. For instance, to practice Scrum, SAFe, or Scrum at Scale requires business involvement with an involved sponsor. So, in those instances waterfall might make more sense.

Question: The 12th Annual State of Agile report revealed that in organizations with some teams practicing agile, those teams represent less than half of the organization’s teams in total. What does this say about the spread of Agile across the enterprise?

Sanjiv: That says we’ve got a long way to go. Waterfall has been around since 1974, and agile has really only taken off in the last 10 years, so there’s something DevOps identifies as “Conway’s law,” which means our process and organizations mirror each other.

As we’ve been using waterfall for 50 years, we’ve built up governance, portfolio management, funding, etc. These are ancillary functions that are waterfall in nature.

Until we start aligning those to agile teams, it’s no surprise the organization itself is not all agile. When those start to be agile the enterprise can be agile, until then we have a long way to go.

Question: In the 12th State of Agile Report, 90 percent of respondents indicated they participate in a daily stand-up meeting at their organization. Why are standup meetings valuable for software teams?

Sanjiv: Let me give a comparison from agile history.

Before Scrum became popular, 18 years ago, eXtreme Programming (XP) was all the rage. However, the first thing people thought of when XP came to mind was folks sitting together and pair programming.  This was the most visible and tactical part of the XP methodology, so it was easily recognizable. A lot of XP magic happens behind the scenes and isn’t immediately obvious, but what is obvious is two people sitting together, so if you don’t know anything else that is your first assumption. For many, XP was simply, “pair programming.”

With Scrum you have a product backlog as well as specific roles for the Product Owner, ScrumMaster and Development Team. The Scaled Agile Framework (SAFe) add the Release Train Engineer (RTE) role, and Scrum at Scale has sophisticated structures like the Meta Scrum. However to the casual observer, they look at Scrum and see a team standing in a circle – it’s simply the most visible practice.  Therefore, Scrum has largely become associated with a standup meeting. They associate the mechanics of standing in a circle with better process for software development.

So, I absolutely encourage it as a practice though because it’s so simple and straightforward. In 15 minutes or less, you can break down barriers to communication, face to face. However, I also strongly encourage everyone to go well beyond the Daily Standup “cult of practice” and truly implement other agile practices with true agile values in mind.

Question: Any additional comments you’d like to make on the findings of the 12th Annual State of Agile Report?

Sanjiv: I find it interesting that most of these responses were taken in North America. As you look at the places in the world with under 10 percent responses provided on this survey, I believe those are opportunities for growth. I know there’s a strong level of agile adoption right now in Australia and Brazil. And there’s a huge opportunity in South America. We also see strong growing adoption in India and China.

The primary opportunities, however, in my estimation, exist in China and Africa. For instance, there are approximately 250 Scrum trainers worldwide, and the majority are based in North America and Europe. I think there are only 3 based in China, and only one based in Africa.

Thank you Sanjiv for taking the time to answer these questions and provide our readers with some food for thought. Cheers!

The post Sanjiv Augustine Discusses Business Agility, High-Performing Teams and Opportunities in China and Africa appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

For years VersionOne has taken its role seriously in furthering agile research for the betterment of the software development industry. The State of Agile Report is one great example. For 12 years straight we’ve surveyed practitioners, IT leaders, executives and everyone in between to find out who is using agile, how they are using it and why. This is just one way the company has historically contributed to the software development community.

In order to deliver products or services that will truly benefit our customers, we have to do a lot of listening. We listen to customers and non-customers alike. We want to know, what are the challenges of software teams? Where is agile bringing benefit and where is it falling short?

One of the best ways to learn, however, is to talk to the experts. Talking to leaders within the agile community who have changed the industry landscape through inspiring thoughts, helpful innovations or challenging the status quo is incredibly worthwhile.

CollabNet VersionOne recently had a conversation with Dean Leffingwell, SAFe (Scaled Agile Framework) creator and chief methodologist, at Scaled Agile Inc. CollabNet VersionOne platforms are designed with SAFe in mind because we have seen how many enterprises achieve success using this methodology.

Let’s hear Dean’s thoughts on some of the State of Agile Report findings, learn more about his experience joining the agile movement and ask some questions about what’s important for our industry.

Question: How did you first learn about agile and what about the practice appealed to you initially?

Dean: “I first learned of Scrum and XP in the late nineties. But I was working with large enterprises, those with 200-500 or even thousands of developers. I saw how XP and Scrum worked well for small teams, but it didn’t seem like something for me because I was dealing with really big teams building really big systems. So it didn’t influence my thinking much at that time.

Later, from 2001 and on, I began advising startups and spent time learning Agile staring with XP. Frankly, I was blown away by the discipline and code quality that resulted from XP practices. I was tipped. I also attended a ScrumMaster class and was impressed by the simple Scrum paradigm and the roles of Product owner and Scrum Master. At that time there was a quite a method war between the two, but I saw them as being optimized for different things, the yin and yang, if you will, of team agility. So I adopted both methods and built a hybrid process that I used to coach a number of software startups. The results were truly amazing. It was the biggest improvement in the software development I’d ever seen. I was convinced there was only one way to develop software from them on, and I have been an Agile champion ever since.

Looking back now, there was a time when Agile seemed so new. But by now, I’ve been using it for almost half of a 40-year career. We use SAFe here at Scaled Agile, Inc., and of course the framework team operates as an Agile Team. Now my personal mission is to allow people in larger enterprises to reap the benefits of these Agile methods, so the power of the methods is not relegated solely to just small companies and small teams.”

Q: The 12th Annual State of Agile report reveals that 29 percent of respondents use the Scaled Agile Framework (SAFe) and it is the most popular scaling method used. Why is this method continuing to grow in popularity?

Dean: “The simple answer is, it produces outstanding business benefits. We have more than 40 published case studies on the Scaled Agile Framework website and another 40 or so public references to what companies have achieved with SAFe. The results these companies achieved are unbelievable.

There are records of significant productivity gains, quality improving by 3 or 4 times, time-to-market increased by 70 or 80 percent, and most importantly, people enjoying their jobs more. They report much higher levels of employee engagement. SAFe is basically Agile on steroids with a lean substrate, but as applied to large enterprises. Business get outstanding benefits from SAFe.

Also, Scaled Agile Inc, which owns SAFe, is a rock solid company. We have an outstanding entrepreneurial team, experienced executives, the leading framework, professionals in learning development, and certification, very effective sales and marketing, over 175 worldwide service and tooling partners, etc. We have a community platform that supports hundreds of thousands of users, a customer success team with a less than 24 hr. response time to questions. And we have the development and support infrastructure necessary to implement and share the framework globally. We are in a strong cultural, thought leadership, distribution and financial position.

Success scales. SAFe is generally not an approach that managers ‘need to be talked into’, they see the benefits and decide for themselves if the efforts is worthwhile. Usually the answer is yes.”

Q: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Dean: “I think that managing changing priorities is certainly one, but the collected benefits of creating a persistent way of working, lean thinking and relentless improvement, are important too. Agile isn’t a state of being, it’s a journey that can always be improved.”

Q: If you had to make one prediction for next year’s State of Agile report, what do you guess the new findings will reveal about where agile is going?

Dean: “The trends will likely continue. That’s why they are trends. But one of the things that the State of Agile report doesn’t cover extensively enough is DevOps. DevOps is different from agile, as it’s focused more on code to cash than concept to code. But it’s part of the continuum.

Agile is mostly about the front end of the product lifecycle and DevOps takes the industry further down the lifecycle. These two communities — agile and DevOps — see things very similarly. These movements need each other. You’ll see that folks scaling agile need DevOps to support rapid release of new value. And those heading down a DevOps path will say, ‘We can’t do it without agile development delivering smaller batches just-in-time.’

I’d anticipate that these trends will continue to show that these worlds are converging. Agile has always been mostly about ‘development’ which helps on the front end. But we haven’t yet optimized the full continuous flow of value. To get releases out quicker, agile and DevOps must be married in the middle. And as SAFe integrates DevOps and agile, I’m also confident that SAFe will maintain its leadership position. ”

Q: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Dean: “I think that misses the larger piece of the puzzle. In an enterprise, what C-level executive doesn’t want faster time-to-market or the ability to respond faster to market needs? Will the CEO believe Lean and agile are good? ‘Yes and can I get ice cream with that?’ So I’d say it’s relatively easy for a CEO to get on board. Executives get it.

Then, at the ground level where the work is done, what developer doesn’t want to be on an agile team? Most do because this means getting their voice heard and getting the psychic reward for doing the right work in the right way, with a minimum of nonproductive overhead. And seeing their work solve real problems for real users quickly and expeditiously. So there’s usually very little resistance in the executive suite or at the practitioner level.

The challenge can be in the middle. Only these managers and leaders can change the systems which control the way the work is performed. It turns out that they, not the executive or the developer, hold the keys to the kingdom. And in the larger enterprise, there are a lot of them and they are talented and largely responsible for the success that’s been achieved to date. It’s hard to argue with what they have achieved with the existing way of working.

But there is a new, and better way of working available. At Scaled Agile, we always start by getting in front of these people, to show them a new way of working and to directly address the pockets of resistance that can be there. We teach these leaders first so they can teach others. These are the champions we really need to effect change.“

Q: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Dean: “I haven’t found them. I just don’t know of any material initiative where, we’d really like to wait until the very end to find out how I’m doing. The scientific method says, ‘I don’t know the answer, I need to find out with a series of small experiments.’ Perhaps it’s the thrill of leaving all the risk to the end of the program that still drives waterfall: ‘I can hardly wait for that surprise!

But there’s just no way you can begin knowing everything 100 percent up front. Considering the business case up front is important, but Waterfall, for example, starts with the assumption that the requirements can be known fully up front. But if that were truly the case, then the system’s already been built.

It just doesn’t make sense when we build systems of complexity. Waterfall got us where we are, so it is not by any means a stupid process. But we’ve learned better ways.”

Q: In the 12th State of Agile Report, 90 percent of respondents indicated they participate in a daily stand-up meeting at their organization. Why are standup meetings valuable for software teams?

Dean: “Simply, programmatic communication and collaboration. And it’s not just for software teams. At Scaled Agile, our teams are spread out throughout a 27,000 square foot building — plus we have folks on the road, and we have people around the globe. But if you walk around our building between 8:30 and about 11 AM, you’ll see most every team doing a daily standup.

Now honestly however, if your teams are distributed you’ve got to have some work-arounds. For the framework team, because of our distribution, travel, and classroom training and consulting schedules, we do not have a daily stand up. But we try to make up for that by running one week iterations inside our two week company sprint cycle. But we are thinking about starting one. In any case, the point is you have to have steady, routine communication.”

Thanks so much Dean for taking the time to chat!

If you’d like to learn more about SAFe from Dean, check out this webinar, “Driving Innovation in the Enterprise with Lean Thinking and SAFe.” In this webinar, Dean Leffingwell illustrates how seemingly disparate practices — like Agile, Scaled Agile, Lean Startup, Lean UX, DevOps and Continuously Delivery — need not be separate initiatives, but rather a continuum that helps enterprises deliver more innovative solutions at a velocity they could only imagine before.

The post Agile Q&A with Scaled Agile Expert Dean Leffingwell appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Another amazing installment of DevOps Enterprise Summit London (DOES18) is in the books! As a proud sponsor of the event for the past three years, we feel confident in saying that this was the best year yet. It was our first time at DOES London as a combined company – CollabNet VersionOne – and we were excited to announce our newest solution, CollabNet Enterprise Value Stream Management (EVSM). CollabNet EVSM combines our Agile, Enterprise Version Control and DevOps Continuous Delivery platforms to help visualize, measure and optimize delivery pipelines and value streams across the entire application lifecycle, giving customers the ability to make their Agile-plus-DevOps environments into realized digital business drivers. We could not have thought of a better venue to announce CollabNet EVSM and were very pleased with the activity and interest we saw at our booth.

Of course, this is not to overshadow the incredible programming put on by Gene Kim and IT Revolution. Almost 1,000 attendees, including ourselves, enjoyed listening to dozens of speakers representing global companies like Disney, Barclays, Adidas, Capital One, Verizon and others, share their DevOps and digital transformation journeys. We certainly learned a lot and were excited to hear several stories about value stream management and business-centric talks that aligned with our own vision. There were a few themes and sessions that stuck with us and we wanted to share those highlights with you:

  • The Intersection of Business and Technology: It’s no secret that every business is becoming a technology business. From banks to government to retail it’s important that every company have a digital presence, as consumers become more reliant on accessing what they need on a website, app or other digital platform. Plus, with consumers becoming increasingly demanding and the landscape becoming more competitive, being able to deliver quality at speed is mission critical. For many years, tech teams within organizations functioned as a silo from business teams. This created bottlenecks, general misunderstandings to outright disasters, and ultimately poor customer experiences that affected the bottom line. Organizations are finally realizing that technology and business teams need to come together to work toward a common goal and have a mutual understanding to encourage a blameless culture. These themes were especially apparent in talks like this one from Aimee Bechtle and John Schmidt from Capital One. Bechtle, senior manager, next generation infrastructure business strategy, and Schmidt, software product innovator, shared how they created cross-disciplinary teams by starting a DevOps dojo. The Nike talk, from Randy Lyons, senior director of Nike digital, and Michele Power, CFO of Nike Direct EMEA, emphasized the importance of business leaders understanding technology, and technology leaders understanding business. We could not agree more that having business and technology leaders sit at the same table is a critical step in realizing digital transformation.
  • Don’t Leave Out Ops: A phrase we often heard at the conference was “The DevOps equation has been favorable to the Dev side.” Well, not anymore! Damon Edwards, co-founder and Chief Product Officer at RunDeck, gave an insightful and engaging talk on how developers have frankly had it easy in this whole DevOps movement. He walked through a ticketing system that many in the audience were all too unfortunately familiar with, ending with the conclusion that the adoption of Agile, DevOps and Continuous Delivery methods has by and large left operations out of the picture, leading to failing transformations. Other sessions like this one from Cornelia Davis, senior director of technology at Pivotal, also talked about ways to revolutionize and engage the operations side of the DevOps journey. While Davis, Edwards and others brought to light the current state of operations, it’s clear that much more needs to be done to bring operations into the transformation fold. Hopefully as we head to DevOps Enterprise Summit Las Vegas later this year, and the London event in 2019, we will begin to see some success stories of bringing ops into the mix.

There was so much more that was shared and learned over the course of two days, but the themes of integrating business and technology, and next-gen operations stuck with us the most. If you attended, or watched the live stream, we’d love to hear what your favorite talks or themes were! Comment below to leave your thoughts.

If you want more DevOps in your life, be sure to join us at DevOps Enterprise Summit Las Vegas October 22-24, 2018 at The Cosmopolitan. Early Bird tickets are still available until July 16 – register now.

The post DevOps Enterprise Summit London 2018 Recap and Highlights appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

DevOps has grown significantly in recent years as an approach to better and faster software delivery through breaking down the Development and Operations silos. Author and speaker Gene Kim defines DevOps in The DevOps Handbook as, “The emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.”

What types of challenges prompt an enterprise to start looking to DevOps to improve process and flow? Issues such as:

  • Lack of management visibility;
  • Inconsistent processes;
  • Incompatible data and measurements;
  • Minimal collaboration and knowledge sharing;
  • Deployment delays, inefficiencies and errors;
  • Limited alignment with business strategy;
  • And unmanaged dependencies

All of the above can contribute to slow release times while the cost of regular inefficiencies take a toll on the organization. Team members experience frustration due to a lack of clear direction and changing priorities and company resources are depleted. These challenges are familiar at all levels of the enterprise — from portfolio to program, release and team.

These challenges are all reasons that organizations bring companies like CollabNet VersionOne into an Agile-plus-DevOps discussion. Any one of the challenges mentioned is enough for managers to seek a better way, however most of the time we see enterprises facing almost all of them at once.

When we meet with large enterprises that are dealing with the challenges above, these issues have repercussions throughout the entire business.  What about taking a more holistic approach and applying the principals of DevOps to the entire product delivery pipeline?

This is where Value Stream Management (VSM) comes in. What is VSM?  Forrester defines VSM as a mechanism for business users’ visibility into how much value is being delivered. It gives all stakeholders a view of the health of the product delivery pipeline. In essence, VSM is end-to-end visibility and perhaps value delivery is simply the last dark mile.

For example, there are a number of iteration periods that may be well known to an enterprise in capturing value such as portfolios, epics, features and backlog. However, to truly create value, other iteration periods, such as commit, artifacts, packages, releases and deployments, must also be known, measured visibility.

So how does an enterprise apply DevOps throughout the value stream? Is it possible using point tools alone? We see many organizations with an alphabet soup of tools from AWS to Puppet to Jenkins and dozens more, yet they still face the challenges that I first mentioned, such as incompatible data (no way to correlate data from various tools) or minimal collaboration and sharing.

On top of the hodgepodge of tools, the silo-ed teams and distributed nature of most enterprises today, we also find that there are a number of methodologies in use within an organization such as Agile, CMMI, Waterfall, etc. The struggle can be to blend work items across teams and the good news is that VSM can map multiple methodologies and still produce the needed traceability and visibility for business value evaluation.

Simply creating software faster does not solve the problem. In fact, it can create new problems, such as higher inventory, unchanged delivery processes and endless new surprises that will overwhelm teams.

Resources such as the State of DevOps Report give us a glimpse into how enterprises are doing and affirms the need for a more holistic view of DevOps that spans value streams throughout the organization and enables business value visibility.  We see in the 2017 State of DevOps report that though organizations are increasing deployment speed, quality is lacking and the result is bigger failures and more time needed to restore service. In other words as source code change accumulates, we lose track of what matters most:  the business value. “Going faster” with a primary focus on automation only increases risk and likelihood of Failure.

We must measure DevOps performance in order to drive business value.  A discussion on how collaborative Dev and Ops environments can work better together to create real digital business drivers is the next step. The best way to adopt DevOps is clearly understanding the business value that the new changes will deliver, the efficiencies and benefits gained, and any future possibilities to optimize each product and process in a delivery pipeline.

As a longtime leader in the software development space, CollabNet VersionOne has the leadership (recognized this year already by both Gartner and Forrester).  Our main mission, as we have shared this week at the DevOps Enterprise Summit London (DOES18) is to enable enterprises to — not only deliver better software faster — but gives organizations implementing Agile-plus-DevOps a better understanding of the value delivered through visibility and traceability across the product delivery pipeline.

To learn more about marrying DevOps and Value Stream Management, please visit: https://www.collab.net/solutions/value-stream-management or watch the recorded webinar, “Bringing Value Stream Management to the Enterprise.”

The post Expanding Agile-plus-DevOps Across the Enterprise Value Stream appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The ideal DevOps project starts with everything stored in source control. As a coach, I often find that too little thought is given to how a team will handle their source control branching strategy. Time and time again I have seen how this one decision determines much of the complexity of both product and process. The ease of the journey to continuous delivery is largely dependent on this decision. Teams see success when they take time to make this decision and don’t just buy into master-only development or a model such as GitFlow. Instead, they think about how they want to manage complexity, and it starts with source control and branching strategy.

As an industry, we don’t think about branching strategies in depth or enough. One of the key tenets of DevOps is systems thinking and people tend to forget about it, albeit unintentionally. If branching strategy is supposed to be the best thing since sliced bread, why does it feel or look like we’re trying to navigate through a train yard with no knowledge of how to navigate through the train yard? We’re not train engineers, at least not at the beginning of our efforts.

The current state of branching strategies is usually more like organized chaos. The less complex or the simpler your branching strategy is, the simpler your product is going to be, and the simpler it will be to maintain it. Feature branching and feature toggling are two ways to simplify:

  • Feature branching: Feature branching is when you take a feature, work on it by yourself in its own little space, and then merge it back in to the pipeline. Oftentimes I see people using a much more complex model called GitFlow. GitFlow can be abused as a branching model although it comes in handy for understanding that you still need to maintain all the code, but it’s infinitely more complex.
  • Feature toggling: Feature toggling can be helpful, especially if you work iteratively or with an agile process. Jez Humble and Dave Farley are very clear in their book Continuous Delivery and the follow up since writing this text book. Trunk “based” (not trunk only) development is key to the team understanding and integrating their changes together. When the team has to deal with integrating their changes on a trunk or master branch every day, they have to deal with the pain of integration immediately instead of somewhere down the line with a merge. When we introduce feature toggling, teams can provide toggles around their new features to make sure they have control of them in production. Feature toggling gives teams (Dev and Ops) the ability to make sure that when something doesn’t work as expected, it can quickly be turned off.

All of this means that we have to learn as an organization what works best for us. On the complexity curve, this isn’t a linear problem, it’s more exponential. Just think about the number of branches that you have to maintain and all of the work you have in progress at any given time – it’s naturally more exponential. What can also add to the complexity is if you’re using a model where you create a lot of branches, you might be doing work that’s not actually going to get out into your production environment, which is a problem, because then you’re spending time doing something that you might never get back to.

The more often we work together and on fewer things, the better off we are. Keeping it simple doesn’t mean that it can’t be complex. Keeping it simple just means that everybody knows what’s going on, everybody knows how to use their own internal process the right way, so that when it comes time for changes to come together for a release or a deployment, everything works together very, very smoothly. That’s how I hope you can be epic with your own branching strategies and reduce the complexity of your product.

The post Branching Strategy – The Forgotten Child of DevOps appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

While it may seem that DevOps is past its honeymoon phase, quite the opposite might be true. As noted in the 12th Annual State of Agile Report, 48 percent of respondents said that their organization is currently undergoing a DevOps initiative. That leaves 52 percent who are only planning or are not even on their DevOps journey yet! However, 65 percent of respondents said that a DevOps transformation was important or very important to their business. So, why might there be a lag between adoption and acknowledgement of benefits?

One of the main reasons teams set out on a DevOps journey is because they want their organizations to continuously improve. While achieving this benefit, and several others, is the end goal, it can be really challenging to know where to start. An analogy I like to use, is likening starting a DevOps transformation to operating a train for the first time without ever having driven a train before through a switch yard. Many organizations we run into today see DevOps as this big monstrosity (like a train having to navigate a train yard and load cargo or deliver cargo), which can understandably be challenging to understand and implement. They don’t know how to begin because there are multiple places to start; further more choosing the wrong starting location or worse, derailing, can start or set the entire business off course.

In order to move from this chaos to making a definitive first step on a DevOps journey, there are four questions you should ask (and answer!) to help you decide where exactly to begin:

  1. How can you increase the quality of all of your DevOps processes?
    If we are measuring, we need to be able to tell how long we are spending in development, how long we are spending in testing, how long something is sitting on the shelf, and then how long might it be in an A/B scenario where somebody is testing but it is not really fully out into production. We need to be able to identify bottlenecks and poor quality. Once these bottlenecks are identified through measurement and their resulting metrics, only then can we begin to see where improvements can be made.
  2. How can you accelerate delivery?
    This is key to getting stakeholder buy in. If you can identify blocks of value and can track them through all the phases of maturity in the software delivery lifecycle, you can actually prove to the people who are making organizational decisions how fast we’re moving and how each phase of the process affects one another as well as how much quality there is within the process. This enables the third way (see The DevOps Handbook for a much better explanation than I can provide).
  3. Are you confident about what you’re delivering and how are you able to assess the riskiness of a deployment?
    If you can tell someone that your release is this risky or that risky compared to another release, we know how much effort to put into validating and verifying it will deploy and run well in production. We know how much effort we need to expend to make sure that we have gotten all the defects out of our release and so we can do a valid risk assessment of our product. In other words, take your time and build up confidence your DevOps transformation is a journey of continuous improvements!
  4. How do we improve in compliance?
    How do we get people to the table sooner in the process that are generally left until last or next to last for their input or validation and verification? For instance, enterprises that have high risk models or governmental regulations that they have to meet in order to get products out to end users, face a lot of lag time. However, it’s important to address security and compliance issues upfront and to have those teams in on conversations about development to address any conflicts before they get too deep into production. Studies of high performers by DORA show that moving security, configuration management and compliance farther left in the process improve lead times.

Why ask these questions? They address the main components of DevOps Performance Measurement and further address how to manage a Value Stream from ideation to release. When it comes to measuring DevOps initiatives, we are easily able to identify the input and the outputs and how to measure them, but we do not know what is in-between and how to measure that. So, we have to be able to say how good we are at doing DevOps so stakeholders can feel confident in continuing to invest in the transformation.  

This is still definitely a lot to take in, but don’t be discouraged. Even the biggest organizations years into their DevOps initiative still come across points of failure and are continually learning. You won’t achieve DevOps tomorrow, or even next month, and maybe not even until next year. The best thing you can do today is ask the right questions, get the right metrics in place and prove to the critical members of your team that undergoing a DevOps transformation will be challenging, but overcoming those challenges and discovering new problems will be even more rewarding in the end!

Bonus: If you want to learn more about what it takes to undergo a DevOps transformation, and have the opportunity to ask us and some of the top tech leaders from around the world how they got started on their journeys, we encourage you to join us at DevOps Enterprise Summit London June 25-26, 2018. There’s still time to register. Hope to see you there!

Bonus bonus: Watch the recording of me delivering a talk on this topic at DevOpsDays Charlotte 2017:

[IGNITE] Measuring DevOps To Provide Objective Continuous Improvement In Your Org - Logan Daigle - YouTube

The post Four Questions to Manage Your Value Stream appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Though version control is an essential part of any software development organization’s day-to-day routine, not all teams understand how to best leverage the tools available. Whether your organization is using Subversion, Git or any other tool to protect and manage your company’s valuable software assets, there are a number of ways to maximize those investments and save your teams time and effort.

In my last post I shared some best practices for developers when it comes to using version control systems. There are also a number of tips and tricks of the trade that organizations and managers can employ to help ensure better quality products, smoother process and happier team members.

These best practices below are recommendations for the way software organizations can manage version control and create good workflow habits. By following these guidelines organizations can get the most from using version control tools and set up their teams for greater success — quicker releases and better quality products.

 First off, let’s talk about source code. It is important, for obvious reasons, that everyone on the team knows how to access the source code repository or how to make changes to the software asset. Developers should be using the correct set of building blocks for each project. If critical updates had been made, those should most likely be included in various branches of the repository. Even though Git is a distributed version control tool, there should always be only one single source of truth to avoid confusion. Without maintaining these practices, collaboration gets harder and quality starts to erode.

Also, to speed users access when it comes to source code, replicate the data so that it is close to where it is needed. Replication is particularly useful when teams are geographically distributed. It is also useful to mitigate the load CI systems put on servers when verifying code changes, having a dedicated replica for CI usage eases that burden.

Source code is one of the organization’s most valuable assets and must be protected. Strict access control should be in place to keep IP safe and in the right hands. These access controls should be regularly updated as teams and roles change.

  • Keep a single source of truth.
  • Ensure speedy access to source code in a convenient location.
  • Control access to source code.

One of the reasons version control is so essential for software development is it helps ensure quality at the source. Organizations can save time and effort by tightly integrating code reviews and continuous integration (CI) within the source code management process. By shifting these practices left in the lifecycle, teams can develop software products with fewer bugs and that are more responsive to end-user feedback.

  • Integrate code reviews and CI as part of the source code management process.

You know the college nightmare that we have all experienced at least once — the one where you spend hours typing a research paper, only to forget to save and loose everything? This happens to developers also and is one of the reasons we have version control systems. No need to throw away projects and start over new. In general, it’s better to version control everything. Aside from generated content, better safe than sorry.

  • Use version control for everything.

Now let’s talk about repositories and release. The key here is, the more information the better. Keeping branching strategy and release process defined simplifies workflow for everyone. Team members should not be operating with vague guidelines or they may take an action that makes the most sense to them personally, rather than the prescribed outline for the organization. By insisting on proper documentation and clear, detailed communication of strategies and process, consistency is maintained.

It will help speed up starting a new initiative if each project can self-service repositories, manage access rights and define workflows. Again, there should be a consistent and clear process in place for all users.

  • Define, document and communicate all processes.
  • Keep the whole team in the loop regarding branching strategy and release process.
  • Speed up the beginning of projects by allowing self-service of repositories.

And finally, the best thing an organization can do to ensure team members are using version control systems properly is to invest in the continued learning of those team members. Companies should, in addition to prioritizing good documentation, organize training sessions and workshops. This will help individuals improve familiarity and skill sets with tools and processes and ultimately benefit the entire software organization.

While version control may not be the most exciting or news-worthy practice in software development, its importance cannot be downplayed. Software organizations rely on version control systems as a foundation for software creation, establishing process and workflow from the very beginning stages of the software development lifecycle. Using version control systems to ensure quality, protect IP assets and build teamwork all make the extra steps worthwhile.

If you missed my recent webinar, “Enterprise Version Control – How to Deliver Customer Value at Speed,” you can watch the recording here.

The post Version Control Best Practices for Software Organizations appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In my last post, Don’t Underestimate the Importance of Version Control, I outlined some of the basics of why version control is important. Version control saves versions of code which can then be reused, or in case of issues, applications can be reverted to older working versions. Popular version control solutions used today are Git, Subversion (SVN), Perforce and others. Version Control is vital at the enterprise software development level where you have a vast number of disparate teams. It is an every-day part of the developer’s routine, but also helps organizations achieve some high-level business goals such as increasing efficiency and improving quality and reliability of software.

Today I want to share some best practices for developers related to version control. These may seem like no-brainers, but after 15 years in the industry, you’d be surprised how many folks I’ve seen struggle to follow these guidelines. These tips benefit the developers by cutting down redundant work, increasing efficiency, and helping to prevent mistakes and errors. Following these tips will also promote teamwork and better collaboration as all of these habits make it easier for different people to work on the same code.

Best Practices for Version Control Users

  1. Make small changes. In other words, commit early and commit often. Of course, be careful not to commit any unfinished work that could break the build.
  2. Don’t commit personal files. These could include application settings or SSH keys. Often these are committed accidently but cause problems later down the line when other team members are working on the same code.
  3. Update often and right before pushing to avoid merge conflicts.
  4. Verify your code change before pushing it to a repository; ensure it compiles and tests are passing.
  5. Pay close attention to commit messages as these will tell you why a change was made. Consider commit messages as a mini form of documentation for the change.
  6. Link code changes to work items. This will concretely link what was created to to why it was created or changed by providing traceability across requirements and code changes.
  7. No matter your background or preferences, be a team player and follow agreed conventions and workflows. Consistency is important and helps ensure quality making it easier for team members to pick up where you left off, to review your code, to debug, etc.

Using version control of some kind is a must for any organization and following the guidelines above can help developers avoid needless time spent fixing errors and mistakes. These practices also help organizations reap greater benefits from having a good version control system. In my next post, I’ll provide some tips and best practices for organizations regarding version control. These tips will outline some ways that companies can ensure the workflow is optimal for ensuring quality and efficiency. Stay tuned!

Join me Thursday, April 19 for a webinar titled "Enterprise Version Control – How to Deliver Customer Value at Speed," to take a deeper dive into how version control can help you deliver value to customers. 

The post 7 Version Control Best Practices for Developers appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We are proud to announce the release of the 12th annual State of Agile report! Started by VersionOne in 2007, the report is the largest, longest running, and most widely-cited agile survey.

Over the past 12 years, the State of Agile survey has reached thousands of professionals practicing agile around the world – and boy, have we learned a lot! Each year, the findings from the survey enlighten us as to the advancements made in the agile community, as well as the areas where we still need to improve.

The data in this year’s report found that organizations are realizing the benefits they set out to achieve by adopting agile. The top five reported benefits of agile adoption include:

  • Improved ability to manage changing priorities,
  • Better project visibility,
  • Better business/IT alignment,
  • Faster delivery speed/time to market, and
  • Increased team productivity
Here are some more themes and takeaways from the 12th annual State of Agile report:
  • Agile is expanding within the enterprise – Agile adoption is growing within organizations, both more broadly and deeply. A higher percentage of respondents this year report that “all or almost all” of their teams are agile, and that agile principles and practices are being adopted at higher levels in the organization.
  • There is room for improvement in agile maturity – Only a small percentage of respondents indicated that their organizations have a high level of competency with agile practices across the organization. The majority acknowledge that their organizations are still maturing.
  • Organizations are scaling agile – The Scaled Agile Framework® (SAFe®) is reported as the most widely-used approach to scaling agile. Internal agile coaches, consistent practices and processes across teams, and the implementation of a common tool across teams are the top three factors reported to have been most helpful in scaling agile.
  • DevOps initiatives are on the rise – The survey reveals the importance of accelerating the speed of delivery of high-quality software, and the emphasis on customer satisfaction. It’s no surprise, then, that a large number of the survey respondents report that a DevOps initiative is underway or planned for the next 12 months.

Be sure to download your own copy of the full State of Agile report at www.StateOfAgile.com
What do you think? Let us know your thoughts and comments on the findings below.

The post Top Agile & DevOps Trends from the 12th Annual State of Agile Report appeared first on VersionOne Blog.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview