Project Management

Home / Blogs / The Reluctant Agilist /

The Reluctant Agilist

About this Blog

RSS

Categories

Date

newer posts

older posts

Following up on Commitment, Evolution and Britney Spears

Categories: Agile Practice, PMBOK, Waterfall, Scrum

Since I posted my comments on the change to the Scrum Guide, I have had the chance to teach two Certified Scrum Master classes. Despite my issues with the change, my desire to be transparent about things won out. I am still teaching commitment and explaining why, IMHO, it is so critical to the Team. However, I am also explaining the change in the most recent Scrum Guide and the argument for use of the word “forecast”. In both cases this has generated some healthy discussion within the class and my hope is that the participants will leave the class well enough informed to make up their own minds about it.

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?

Posted on: August 23, 2011 11:50 AM | Permalink | Comments (2)

Where’s the Commitment?

Categories: Scrum

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

Posted on: July 26, 2011 02:01 PM | Permalink | Comments (5)

Leaving the Cave

Categories: Agile Transition

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

Posted on: June 25, 2011 01:47 PM | Permalink | Comments (2)

The Mark Inside

Categories: Agile Transition, Agile Practice, Scrum

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

Posted on: June 07, 2011 04:40 PM | Permalink | Comments (2)

Review Meetings - The Weight is a Gift

Categories: Agile Practice, Scrum

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.

Posted on: May 23, 2011 10:20 AM | Permalink | Comments (4)

newer posts

older posts

The Reluctant Agilist

About this Blog

RSS

Recent Posts

Categories

Date

Following up on Commitment, Evolution and Britney Spears Categories: Agile Practice, PMBOK, Waterfall, Scrum

Where’s the Commitment? Categories: Scrum

Leaving the Cave Categories: Agile Transition

The Mark Inside Categories: Agile Transition, Agile Practice, Scrum

Review Meetings - The Weight is a Gift Categories: Agile Practice, Scrum

Sponsors

Vendor Events

Guessing is not a strategy: How to build decision velocity with AI and real-time data

Newsletters

Following up on Commitment, Evolution and Britney Spears

Categories: Agile Practice, PMBOK, Waterfall, Scrum

Where’s the Commitment?

Categories: Scrum

Leaving the Cave

Categories: Agile Transition

The Mark Inside

Categories: Agile Transition, Agile Practice, Scrum

Review Meetings - The Weight is a Gift

Categories: Agile Practice, Scrum