In the first part of this series, I focused on two of the primary causes for failure in the implementation and use of Agile methodologies — cultural failure and lack of training.  While these are probably the primary things that cause issues with Agile processes, they’re far from the only things that can (and do) go wrong.  In this second part of the series, we will explore the need for continual (or continuous) improvement and lack of evangelism and how they relate to the success or failure of an Agile methodology.

Retrospectives — Continual Improvement in Practice

One of the more common issues that I see, even in teams that adopt most of the other practices of a methodology like Scrum is a failure to fully engage in the type of continual improvement processes that are foundational to any Agile practice.  In Scum, these are retrospectives — the time at the end of every iteration where the team gets together and discusses what went well during the prior iteration, what didn’t go well, and decides on new things to try to correct for those inconsistencies or inefficiencies they encountered.

To understand why these meetings are so important, we need to look at the history of Agile, which has a direct lineage to the Lean Manufacturing processes that became popular in Japan after World War 2.  Lean Manufacturing focused on empowering teams and individuals to do the right things at the right time to provide the most value from the manufacturing process — and that should sound intimately familiar to anyone who’s done an ounce of research into the Agile philosophy.  One of the eventual outcomes of W. Edward Deming’s work in Japan was a process that can be encapsulated by the concept of “Plan -> Do -> Check -> Act”:

• Plan = Obtain requirements
• Do = Perform some action to bring the requirements to life
• Check = Measure performance, identify faults
• Act = Implement corrective actions to improve performance

The problem with many Agile implementations is that they skip the “Check” & “Act” phases — which are what the Retrospective (or similar meetings / rituals / ceremonies) are meant to do.

Now, I get it — a lot of people see these meetings as too “soft” or that they’re nothing but “bitch sessions” where people complain about what other people did wrong.  That’s not a problem with the concept, but a problem with either the culture or the facilitation.  When done right, a good retrospective is quick, focused, and narrowed to issues that are of general concern to the team —

• If your team members are calling others out, you’re doing it wrong;
• If your team can’t identify anything that went wrong during the iteration, you’re doing it wrong;
• If your team can’t identify anything that could be improved on, you’re doing it wrong.

No team is perfect, and there are always things that come up that could be corrected — even if it’s a small thing like “People talk too much during the daily standup, so I can’t get back to work in a timely fashion.”  These don’t have to be genius-level issues; they might be a series of very small things that add up to a big impact.

One thing that I’ve seen work exceptionally well is to use a dot-voting system for your retrospectives.  Divide a large flip-sheet or a whiteboard into four spaces, and label them “Good Things”, “Bad Things”, “Improvement”, and “Kudos”.  Bring the team in, hand them a set of 4-6 dot stickers Post-It notes of the same color, and give them a Sharpie or other permanent marker.  Let them brainstorm ideas for each category for 5 minutes, then make sure they’re all posted in the appropriate category.  Then, each team member “votes” for the Post-Its they think are most important or interesting, and once everyone votes, you organize them by most-voted to least-voted.  Next, spend the next 20 minutes going through each item from most- to least-voted, and have someone take notes — spend little time on “Good Things” and focus most on “Bad Things” and “Improvements”.  Every “Bad Thing” you discuss should have at least one action that can be taken in the next iteration to correct for it.  Every improvement should be measurable and something that can be worked on in the next iteration.  Taking these notes and gaining commitment from the team ffor corrective action provides everyone in the room a firm understanding of what, why, and how these things can be fixed or prevented.

Ignore this, and you’ll stagnate.  Implement this, and you’ll be constantly improving.  Which would you rather be?

The Role of Evangelism in Agile Success

Because many people (wrongly) view Agile as the realm of development teams, and consider it to be primarily (if not exclusively) a software development commitment, many teams who switch to Agile methodologies attempt to do so in an insular and almost exclusive fashion.  The development teams restructure themselves into Scrum teams of 5-9 people, hold their daily standups in a development cubicle, review their work with each other and whomever they’ve managed to snag as a “Product Owner”.  They repeat this process in isolation, and lash out when “the Business” tries to feed them input and priorities, or when their work “isn’t appreciated” because it doesn’t resonate with the end users, customers, or the market.

You can’t effectively implement Agile practices in isolation — something I covered as a cultural issue in the first part of this series, as well as in other posts on this blog.  And if that’s true (trust me, it is), then most teams need someone in the organization to take on the task of explaining to others in the company why Agile is the right move, what it means to the organization as a whole, and how that’s going to change how they work with developers as well as how the company as a whole operates.  This person needs to be well-versed and experienced in effective Agile practices, and needs to be able to spend whatever amount of time they need to in order to drive alignment toward an “agile” culture across the organization.

This person needs to be able to call “bullshit” across the organization, including the development team, when necessary.  They need to be both the shield and the sword for the overall transition to more “agile” practices and approaches.  They need to have sufficient social capital throughout the organization to leverage those relationships when something goes sideways, or when another member of the exec team or management team pushes back — either overtly or passive-aggressively.  For these reasons, it’s often the Product Manager role that becomes the Agile evangelist, and if they’re given the proper background in knowledge, training, and experience, they can be the best tool the Development teams have for integrating “agile” thought and Agile practices throughout the organization.

Without someone acting as the overall evangelist, isolation becomes the order of the day, or even worse chaos takes over as every team comes up with a different definition of “agile” with different processes and expectations.  Then nothing gets done, because everyone winds up fighting.  Don’t be that company.