Iterative vs. Agile

This article was originally published on Scrum Alliance website in October 2009

Recently, I happened to overhear and eventually involve myself in a conversation between two Project managers. They were discussing why Project managers have to define what “yes” and “no” means to the team – after all, people have understood these words since kindergarten. The story is very familiar to Project managers. Every week, team members report that their activities are on track; the project status is green, and everything is going as planned. Everyone is happy until the project is about three quarters complete, and suddenly one team member reports that he is not on track anymore. Suddenly, dates need to be changed and the schedule needs to be updated. The Project manager inevitably asks the important questions, “Why have you been telling me all along that you were on track?” “Have you been hiding something?” “Don’t you know, ‘yes’ means ‘yes?'” Obviously, the Project manager cannot go to the sponsor with the bad news, and the team has to work overtime to get the project back on schedule.

This reminded me of a story that Alistair Cockburn once told about a student trying to do his reading assignment. The student had to read a dozen stories and answer a few questions afterward. He had a week to finish this assignment. If I were the student, I would have spent every day just thinking about reading those books, and would have postponed reading each day until Sunday afternoon when I would cancel everything and start reading the first book. But this student was different; he was a good planner. Upon getting the assignment, he considered the size and difficulty level of each book and figured out he had to read a couple of books every day to have enough time to go through the questions and answer them. He spent three quarters of the week just reading those books. He was on track until he started looking at the questions. He then realized there were things he didn’t pick up on or pay close attention to when he was reading them for the first time. This meant he would have to re-read many of those books. This also meant he would have to spend a lot more of his weekend on his homework than he had planned. Good thing he had some contingency built in to his schedule!

Could he have done better by scheduling the work in a different way? What if he had quickly read one book, and then immediately looked at the questions? Then re-read, but this time paid closer attention to where the answers were coming from. What if he had changed his approach a little further? What if he had not read the books first but considered the goal – answering those questions. Why not read the questions first and specifically look for the answers in the books? Does this sound like test driven development (TDD)?

Let’s think about how the student measured his progress. In the original plan, he was checking off activities as done (reading each book) each time he finished a book. He was on schedule during the reading phase. But the real goal wasn’t reading books. He wouldn’t get any credit from his teacher for just completing the reading. His success was measured against how many questions were answered and how well he answered them. So measuring progress against reading wasn’t realistic. On the other hand, if he had reviewed the questions first, then read those books to answer the questions, and measured his progress against answering questions, that would have been a better measure of progress. If you think about this in the software development world, this is similar to an iterative process. You complete (read) a set of stories and go through the tests for just those stories. But is this approach good enough? Is this agile?

Let’s take this a step further. I realize this may not work well with the homework example, but bear with me. Imagine that the student has the option of taking a set of answers from one book at a time to the teacher and getting feedback. The teacher might have said that a one-word answer was not good enough, and that she was expecting a paragraph, or that she was expecting correct spelling. In this case, the student could have made some changes to the way he produced these deliverables (answers) and could have scored better on each subsequent book.

One could argue that the teacher should have defined all the success criteria (minimum number of words in the answer, no spelling mistakes, etc) at the beginning of the week so everyone would know what they were measured against. I agree; the teacher should have. Translating this to software development, one could argue for collecting all the requirements upfront and getting a sign-off from the user. Then again, we have seen so many times that requirements are a moving target. We can get sign offs and freeze those requirements, only to find that we have to make changes later. Sure, we can keep complaining about how changing requirements interferes with our plan. However, at the end of the project, we can call it a success only if we deliver what the customer really needs, not what we signed off to do in the beginning. We can do that only if we are open to change and if we are getting frequent feedback. Getting frequent feedback from the user and making changes accordingly is the heart of agile. It is not enough to iterate through user stories or components.

As for the developer in my first example who kept saying he was on track; he may not have been hiding anything or lying at all. He may have been just following the plan like the student reading the book and checking off activities on his schedule. Or he might have meant something that we hadn’t been paying attention to such as: “Yes, we are on track but I haven’t tested this with the other components.”

