Working in an Agile team?
Silver Catalyst is a lightweight project management tool for agile teams. Check it out!

Is Shu-Ha-Ri harmful?

Posted on March 5th, 2010 in Agile by siddharta || No Comment

Christian says in his post that Shu-Ha-Ri is often misunderstood as a reply to Rachel’s Shu-Ha-Ri considered harmful. I agree with what Christian says.

Why we need guidelines

On the scrumdevelopment yahoo group, there was a discussion a few weeks ago on whether technical practices, for example continuous integration, should be taught in Scrum. Someone wrote “Scrum should not introduce technical practces. Any responsible adult after seeing the output of a couple of sprints will inspect and adapt by themselves to introduce continuous integration.” Sorry, but thats complete crap.

Most beginners have no idea about continuous integration, what it is, how it can help, how easy or tough it is to get started, what are the prerequisites, what is the expected return and so on. Instead, the coach, or someone who understands the context has to make the choice and tell the team that this is something you need to do.

Only after some months of doing agile will the team get the understanding to be able to make such decisions by themselves.

Appropriate guidelines are the key

The Shu-Ha-Ri model says that a new team should just follow the rules. The key thing here is that the rules are not just “by the book.” As Christian says, the coach should tell you what makes sense in your context. Then the team follows it. The team still doesn’t have the understanding to decide whether to do something else or not. They still don’t understand the context and its impact. So they rely on the coach to give out an appropriate set of rules that can be followed.

This is different from doing it “by the book”. When you do it by the book, the rules may be completely inappropriate for the team’s context. In this case the team will just get into a whole lot of trouble. Because they are beginners, they will neither know what the problem is, nor how to get out of it.

Learning to play bridge

Sometimes it’s tough for people experienced in agile to appreciate the beginners mind. Once you are experienced, there are no rules. The answer for every question is “it depends on the context.” But that is not an answer that helps a beginner.

A simple way to get back into the beginners mind is to learn something new and see your own thought process. I’m learning bridge. Like everything else, there are some guidelines on how to play in different situations.The guidelines are not foolproof. There are many situations where it is better to break the guideline. But following the guideline will work in the majority of cases.

For a beginner, it is best to simply follow the guidelines. You will make the right choice most of the time. As you get better, you will start to understand where the guideline works and where it doesn’t. But you learn this only by following the guideline and making the wrong choice. An experienced player already understands all this and will use a lot of judgement and will break the guidelines often.

If a beginner tries to behave like an expert and break the guideline without sufficient understanding, they will actually do worse than a beginner who just blindly follows the guideline in every situation.

Summary

  1. Guidelines are important for beginners
  2. Guidelines should not be “by the book,” but should be customised by a coach to suit the context of the team
  3. The answer to every question is “it depends on the context,” but that answer doesn’t help a new team
  4. If beginners try to behave like experts, they will do worse than if they had just followed the guidelines
  5. As beginners understand the process, they can start taking decisions themselves

Is scope creep bad?

Posted on February 19th, 2010 in Agile, Lean, Methodology by siddharta || No Comment

I recently gave a talk on 5 pitfalls in agile development. One of the points in the talk was about how traditional methods focused on managing projects by cost and schedule, whereas agile methods looked at other ways of measuring progress. For example, working software is held as a primary measure of progress. So is delivering business value.

Continue reading ‘Is scope creep bad?’ »

Questioning the end of sprint demo

Posted on February 1st, 2010 in Agile by siddharta || 1 Comment

Scrum prescribes this little ceremony at the end of the sprint called “the demo.” The idea of the demo is to show the stakeholders what was built during the sprint. What can be wrong with that?

Continue reading ‘Questioning the end of sprint demo’ »

Is velocity a useful metric?

Posted on January 28th, 2010 in Agile by siddharta || 2 Comments

In my talk at Agile Bengaluru, I asked “What is velocity? What does velocity measure? Is it useful?”

What is velocity?

Everyone was united on this – velocity is the aggregate of story points (or any estimate unit you use) completed in the sprint.

What does velocity measure?

I got a bunch of answers for this

  • Velocity measures the amount of work (capacity) you can do in a sprint
  • Velocity measures the amount of value delivered in the sprint
  • Velocity measures the productivity of the team

Continue reading ‘Is velocity a useful metric?’ »

Evolving from ad-hoc to Agile to Kanban

Posted on January 25th, 2010 in Agile, Kanban, Lean, Silver Catalyst, silverstripesoftware by siddharta || 3 Comments

This is the presentation I gave at Agile Bengaluru 2010 this past weekend. It describes the journey moving from ad-hoc development to an agile process and how we then adapted it to a more Kanban like process. The bad news is that you can’t really make out much with just the slides as the commentary is not there. The good news is that the session was recorded, so I’ll post it up once the recording is made available. In the meantime, here is the presentation.

« Previous Entries