The Reluctant Agilist

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.”

One of the common challenges that people face when trying transition towards Agile is that they get caught up in the idea that the change is impossible. The typical argument raised is that while the practices and behaviors sound very appealing, they would never work in their specific organization. This is not to say that there are not some organizations that just aren’t able/willing to adopt Agile, but more often than not the conflict stems from the fact that the individual raising the argument is just not able to envision a world in which the practices of their organization could change. While this issue isn’t specific to a debate between Agile and a traditional approach, it is one of the most tragic impediments we face in the workscape today.

How could they see anything but the shadows if they were never allowed to move their heads?
(Plato’s Allegory of the Cave – The Republic, Book VII)

A traditional approach to managing projects, and work is based largely on the idea that we need to apply controlling methods in order to keep things “on track”. Under this approach, deviation from process and practice introduces risk, so if we want to keep safe, we just stick with what we know.

The problem is that what we know doesn’t actually work. When I’m teaching Certified Scrum Master classes, one of the first questions I always ask is if anyone would like to take up in defense of a traditional (waterfall) approach. No one ever does... which makes sense in that context because why would anyone take a Scrum class if they were totally sold on a traditional process. But that aside, there is plenty to suggest that the normal way we work is flawed. Since the Standish Group began issuing the Chaos Report in 1994, the percentage of projects that finish on time, in budget with scope being met in a way that satisfies a client has never climbed above 35%. Since we aren’t professional baseball players, this would indicate that something about how we work is clearly more broken than not. The rub is that the way we work, even if it is flawed, is familiar. We are accustomed to it in the same way that the “strange prisoners” chained up in Plato’s Allegory of the Cave were familiar with their life of shadows and darkness. Where they and developed ideas about what the shadows represented, we’ve developed practices and techniques that are meant to help us believe we can control what will happen when we employ our flawed system. So, even though we may fail around 60%-70% of the time this is the devil we know. It is a consistent, predictable and comfortable devil.

The Devil You Don’t

Even when we realize that change may be needed, it is still uncomfortable. When the change is significant – like altering how an organization approaches work, it is easy to see all the little things that could be in the way making it impossible.

There is nothing impossible to him who will try.
Alexander the Great

When embarking on change like transforming a team or an organization to Agile, we all have those moments when we can only see the things in our way. This is a normal, human aspect of making any kind of change. The trick is that in these moments, we have to acknowledge that we are still so focused on the shadows in the cave wall that we are not allowing ourselves to imagine that there may actually enough light outside the cave that the shadows will disappear. When you find yourself headed down this rabbit hole, remind yourself to take a breath and rather than coming up with all the reasons why it wouldn’t work, try coming up with the reasons why it could work and think about what that might look like. Chances are you will find plenty of people along the way who are more than willing to offer reasons why it can’t work. If you want to see Agile take root and deliver value to your workscape, challenge yourself to be the one who can see the good things that may come from change.

It always seems impossible until its done.
Nelson Mandela

“Hustlers of the world, there is one Mark you cannot beat: The Mark Inside.” (William Burroughs, Naked Lunch (1959) Grove Press, 2003, ISBN 0-802-11639-6, 289 pages)

In preparation for a transformation project I worked on a few years ago, I held phone interviews with a number of they key stakeholders prior to my first onsite visit. The objective was just to get some basic knowledge about their experience with Agile and also to get a sense of whether they viewed the change in a positive light, or a negative light. One of these calls was to be with a Senior IT Manager. He had risen quickly in the company by being a bit of a maverick and playing by his own rules. A big part of his success within the company had come about as a result of him applying traditional waterfall practices around an organization that had previously had no discernable process, so I was surprised when I kept hearing what a big chamption he was of Agile and that he had been doing it for years. He was intelligent, well schooled, certified as a PMP and also, I was told, an expert in Agile because he had been doing it for years.

When we spoke, he started out by telling me how glad he was that the company was (finally) going to do Agile and then listed every reason why it would surely fail. He then expressed how important it was for his team in particular to be the first one to make the transition, and then ran through a list of reasons they would not be able to do it. Throughout the entire conversation he kept talking about how excited he was for the change and then following up with a lengthly explanation of why it would not work.

The high point in the conversation was when we started to discuss some changes in process so that they could practice Scrum. What they were doing at the time was textbook waterfall. He explained to me that as far as his team went, he was okay with changes as long as it didn't have a negative impact on the process they were currently following or the reports they were responsible for delivering each week. With respect to the possiblity of him making some adjustments to how he managed his staff he responded, “Listen, you don’t have to tell me about Agile. I’m know all about Agile. I don’t have to change anything about how I work. I’m completely Agile already!”

