The Reluctant Agilist

What strikes me as ironic is it always seems to come at the end of a 2 or 3 day class where we have spent the time discussing an approach to work that is more lightweight than has been used in the past.  So, we’ve removed all the extraneous process, lots of the burdensome paperwork and a kitchen sink’s worth of other stuff but the question is still centered around on defining the bare minimum (of the less burdensome process) that must be done. 

If the person asking the question is specifically concerned about reaching a state of Agile Nirvana-ness, or works for a company that awards gold stars for Agility, my recommendation would be apply no less than the amount of <methodology or framework of choice> as is required to deliver working product. This is one of the primary way we measure success in Agile. But most organizations do not give out a prize for being “TOTALLY AGILE”. And at the end of the day, the job is to deliver something that works, which can improve the company’s financial position in one way or another. In order to reach that goal, one must apply no less than the amount of <methodology or framework of choice> as is takes to reach that state.

But for many of us, especially those trained in traditional project management, we need a line in the sand. We want something helps us know when we are fighting for the Empire or the Rebel Alliance. (One more reason we should all be issued orange jump suits when we take CSM training.)

There are specific elements in the Scrum framework that (IMHO) when left out result in the practice of something which is possibly Agile, but no longer Scrum. However, my list is based on my own personal understanding of what SCRUM. This begins with what is defined in the Scrum Guide (and related documentation) and is then filtered through my own empirical approach and experiences. I’m quite sure solid arguments can be made to dispute each item I would include (or not include) on that list of what is required to do Scrum.

In my own personal practice of Scrum, there are two parts to the answer. The first part of the answer is that each person involved needs to apply no less than the amount required to complete work that can drive revenue. The second part if that in order to truly see the benefits that Scrum (or any Agile practice can provide), I have learned that it is best to start as close to a pure version or the practice as the individual’s organization can tolerate. Each iteration offers an opportunity to plan-do-check-act over and over again. Each time we go through those steps we should making adjustments until an optimal practice of Scrum emerges. Once this optimal practice does emerge, they must  never stop finding ways to break it and make it better.

What I am more curious about is what drives the desire to find the bare minimum of the newer, more lightweight process. My expectation is that it stems from a perception that Scrum would be difficult to implement within the context of whatever waterfall-esque process is currently in place. This could easily lead to the question of how much can we leave out and still technically call it Scrum.  But again, at the end of the day, bonuses are rarely awarded based on Scrum purity. And there are, unfortunately, far too many organizations, teams and individuals out there who have jettisoned all but the vocabulary and still feel comfortable calling it Scrum.

One of the main concepts in Scrum is the idea that when a team commits to getting the top prioritized work to a potentially shippable state by the end of a sprint, that they be allowed to make good on that promise. This is one of the core points at which trust is developed. The organization can begin to trust that the team will deliver as promised and the team can begin to trust that the organization does actually know what its’ top priorities are, and is able to stay focused on them long enough to allow the team to deliver on their commitment.

In theory, this sounds very simple, but for many organizations, the tempting lure of a new opportunity that must be started “RIGHT NOW” is tough to resist. Many organizations see their position in the marketplace as demanding the ability to respond at a moment’s notice to changes in the marketplace. Many of them consider their ability to do this a hallmark of their own agility. Unfortunately, it probably falls closer to a hallmark of their organizational ADD.

When an organization interferes with a team’s commitment once it has been made, it is called breaking the sprint or abnormal termination.

Look! A Squirrell!

For a framework like Scrum to work, there has to be trust. The trust in Scrum is predicated on the various players making promises and sticking to them. For the organization with ADD, their inability to maintain focus on top priorities for a period of time as short as two weeks can be far more devastating than they realize.  What’s worse is that the longer this lack of trust remains, the harder it becomes to understand what happens when you violate the trust.

An Example

The Organization considers itself very Agile. It has a market reaction response time of less than ½ day. This means that within a 4-hour period, The Organization has a defined approach of stopping all its’ people from working on their various projects and uniting behind whatever new effort has reached a point of criticality. The Organization has been trying to do Scrum, but Scrum hasn’t been working because The Team can’t finish their work in a sprint and can’t even provide decent estimates as to how long things will take. The Organization believes that if The Team got better at estimating, and making good on their commitment, then The Organization would not have to constantly interrupt them. As it stands now, The Organization can’t wait until the end of the sprint to introduce new work because The Team can’t even tell when the work will be done.

In the above scenario, The Organization has a lot of frustrations with the team not being able to finish work or forecast how long it will take. This is totally understandable. Sadly, The Organization doesn’t see that it is actually the cause of the things it is complaining about.

The Breakdown