Sometimes the organizational structure and/or process do not lend itself to getting frequent feedback from the user. What do you do in that situation? Tell me a story about your project.

– See more at: https://www.scrumalliance.org/community/articles/2009/october/iterative-vs-agile#sthash.Jw9mxhUK.dpuf

Is Sustainable Pace Just Nice to Have? Think Again!

This article was originally published on Scrum Alliance website on May 2011

 

Most of the time, “selling” Agile is easy these days. Everyone agrees that iterative and incremental development is a better alternative; more user interaction is better; so on and so forth. At some point, I will talk about the importance of a sustainable pace. At that point, most will gloss over and some will simply say that it is nice! When I insist that it is not just nice but it is essential, some will respond: “Manoj, there is Agile and then there is reality” (That is actually a quote). Really? Is sustainable pace just a nice to have?

Sure, part of the reality is that our customer always wants to do more than we are able to deliver in a given time period and with a limited amount of money available. But isn’t that true with most things in life? When most of us (regular folks like me!) go shopping, we would like to buy more than what we are able to afford; but, then we settle on what we can afford based on what we have the money for and what our priorities are. Sometimes I need my wife to bring me back to reality! Shouldn’t we do a similar favor for our customer? What happens if we don’t realize our limits? Well, in the case of my shopping, I will get my credit card in high gear and buy all the golden eggs that I can at once. Eventually, reality will show up at my door step as a bankruptcy notice. Eventually, the goose that was laying golden eggs one at a time will get tired and die – or perhaps the goose might produce more eggs under pressure but those eggs will quickly start to deteriorate in quality.

Of course, there are some marketing folks who are going to promise more than the IT division can produce in a given period of time. Now, it is the IT team who will have to live up to their promises. How do we do it? Well, there is the scope, which we cannot go back and negotiate once it is promised. There is the schedule; also already promised and non-negotiable. There is cost; we have the maximum number of people already. There is only one way — our team will have to work more nights and every weekend. But, let’s be nice, during the weekend, the team should only work eight hours.

 

When we start a project, most of the time the team figures out that we are trying to accomplish a lot more than what we can do. Many a times, anyone who points out that fact will get a briefing on the reality that we don’t have any other way out. At this point, our optimistic nature takes over and we tell ourselves there will be a way to do it.

During the iterative/incremental process of working, we will start realizing very early in the project that the team can not complete all that we have promised. Our first reaction: try to stuff more and more into every iteration. We will avoid talking about how many hours team members are working and adopt the “Don’t Ask, Don’t Tell” policy. The team is smart; let them figure out how many hours they need to work – as long as they complete everything in the scope. Well, who decides what is in the scope for each iteration? Someone outside the team?

If we are to work this way, among many, I’d like to point out two impacts; one affects the short term and the other affects the long term prospect.

Short term

We have too many things on our plate in the current iteration. This means there is no time to look at what is ahead. Because of that, we begin the next iteration unprepared. We spend too much time figuring out what we are suppose to do and by the time we figure it out, the whole team would have wasted a significant portion of that iteration. No wonder we are not able to get everything done that we have committed to during the iteration.

Long term

When the team says they are not getting much sleep because we have a lot going on or in order to meet our sprint commitment, I start worrying – both for team members and for the system they are building. Late in the night, when that developer is trying to finish the code so the team can claim that story point, which task receives lower priority? Refactoring the code? Automating the unit test? Testing for all the alternate flows? Well, all of the above become a nice to have and quality is sacrificed to meet the schedule. A few iterations in that mode will create fragile code that will easily break. More on how to avoid messy code can be found at Uncle Bob’s article in January newsletter (see reference below).

Sure, the customer may not care if your employees are working long hours every day but have you talked to them about the quality of the code as a result? Try telling them the downside and they may start to care. In the long run, the customer will be the one to pay when they want to change the code for next release. Do you still think sustainable pace is a nice to have? Maybe we should check with our customer. Maybe they would agree that quality is nice to have too or maybe not. One thing is for sure, we shouldn’t make the decision for them.

 

Additional reading on Sustainable Pace

  • Vikas Hazrati in an infoQ article discusses whether Sustainable Pace means a 40-hour work week.
  • George Dinwiddie’s comments on Sustainable Pace