Unfortunately, the irony of his comment was lost on him. Despite his expertise in Agile, what seemed to be missing was the idea that part of working in Agile means we are constantly inspecting and adapting. This is an ongoing process. We are never finished working on getting better at working, and we are never done becoming Agile. In this particular case, the Senior IT Manager, who was responsible for setting the tone for all of IT, had decided that he was already so Agile, he no longer required being Agile. He looked down on the transition as if it was something for lesser beings and unfortunately, this flowed down to his staff, making the transition much more difficult.

In grifter terminology, the "mark" is the one who gets hustled, or taken advantage of because of his inability to see the con. The William Burrough’s quote above refers to our ability to be our own worst enemy. For an organization who has its’ sites set on transition, the mark inside can manifest many ways. Sometimes the folks walking around telling you they are experts at Agile will actually be experts. Just be wary of the experts who seem to have reached a point where they no longer feel a need to learn new things and get better at what they do,because that is most definitely a sign of un-agilility.

Review Meetings appear to be fairly simple in form, but for some reason, they often get twisted into a variety of different types of events that are really set up to provide the same value that a review meeting does. Sometimes this is due to convenience and sometimes just a simple lack of understanding. The Review Meeting is one of the most powerful parts of an inspect and adapt approach, so it never hurts to go back to the basics…

We hold the review meeting at the end of a Sprint in order to have the Scrum Team present their work to the Stakeholders in order to A) show the Stakeholders working product (our primary measure of success) and B) obtain the feedback needed to prepare for the next Sprint.

One common misunderstanding about the review meeting is the idea that this is where the Product Owner accepts the work. This is not the case. In order for work to be presented in a Review Meeting, it must have been accepted by the Product Owner as being potentially shippable at some point prior to the end of the Sprint. The purpose of the Review Meeting is to present the accepted work to the Stakeholders, and get their feedback. Because the Product Owner, who speaks on behalf of the business to the team, has already accepted the work (before the Review Meeting) it is considered accepted and potentially shippable when it is brought into the review. The feedback provided by Stakeholders in the Review Meeting could lead to new User Stories, which would be placed in the Product Backlog for prioritization by the Product Owner to be included in a future Sprint.

The Stakeholders and the Scrum Team attend the Review Meeting. The meeting is opened by the Product Owner who will provide the attendees with an overview of what transpired on the Sprint that is ending. This may include Sprint Goals and Objectives, Themes that were focused on during the Sprint, Total Number of User Stories Planned and Achieved, Impediments that arose and how they were addressed, if the team did not complete their work an explanation as to why should be given. Additional details could be added if needed.

As the Product Owner completes the introduction, the Team will be introduced to showcase their work. They may come up as a group, or select one or more members to speak on their behalf. The important thing is that they are present because if they’ve completed their work, they should receive praise for it. If they have not, they should feel the weight of standing in front of the Stakeholders and being accountable for not having met their commitment.

While the team is presenting, the idea is to show their work, talk about it and get feedback directly from the Stakeholders. Some teams approach this meeting as though they had been called to justify their existence on this planet. There may well come a time for that, but this is not it. Stakeholders are busy people and they have a lot of things that compete for their attention. In the Review Meeting, we want to respect that and show them the things that will excite them and get them talking – our goal is feedback. Teams presenting should keep things brief, focused and whenever possible, as tantalizing as they can. Once you see the cell phones come out and the laptops open, you’ve already lost them as an audience.

If the team has not met their commitment during the Sprint, they should stand before the Stakeholders and explain why. This is a scary thing and it should be. The Teams have the freedom to accept the work they thing they can do during a Sprint, but once they make that commitment, they are accountable for making good on it.

One mistake I made in the past was on a project where the team was really struggling. They were unable to meet their commitments and we had a hard deadline and a minimum set of functionality, which we were unlikely to have completed on time. Because the team was so busy, I would attend the meetings for them and each time, I took the hit for the fact that the team had not completed their work. From the viewpoint of a traditional PM, this is the right thing to do – take the hit, protect the team. But from the Scrum perspective, if the team is not directly held accountable, then they do not feel the weight of the commitment. It is this weight that solidifies for the Team, how important it is to meet the commitment.

Once the work has been presented, the Product Owner may hold a discussion about upcoming prioritization (like what is out roadmap looking like, what do we plan to do in the upcoming Sprint) and either the Product Owner or the Scrum Master may provide additional status, discuss Risk Management, Issue Management, HR or Communication issues, etc.

While I know a lot of folks who let this meeting run on a bit, my rule of thumb is to never let it last more than 1 hour for the simple fact that everyone in the room has work to get back to.

Often times Stakeholders will feel they are too busy to attend the Review. This is a warning sign that indicates they may not truly understand the Agile value system or why the team is following it. Stakeholder presence at this meeting is as critical as the Team presence.