In this scenario, regardless of where the breakdown began, what is in play is a consistent, pervasive dysfunction where The Team commits to work it cannot complete. This is in part due to the fact that they don’t expect to be allowed to meet their commitment because The Organization has (through it’s behavior) set an expectation that they will interrupt the sprint and ask the team to re-plan around new work. For the team who is expecting the interruption, there is little chance that they will be able to become completely invested in meeting their commitment since no amount of effort on their part will make it happen anyway.

The second cause for this issue is that the team does not understand it’s own velocity. It doesn’t understand its’ velocity because it never meets its’ commitments. Without velocity, it can’t accurately plan work into a sprint or understand when a particular set of work will be completed.

If The Organization were able to hold off until the end of the sprint and allow The TEAM to meet their commitments, The Team would be able to to understand its’ velocity. If they understood this, they could determine how long things would take and provide The Organization with the forecasting information they need.

Each time The Organization breaks the sprint and has the team reorganize around new work after a commitment has been made, it steps on The Team’s ability to deliver and earn the trust of The Organization. In order to reform the trust, The Organization is going to have to stop interrupting the team and allow them to complete their work. Only then will they get the level of predictability they are looking for.

Repeatedly taking the time to examine how things are going is something that is baked right into an Agile approach. Scrum, for example, is defined as being built on “three legs”: transparency, inspection, and adaptation. If you are practicing Scrum, each Sprint includes the Sprint Retrospective, a “ceremony” where the team meets privately to inspect how they are working and to determine what steps they need to take in order to improve during the next Sprint. While a disciplined traditional approach may include a review at the end of each project (or ideally, the end of each phase), in Scrum, this happens every 2-4 weeks. It is the last official thing a team does during each Sprint.

The Scrum framework offers a more lightweight approach than you’ll have under a more traditional methodology like the one defined in PMI’s Guide to the Project Management Body of Knowledge (PMBOK). Because Scrum has removed so much of the process overhead, one of the things that teams come to depend on is the cadence of Scrum. We begin each Sprint with our Sprint Planning meeting; we hold a Daily Standup (or Scrum) meeting each day (at the same time in the same place); we hold a Demo (or Review) meeting with the stakeholders at the end of the Sprint and we follow that up with the Sprint Retrospective. Each of these practices provides opportunities to inspect and adapt, but it is the Retrospective meeting where the team comes together privately to exhale at the end of the Sprint and work out how they, as a unit, can become more effective.

Another interesting aspect of the Sprint Retrospective is the way the meeting is conducted. Teams will often start by focusing the positives and identifying what went right during the Sprint. Even if the Sprint did not go well, there is always something positive that can be gleaned from it.  When the team talks about what could have gone better, the goal is to offer constructive criticism geared towards enabling them to function better as a unit. The subtle shift in from focus on “you” to “we” is a very important cultural change for those of us making the switch from a traditional approach. Before the Sprint Retrospective ends, the team will come up with an action plan for the next Sprint so that they can do more of the good things they’ve identified and take steps to correct some of the things that did not go as well as they could have.

If you are new to Agile, it may seem unnecessary to hold reviews with the frequency called for by Scrum - especially if things appear to be going well. Many rely on the old adage, “if it ain’t broke, don’t fix it”. The problem with that approach is that it becomes far to easy to overlook things until a time when they are so clearly broken, that there is no way back. If we are always inspecting and adapting, we are far more likely to catch things while we still have the ability to make any necessary adjustments.

If you are interested in learning more about Retrospectives, there is a great book by Esther Derby and Diana Larsen called Agile Retrospectives: Making Good Teams Great.

Talking through the commitment vs. forecast question in the class offered a great example of one of the truly awesome things about Agile. Regardless of which flavor(s) of Agile you are working with you can expect that the standard will continue to evolve and change – and that is baked right into the different frameworks. So, as the workscape continues to grow and transform, expectations for productivity continue to increase and as knowledge workers continue evolving how they approach the overwhelming volume of information they have to deal with on a daily basis, it is safe to say that the techniques we apply in Agile will continue to evolve as well. This may not sound significant on the surface, but I would like to offer two points to illustrate why I believe the organic nature of Agile is so critical.

1.     Knowing that you are working with a methodology or framework that is going to continue to evolve and change places a different sort of demand on the practitioner. When working with a standard that is more, or less, locked down, many people reach a point where they believe they have finished learning it. Hopefully this is more the exception than the rule, but the problem is that they are able to get to this point in the first place. With a standard that is not locked down, that continues to keep pace with the changing workscape, the only way for the worker to remain viable is to continually grow their own knowledge and experience in step with the practice.  This forces Agile practitioners to approach their work as a learning experience, which requires a level of awareness and attentiveness that is not called for  by someone who has already “learnt” it.

