Poor implementations can be messy!

Poor implementations can be messy!

Implementing Agile poorly will yield poor results. There are three categories of poor implementation – partial implementations, failing to define interfaces with non-Agile groups and not training everyone involved. Poor implementations of Agile increase the risk of failure because those involved with Agile projects will not have enough guidance. That will generate conflict and put pressure on people to revert old behaviors. Both conflict and reversion generally translate into lower quality, lower productivity and unhappy customers.

Partial implementations of Agile increase the level of process complexity that any Agile project will face. Process complexity is a problem because it slows groups down and makes it harder for them to follow the process.  In some cases it is harder because there are more moving parts to remember to do, and in some cases its harder because is causes people to actively resist the process (listen for comments like, doing XYZ is a waste of time or I will skip step ABC and ask for forgiveness if I get caught). Part of the complexity will be generated by the increased number of boundaries between those that are following Agile techniques and those that aren’t. Just the difference in vocabulary can create complexity.

Some organizations only implement Agile techniques haphazardly. Others don’t caution their teams on the impact of adopting only the part they think is important, which results in partial implementations too.  This causes the built-in Agile framework controls not to ensure process fidelity. Agile frameworks, like Scrum and xP (Extreme Programing), are built to form an interlocking set of control mechanisms.  For example, the technique of sprint planning, which generates a sprint backlog (list of tasks) replaces the waterfall mechanism of detailed task scheduling.  If sprint planning was not implemented and detailed task planning discontinued (hey, we are Agile…), one of the basic team level control mechanisms would be missing and it would be easier for a team to wander off track.

There are many partial variants that organizations have tried with a wide range of results.  They include: “water-Scrum-fall” (thanks to Johanna Rothman for this one) which features a big upfront design, Scrum for coding and then a major test event”; “iter-fall” which is Agile up to a point, then a big bang of testing and rework and re-testing occurs, and “fall-iter” which is a big upfront analysis, then Agile for coding.  Partial implementations require a significant amount of planning to make sure all of the controls are in place to protect both the team and the organization, and to ensure that communication points are identified between processes.

Just because your team is doing Agile does not mean every team or department in your organization is doing Agile.  This is a problem because those groups that aren’t Agile may expect you to act exactly the way you did before you began using Agile.  Every IT organization has a huge number of specialist departments that are critical to the delivery of functionality, ranging from security (of all sorts), database administration, change management (production gatekeepers), project management office and more.  The list could go on and on.  Couple this with groups outside of IT, including: procurement, legal, finance and marketing departments, and the possibility that everyone will be using Agile techniques approaches zero.  Depending on the type of project you are doing, EVERY one of the departments mentioned are going expect some form of communication or deliverable in order for your project to progress.  Ouch!  Organizations that implement Agile must spend the time and effort to negotiate how Agile teams will interface with support and other groups (this includes development teams using legacy methods and techniques).  I have seen examples of support teams that have stopped an implementation, albeit only for a few days, because an Agile team had not created a formal requirements document and had it signed off, because the document was on the support team’s checklist. The “backlog” was not deemed to be sufficient. The solution is to identify every interface and make sure to negotiate the rules of engagement with the affected parties before they get a chance to stop the project!  Do not assume you have the right of way.

Failure to train everyone involved or affected by the implementation of Agile (or any major organizational change) will lead to chaos. The development and management of technology projects is not rocket science (unless you are building rockets), but it is at least moderately complex. The complexity of the process needed to develop and deliver a project means that everyone involved in or affected by Agile techniques need to be trained.  Training should include their roles, how they should use Agile techniques and, as importantly, what it means to be Agile. Can you learn Agile from a book?  You might be able to, but everyone that will be affected by the implementation probably won’t have time to read the book, therefore training is necessary.  Adult learners have special needs that include timing (learn when there is a need to know), require experience (hands-on training), are life-centered (focus on learning tasks) and are responsive to external motivation (promise them a better job)[1]. Training is more than a PowerPoint lecture, the best training is hands-on, is related to the role they are playing and delivered just-in-time for use in the real world. Training correctly improves the chances of a successful implementation.

When implementing Agile, the techniques must fit the organizations culture. However, if you are going to implement parts of a framework or just specific techniques, make sure that you do it with your eyes wide open.  You will need to hold on to processes from the methodologies you used in the past to ensure a good series of check and balances.  Include all the teams that will be affected by the implementation and make they understand how you will interface with them.  Train everyone that is affected, including senior managers. Remember that the implementation of Agile is not fragile, but a poor implementation will yield less participation.