For everyone involved, this meeting is critical, the Stakeholders have to show up, engage and offer feedback. The team members have to stand up for their work and the Product Owner and Scrum Master have to enable that last part to happen. All of this is necessary to generate the perception around the value of making and meeting a commitment. It is a lot of weight for the team to carry – and that is why they should take care with it. But, at the end of the day, this weight leads us to working product that meets our Stakeholders needs and this is why the weight is a gift.

The other day I was speaking with a friend about an issue he had seen during the company’s transition to Agile. The company leadership had made a decision to move to Agile, so there was definite support from the top. The staff had been trained together, and they had brought in coaches to work with the teams. In short, they were taking the steps that are normally recommended for any company who wants to position their Agile transition for success.

Despite all this, there were still a few hiccups here and there, which is common. Transitioning an organization over to Agile is not an easy thing to do because it requires that people change how they work, and more importantly, how they look at their work. Because of the effort required, it is not uncommon to have a few folks who exhibit some initial frustration because sticking with a devil they know (regardless of whether or not it is an effective way of doing things or how frustrated they are with it) is perceived as being easier than trying to change.

In talking through some of the specific things that my friend was seeing, there was one event that I was a little unusual. One team member had actually quit because of his belief that Agile was going to limit his chances for career advancement. This belief stemmed from the idea that on an Agile team we say that don’t worry about titles… everyone has valid ideas, opinions and a responsibility to share their thoughts and ideas. Following this line of thinking, the assumption can be made that because the company was transitioning to Agile, it no longer valued any single individual’s experience, expertise, etc. With no value placed on individual experience and expertise, there would be no reason to give anyone a title that would designate seniority or expertise. And if the company no longer valued titles, how and why would an individual get promoted? If the individual can’t get promoted, how would he demonstrate on LinkedIn that he had achieved a level of proficiency that was rewarded with more responsibility, and a better title. If the individual is not going to get those things, how will he remain competitive in the job market, and how will he get ahead?

I’m making some assumptions about the flow of logic, and it may seem like a bit of a stretch, but it is not an entirely uncommon line of thinking.

There is of course the issue that, if the individual is only worried about LinkedIn because they want to be able to move on to their next gig, then maybe they are not the right person for the gig anyway, but the reality of the job world is that we all need to be focused on staying competitive and employable, so I would like to let this one go for now and focus on Agile.

First, Agile is not for everyone. Some people really grow to embrace the freedom and responsibility if has to offer. Others, not so much. Second, if you ask anyone who has fully embraced it, they will tell you that Agile is not easy and not for the faint of heart. In some respects, it requires even more of you than a traditional approach. The good part is that your effort produces results you can see fairly quickly.

I vs. We

In a traditional model, you have a group of individuals. Each of them comes to work each day with a list of things he or she has to do. The expectation is that if an individual completes their work consistently and delivers solid results, that they will “get ahead”. If their work merits is, it is not unreasonable to expect that they will get a rise, promotion, office, company car, cape, etc.

The difference in mindset for something like a well-formed Scrum team is that instead of a group of people who are entirely self-focused, you now have a group of people who are team-focused. The “I” goes away and is replaced with “WE”. While they are together, the team discusses what they have to do and how they want to do it. Within this small community, each person has a voice that is unique and provides value. This does not take away from the level of expertise that an any one person has to offer, but it should foster the idea that whether you’ve been leading IT projects since punch cards, or you are straight out of school, everyone has something to contribute and everyone should be heard. It will be up to the team to decide how to manage this social interaction and decide how to go about the work. The difference is, the company is not saying something along the lines of “Ok, you pack of geeks… this is YOUR ARCHITECT, you will do his bidding because he is THE ARCHITECT”. Instead, this is the company saying “Hey, you pack of geeks… here is a problem. You are smart, creative people. Go figure this out.”

So, in this case, it is possible that the only thing blocking the path of the person who feels their career is being stalled by Agile is their need to be officially designated by the company is the person who is to be listened to. (They may not be so different from the PMs who wait for an organization to tell the masses that the PM IS IN CHARGE before they can officially start leading.)

It is also possible that the individual may just not have wanted to do Agile too much. The change is not an easy thing and it requires a lot of adjustment. The benefits it brings may not be valuable enough to some folks to work through the change.

With respect to titles and promotions, there is nothing in the Agile Manifesto that says an individual should not be promoted. There is not necessarily any reason this has to change. It is feasible that within an org, Person A might report to Person B. But when they come together to discuss the work to be done, they should both feel empowered to weigh in with ideas and opinions. Ideally, a team will be rewarded for their successes and feel the weight of their failures as a team, but this does not have to be in conflict with an organization recognizing that a particular person has achieved a level of skill or mastery in their job. The key is the way the responsibilities of that role are played out. When the team comes together, if we are Agile, we want everyone to feel empowered and responsible to contribute.

It’s like Uncle Ben says, “With great power comes great responsibility.”