2.     For the practices themselves, once they are locked down, the change control process can become such a burden that the framework, or methodology becomes static. As soon as this happens, it begins to lose its’ ability to provide value in a continuously evolving workscape. If Critical Chain really was the last new tool added to the PMBOK, than that means that the process most of us have come up with reached a static point during a time when:

·      Most of us used Windows 98 or NT

·      Most of us probably got online using AOL and a 14.4 Baud dial up modem

·      The iPod did not exist

·      We had never heard of Monica Lewinsky

·      We had never seen the Matrix

·      We were probably still watching George Clooney on E.R.

·      We were still two years away from hearing the phrase “Hit Me Baby One More Time.”

It is clear that our world of work has changed significantly since 1997. The way we deal with our work has also changed significantly since then. Why then, wouldn’t we require that of our process as well?

The Scrum Guide is the document created and maintained by Ken Schwaber and Jeff Sutherland at Scrum.Org and it serves as their definition of what Scrum is. A recent change to that document has the potential to significantly alter the way many people look at Scrum.

Here is the definition of the change as defined in the update notes:

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
(See: http://www.scrum.org/storage/Scrum Update 2011.pdf)

For some, the switch from commitment to forecast will be simply semantics and not a point of concern. But I believe that removing the idea of making a “commitment” and changing it to “forecast” has the potential to be a very dangerous change for Scrum. For high performing, committed and focused teams, this may not present a issue, but for the teams that are just beginning a transition to Scrum, or struggling with the discipline required to follow the process, this change has the potential to make it “OK” to not deliver potentially shippable code in any given Sprint.

In Scrum, at the end of the Sprint Planning meeting, the Team makes a commitment to the Product Owner. The team commits to what stories it says it will get done during the Sprint. While it is not expressly stated as such, this commitment is basically the Team saying to the Product Owner (and thereby to the Business), “if you are available to us for questions when needed, and otherwise do not disturb us or try to alter what we are agreeing to do, we will have these stories completed and ready for review by end of Sprint.” This may sound simple, but there is a lot going on here.

First, the Team is saying that they’ve looked over the prioritized work, and with their current (but admittedly incomplete) understanding of what is being asked of them, they feel enough comfort with their knowledge of the stories, the project, the process of getting work done and accepted, and their own capacity and abilities as a team, that they can take responsibility for getting that work to a state of potentially shippable by end of Sprint.  So, while each Story Card may only represent a conversation, enough work has been done breaking it down into tasks and understanding the acceptance criteria that the Team is willing to be held accountable for it.

Accountability is a critical part of Scrum. Once the Team makes the commitment, they are responsible for it. If they’ve over committed, they still need to get the work done. If one team member becomes ill or is otherwise not able to perform their role, the Team still needs to get the work done. There are times when, for one reason or another, the Team can’t complete the work. If there is a valid reason for this, they should feel no fear about reporting to the stakeholders in the Review Meeting. If, however, they are just not getting it done, they should experience a significant amount of discomfort at having to explain their failure to meet commitment to the people whose budgets are paying for them.

For the Team, commitment is important because it carries weight, and the Team should feel the burden of that on their shoulders. However, the Team should NEVER commit to things it does not feel it can accomplish. This is something that they need to defend. No one is going to praise them for not doing what they say they’ll do. The promise of Scrum is that you get potentially shippable product at the end of every Sprint. When a team commits to things it does not believe it can do, it is basically committing to failure. Scrum offers the Team great power and, as Uncle Ben said, “With great power comes great responsibility.”

In addition, as it is working through the Sprint, the Team should be monitoring its progress towards meeting the commitment. Anytime an individual works on something that does not contribute to meeting the commitment, the team should work to correct that because it is the other team members who have to pick up the slack.

It is also important to note that it is not just the Team that is making a commitment. When the PO accepts the Team’s commitment, he does so on behalf of the Organization. The PO’s part of this commitment involves ensuring that she is available to the team as needed to provide additional information about the features defined on the story cards. It also means that the PO is agreeing (on their behalf as well as the organization) to not introduce change into the Sprint once the commitment has been agreed upon and to not otherwise disrupt the team (or permit the Organization to do so).

This two-way commitment is the basis of trust for the Sprint. When a commitment is not met, the trust is endangered. If this happens and the Team cannot determine why and make necessary corrections, it may result in the team repeatedly failing to meet its commitment. At this point, the idea of a Team commitment becomes invalid, and the lack of accountability places us more or less back where we were before taking on Scrum.

In many ways, Agile is a privilege, not a right. Teams should treat it as such and be respectful of the idea that “with great power comes great responsibility.”