– See more at: https://www.scrumalliance.org/community/articles/2011/may/is-sustainable-pace-nice-to-have-think-again!#sthash.NjoHdgCg.dpuf

Deal with It

This article was originally published on Scrum Alliance website in Sep 2014

As the day goes by in a typical CSM class, I get a lot of “what if?” questions from students. Some of these questions go this way: “What if the product owner adds a new story or changes a story during the sprint?” or “What if a critical team member gets sick for several days during the sprint?”

A quick answer to these questions usually goes like this: “Deal with it.” Then I add, “Make sure this is brought up in the retrospective meeting so you minimize the chances of similar problems interrupting the next sprints.” Interestingly, toward the end of the class, when someone starts a question with “What if. . . ,” someone else will chime in, “Deal with it.”

Let’s look at the first question a little more deeply. In this case, you are on a team that is practicing Scrum. At the sprint planning meeting, the team created a forecast of how much work they could complete during the sprint. Sometime in the middle of the sprint, the product owner tries to add a new story or significantly change a story. Let’s assume that the forecast and the product increment for the current sprint are potentially in jeopardy because of this change. If that is not the case — for example, if it is a minor change or a small enough story — I would go ahead with the change, especially if it aligns with the goal of the sprint.

Usually, the first role to deal with this type of change will be the ScrumMaster. The ScrumMaster needs to protect the team from external interferences. As a ScrumMaster, that would be the first thing I would try to do. I would wear that “protector outfit” and stand between the product owner and the team and ask questions such as:

  • Is it really that important to make this significant change during the sprint?
  • What if we waited until the next sprint to include this change?
  • Let’s look at the task board together and learn more about our progress now and see the likely impact of this change.

Yes, responding to change is weighted more than following a plan. However, focus is also one of the values of Scrum. Also important is that the team works at a sustainable pace.

If the product owner still wants to entertain this change after considering the questions above, then it is the team that needs to deal with it.

Some of the questions I would ask the team (in no particular order) are:

  • Would the team lose focus by entertaining the inclusion of this story?
  • Does the story align with the goal of the sprint?
  • Do we know enough about the change/new story to assess its size and impact on the original goal/forecast?
  • By picking up this additional story, does the team have to work at an unsustainable pace? How was the pace of the last few sprints?
  • For the product owner, how important is it to include this story in this sprint? If it is important, is the product owner open to reordering existing stories?

Working with the product owner, the team now will investigate this further and come up with ways to deal with it. The outcome of this might be:

  • Yes, we will do it. (The team decided to just pick it up in the current sprint because the work is small enough and the change is important enough.)
  • Yes, and we will also make this additional change (such as removing a lower-priority story).
  • No, let’s add this as a possibility for the next sprint and include it in the product backlog refinement activity now.
  • Maybe we should have a team member or two investigate this further and make a decision later. (Remember, we will lose some focus if we do this.)

A very rare but a possible option is to terminate the current sprint and start a sprint planning session. The product owner is the final authority on making that decision.

Feeding the continuous improvement engine

In whatever way the team decides to deal with it, it is important that this event is brought up in the retrospective. Some of the questions that are to be considered in the sprint retrospective are:

  • Did this discussion about the change and actions take away significant time and focus from the team? (If not, we may not have to discuss it further.)
  • What event brought up the new information that resulted in this change or additional story? Is that event likely to happen again? How would we minimize this type of disruption?
  • Did we miss a stakeholder in our past backlog refinement meeting, or miss out on engaging them otherwise?
  • Is our sprint too long? If we had a shorter sprint, would the product owner likely have avoided interrupting the current sprint, instead waiting for the next sprint planning meeting to bring up his change?

At the retrospective, the team needs to identify some actions to minimize disruptions during the upcoming sprints. That is how the team improves its way of working. That is continuous improvement!

What is your experience?

How do you deal with changes? Tell us your experience. What questions or options would you include in the discussions above? – See more at: https://www.scrumalliance.org/community/articles/2014/september/deal-with-it-but-don%E2%80%99t-forget-to-feed-the-continuo#sthash.RJzrGq68.dpuf

