Barriers to Agile Adoption

Last Updated on Monday, 10 February 2014 10:47 Written by Derek Huether Thursday, 14 November 2013 05:14

We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks.  Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most.  I recently had a client ask me to introduce the elephant in the room.  I was asked to actually list some common barriers others have dealt with. I want to thank our friends over a VersionOne for distributing an annual survey of the Agile space.  One of the questions?  What is preventing you from further agile adoption?  Within the last published survey, 4048 people responded and they were able to vote for more than one barrier.  The responses may sound familiar.

Barriers to Agile Adoption

Did they miss any in the list?  How did you overcome your barriers to agile adoption?

“Big Agile” Slides from PMI Global Congress

Last Updated on Tuesday, 5 November 2013 02:38 Written by Jesse Fewell Friday, 8 November 2013 11:55

Last week was the PMI Global Congress 2013 North America, hosted in New Orleans. There were several agile talks, some loved and some not so loved. And there were some great agile exhibitors there in VersionOne, Rally, and LeanKit.

Meanwhile, my talk on large scale agile methods was part of the “strategic track” and yielded a full house. Although I’ve done this talk a number of times before, this is a completely new version. It includes case studies from large companies, but also incorporates the LeadingAgile change management strategy, and features the popular animation of the 3-tiered model for Agile Project/Program/Portfolio management.

There were some really good conversations after the talk, which tells me people are craving this kind of information. And now, it’s here for you to peruse at your leisure.

What do Scrum teams do during the Release Sprint?

Last Updated on Monday, 4 November 2013 12:36 Written by Andrew Fuqua Tuesday, 5 November 2013 07:10

• What does the system test or integration team do during development sprints?
• What do Scrum delivery teams do during the release sprint or hardening sprint?
• What proportion of a Scrum team’s time should be split between supporting the release-level activities of an integration team, versus planning for the next release?
• Shouldn’t we stagger our product releases so that each group stays busy?

Many organizations have a system test team or integration team that is separate from the Scrum delivery team (the Design-Build-Test team). I sometimes get questions like those above from such organizations as they consider adopting an agile approach, particularly from large organizations that have to integrate the work of multiple teams. I’ll answer these questions after giving a couple definitions.

Definitions

A System Test Team (also known as the Independent Verification and Validation Team, or the Integration and Regression Test Team, or the release-level integration team) is responsible for the execution of continuous integration and regression testing across teams and managing the resolution of the problems by feeding defects into delivery teams. They work closely with the System Team to continue to improve the continuous integration and testing capabilities.

A System Team (sometimes called an Enablement Team or the Build as a Service Team or other things) is responsible for building everything needed to support continuous integration, test environments and test data management. They develop the tools and support the automation. This is often a very small team – as small as one person or a couple of people. You only need this when the testing is going to require integration of multiple teams’ outputs for testing.

Now for the answers to the questions.

First off, read Dennis Stevens’ blog on six things teams can do that are better than writing code that can’t be tested. During a Release Sprint, delivery teams can be working on learning, reducing technical debt, improving unit testing and feature level validation, refactoring, or preparing for the next release. They should be instantly available to support any defect found in the hardening or release sprint, or be directly involved with the testing. Whatever time is remaining should be spent improving their capability and preparing for the next release.

During development sprints, the release level integration team (or system test team) may be doing integration and verification of everything delivered in the prior sprint. They should also be getting ready to test what is coming next. This means collaborating to refine acceptance criteria or to define tests for work about to go to delivery teams. They should be improving their automation and making an effort to understand (or critique) the delivery team’s unit test coverage. In addition, they should be improving their capability.

It is really important to avoid the late testing anti-patterns. Anti-pattern one: delivery teams not verifying their product effectively and throwing garbage over to a system test team. Anti-pattern two: teams not finishing features (a set of related stories that ultimately need to be tested together as a unit) throughout the release such that nothing is system testable until the end of the release. Anti-pattern three: deferring any amount of integration and regression testing until everything is complete.

The goal is to test as much as possible throughout the release, deferring very little to the end. This means delivery teams deliver verified and technically excellent features each sprint. Until they are perfect at this, they have work they can do to improve. This means system test teams integrate, verify and validate frequently (continuously). Until they are capable of doing this, they have work they can do to improve.

If you are looking for simple formula, you will be disappointed: There is not a simple percent-of-time formula for this. Look at where you are, coordinate with all the teams involved, improve your ability to minimize untested code, make sure work is ready ahead of development, and maximize flow of validated product through the system.

* Credit: I took an email from Dennis and massaged it into this blog post.

Bottom-Up Implementation & Top-Down Intent

Last Updated on Monday, 22 July 2013 10:02 Written by Andrew Fuqua Tuesday, 23 July 2013 07:15

A good strategy that I have used for dealing with complex agile transformations in large enterprises has two parts: bottom-up implementation and top-down intent. As Mike puts it, this is “where leadership sets the direction and establishes constraints, but with teams that are empowered to operate within those constraints.”

Bottom up implementation means helping teams be as successful as they can within their constraints. It means getting them mature enough to report out significant performance information like velocity, story ratios, resource shortages, quality and blocking issues on a reliable cadence. It means gaining transparency about the challenges in an actionable way. Due to extreme constraints in many organizations, this isn’t easy. What’s constraining agile in your organization?