Cargo Cult Agile

This article was originally published on Scrum Alliance in Dec 2009.

We have been saying “there are no silver bullets” over and over again. But do we really believe that? In some ways, it is like the disclaimer we add to the end our e-mails. Nobody reads it, but the legal department makes us put it there. Aren’t we (the IT industry) treating Agile like yet another silver bullet? Everyone wants to “adopt” it! Everyone wants to say that we are Agile! It is becoming more like a “Cargo Cult” (See Notes 1).

During World War II, materials such as food, clothing, and tents were airdropped to equip the soldiers and the natives in the Pacific Islands. At the end of the war, the soldiers went home and the air cargo stopped coming, but by then the natives were used to the airdropped materials. Soon, they dressed themselves as ground controllers, wearing carved wooden head sets and waving landing signals in the hopes that these activities would attract those cargo planes.

In some cases, it seems like we just have a need to say we’re using Agile practices, even if we’re really not. We don’t use those old school requirements documents anymore, instead we create user stories. We estimate in story points; Fibonacci series is fun, and so are poker cards! Sure, we do release planning. We also do a Daily Scrum; well, we cannot really do it daily because our team members already have too many projects and meetings, so we just meet twice a week. Regarding user stories, we have to write them down in the form of detail specification because our testing team is busy with other projects and not available for the first few months to really participate. Additionally, we are required to have those documents signed by all parties, scan them, and upload them to the document management system. Otherwise, how would we know what we agreed to?

So if we think adding a daily (or mostly daily) standup meeting, estimating in story points, and implementing a few other things we find in the Agile/Scrum books will save us, well, good luck! Like the Cargo Cult, we can keep wearing our wooden head sets, lighting those run ways, and hoping for the planes to land.

Like the Cargo Cult, we are getting some of those superficial elements correct. But can we really attract the cargo planes with those elements alone? Do we really know what problems we are trying to solve? Do we really understand what we are doing and why?

In order to solve problems in your organizations, you need to look inside, not outside, to adopt yet another practice, process, or tool. You need to look at what problems you need to solve and identify solutions to those problems. Certainly, Agile/Scrum practices are proven in the industry. So bring that knowledge to your organizations in the form of training, coaching, or hiring. They can seed some of the options to get to your solutions. However, the solutions need to come from within the organization. That should be what “adopting” Agile/Scrum means. These practices need to solve the problems and achieve your organization’s goals.

Here are some activities that will help you identify problems and move towards a solution.
1) Do some soul searching: One way of doing this is to have an open space meeting. (See Notes 2)
a. This will help you identify some of the problems you are trying to solve. (e.g. concept to cash takes too long)
b. Help identify some of the possible solutions. (e.g. remove some of the communication barriers)
c. Bringing people together will help the team take ownership of these problems and solutions instead of yet
another mandated process that comes from upper management
2) Create a Product Backlog of concepts that the organization wants to try to solve the problems.
a. Break those into tasks and assign resources.
3) Get senior management sponsorship.
a. There comes a time when you will have to rethink the organizational structure in order to solve some issues.
You can remove some of the organizational barriers only if you have senior management/leadership support.
4) Consider getting a coach, advisor, or someone who has done this before.
a. A good coach will be able to guide you to possible solutions for your issues. Instead of just “adopting” some of
those silver bullets like daily meetings and iterations, they will be able to guide you to solutions to the
problems. A good, experienced coach can reduce the costly expense of experimenting.

There are a lot of articles out there that will help you in this transition. A comprehensive analysis can be found in Succeeding with Agile, a new book by Mike Cohn.

Have you seen Cargo Cult Agile in action? Tell us about your experience with Cargo Cult Agile.

Notes

1. About Cargo Cult: http://en.wikipedia.org/wiki/Cargo_cult
2. More about open space: http://www.openspaceworld.org/cgi/wiki.cgi?AboutOpenSpace

– See more at: https://www.scrumalliance.org/community/articles/2009/december/cargo-cult-agile#sthash.znYCe9sO.dpuf