Bottom up means helping the teams factually communicate the impact of obstacles on team performance. I use assessments to identify and communicate the “non-agile” behaviors and practices that are reducing the potential performance of the teams. Because we know that Agile/Lean practices work, we know that the teams that assess higher will perform better against their business drivers and performance metrics. Have you identified the obstacles in your company?

This approach of team and organizational assessments and improvement road-mapping tied to team metrics is a very mature way to help sustain the changes and to highlight where my clients aren’t getting the success they want. All this information from the ground credibly expresses the impacts of the organizational and management obstacles that arise from management decisions. In many organizations, you can’t simply create change in the larger environment to make the team stuff easy without first producing the information needed to justify change to management. This brings us to…

Top down intent requires helping management understand how they can be successful with Agile teams. They often are not in a good position to be successful with agile, they are under tremendous duress, and they need to work through a ton of challenges. Sound familiar? But we can still make progress. This requires explaining at the upper management levels and in other parts of the organization why they need stable teams. It requires data to demonstrate the impact of the organizational design in order to support moving toward the recommended org design. Understand the system, how it creates value, and its constraints. Build Scrum teams around the constraints.

As part of top down intent, it’s important to build awareness of the capabilities required in the program office that will be necessary in order to maintain the changes after the external agile coaches leave. They need to hire people to sustain momentum with internal training and coaching. And they should do this early on so these new people can get up to speed, spending time with the external coaches.

So there you have it: one way of approaching complex agile transformations in the enterprise. There is more, so stay tuned.

* Thanks to Doug Brophy for his help with this post, and to Dennis Stevens for providing the fodder.

Lack of Predictability: Your Biggest Problem

Last Updated on Monday, 8 July 2013 10:22 Written by Andrew Fuqua Tuesday, 16 July 2013 07:13

What I’m seeing at many of my clients is an inability to know what will be completed in the next release. This shows up as missed dates and frustration over broken commitments and “unreliable teams”. When the executives inquire, they get finger pointing and non-answers, such as “the 3^rd party software was late” or “software development is just inherently unpredictable”. Further, the yardstick they use to evaluate teams doesn’t help. They don’t realize, from top to bottom, that their biggest problem is a lack of predictability. Let me give you an anecdote.

I recently had the opportunity to coach a team considered the best in the company. During an earnings announcement, their CEO credited this group for driving a large percentage of the increase in revenue over the last quarter. This was a big deal. What did they do that other teams should be doing? Can they continue to deliver such results for the company? Actually, this team has no idea how much they can accomplish. Not in this coming release. Not this month. Not even this sprint. Are you seeing this in your organization?

Think Differently

They consider this the best team as measured by short-term business results, but if they aren’t predictable then revenue results aren’t enough. Although many CEOs are after short-term results, it does them no good if next quarter’s numbers aren’t close to guidance. The market hates surprises. Predictable steady growth is crucial. What this CEO really wants to know is how they are going to do next quarter.

Further, market factors and chance account for the results more than this team’s skill – any team could have produced those results given the chance to work on that product. This team actually may be the worst in the company when it comes to developing high-quality features each release. The product is the best by revenue, but the team has no influence over those results or with how they operate. Their results are a red herring.

Hidden Costs

What is the entire organization not paying attention to?  Predictability.

Here is a little taste of what’s going on: The members of this team change often. They borrow people from other teams, which contributes to their over-commitment each sprint and hurts the others. People are on multiple teams and commit to none of them. A couple days after planning, a programmer says he won’t help with their stories because he is helping another team instead. The Product Owner applies pressures to proceed without the required usability involvement, causing rework. They agree to start work on stories that are not ready for development. Attention from the directors through executives greatly increases the pressure, encouraging them to take on too much work each sprint. They regularly reschedule and ultimately cancel their retrospectives. And I could go on.

Their environment is keeping them from being predictable and productive. Sound familiar?

The Fix

Of course, it’s easy to say “don’t do that”, but much harder to implement changes. It requires a program of intentional improvement at the team, program and portfolio levels, supplemented with needs-based training, demonstrating results via agile health metrics and progress via assessment scores.

Since most organizations don’t know how to get predictable, many seek help from an enterprise-level agile coach. Since getting predictable in an enterprise is not a quick process, you need an agile coach who understands how to help when the organization isn’t agile yet. The type of coach you need will help the teams be as predictable as possible given their constraints; One who can help produce factual information about the velocity and quality that teams are able to achieve; One who can credibly express the impact of organizational behaviors that are reducing the company’s potential. You need a coach who will be a guide, interpreting assessments and metrics, relating training to day-to-day events, and cementing lessons learned in training sessions and workshops.

Our Approach

That is what my colleagues and I have been doing lately. We’ve helped companies get predictable. We focus on the end goal, but are pragmatic in our approach. Training is not enough. Sustainable change requires a holistic approach. Specifically, one must address the structure of the organization, their practices, and ultimately their culture. It takes a sustained effort to make a real difference. Engage with a company, meet them where they are, and help get them where they need to be.

* Thanks to many of my colleagues for help writing this article. I liberally stole whole sentences from Mark Kilby, Mike Cottmeyer, Dennis Stevens, Isaac Hogue and others.