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

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.

One of the interesting ways of measuring progress is through learning. At the start of the project we are faced with a number of unknowns. How much progress have we made towards resolving these unknowns? Thats one way to look at progress of a project.

So what does all this have to do with scope creep?

Scope creep is bad right? We all know that. It’s the first thing we’re taught. If you want to stay on time and on budget, then don’t let the scope expand. Common sense!

Except it might not always be.

Scope creep originally meant small, low priority items, that popped up here and there which would cause the scope to increase almost without anyone noticing (hence the term creep). These days it is applied to anything that causes the requirements to be changed.

Now if we look at a project from a learning perpective, one of the things to learn is to identify the actual problem and the right solution. And we learn this by putting out small releases and iterating on it. Thus everytime we get feedback, we are increasing the learning and progressing towards getting the right solution.

Each bit of feedback also causes scope creep as new requirements get added based on the new learning.

From a learning perspective, this kind of scope creep is actually good. It means we are incorporating the new knowledge, and making progress towards delivering the right software. But from a traditional cost & schedule perspective, it is bad. It makes a mess of the estimated cost and schedule.

This is one area where there is potential to trip up. Many companies are still fundamentally measuring projects in terms of cost and schedule and for them scope creep is really bad. This leads to a dysfunctional situation where an agile process is used, but feedback is not incorporated because it messes with the schedule. The end result is that you may end up delivering something, but the value delivered may not be all that much.

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?

The idea behind the demo

The idea behind the demo is to make progress visible. When the stakeholders see tangible progress in terms of working software they are more likely to have increased confidence in both the process and the progress. At the same time, if something could not be completed within the sprint, the demo makes it visible. By keeping the stakeholders in the loop, transparency and trust is increased.

So what could be the problem?

As I explained in my talk at Agile Bengaluru (Slide 13), one problem that we faced was we were too focused on building increments of software, and not nearly focused on putting it out into production and getting feedback.

We thought Scrum was about taking a piece of the backlog, and building it. Then take another piece, and build it. And so on, until the backlog is done. The thinking was “build increment, build increment, build increment.” Nowhere in the equation did we think about putting it into the hands of end users and getting feedback and changing the backlog.

Big mistake!

The demo reinforces dysfunctional behaviour

An end of sprint demo reinforces the “increment” notion. We do a demo not to get feedback but to show progress. “Here is what we built” we tell the stakeholders. Once the stakeholders are happy with progress (or not), we go back to building the next increment.

The demo is really too short to get any substantial feedback. Feedback, if any, is superficial – move this box there, change this colour.

Real feedback only comes when the end user uses the software in accomplishing real life goals. That takes time. Its not something that can be done in a small demo. Also note that feedback comes from the end user, not the product owner, not the paying customer. The only way to get this feedback is to put your increment of software out into production where real end users can use it.

Common sense?

It was a long time before I realised the mistake of not putting releases into the hands of the end user. When realisation hit, I slapped my forehead for overlooking such an obvious thing. “Duh, Stupid mistake” I thought.

However, talking to other teams, I realised that maybe its not so obvious after all. It looks like a lot of teams are focused on “build increment,” not so many on “release to end users and get feedback.”

Perhaps it’s time to get rid of the demo and replace it with a real release to end users.

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

The number of different answers illustrates perfectly that we don’t have a common understanding of velocity. Everyone knows how to calculate it, everyone knows how to use it, but we don’t understand the more fundamental question of what it is supposed to measure.

Let us take a stab at answering this question.

Is velocity a measure of value? This idea comes from the fact that we don’t get credit for partially complete work, thus creating the notion that velocity is measuring value. But clearly it is not. You can have large stories that deliver small value and small stories that deliver large value. Since velocity just aggregates the story points, it can’t be a measure of value.

Is velocity a measure of productivity? This idea comes from the fact that as the productivity goes up, you get more work done causing the velocity to increase. The other side is that the velocity often changes when there is no underlying change in productivity.

Is velocity a measure of capacity? This idea comes from the way velocity is used to plan the stories that can be scheduled in a sprint. But if velocity is a measure of capacity, then we should not cut the velocity for partial work and get a boost next sprint when a tiny bit of work is done to complete it. After all, if the capacity remains the same, then why should the metric change?

Now take a look at the ways velocity is used and the interpretation

• To plan the sprint: Velocity measures capacity
• To forecast releases: Velocity measures capacity
• No partial credit: Velocity measures value
• Trying to increase velocity: Velocity measures productivity
• Not counting bugs/refactoring in the velocity calculation: Velocity measures value
• Counting bugs/refactoring in velocity calculation: Velocity measures capacity

Notice an interesting contradiction there. Should you count bugs/refactoring work towards velocity? Some teams say no, because these don’t add value. Thats a value view of velocity. In this view, if I do a sprint of refactorings, my velocity will be zero. I can’t use that number for the next sprint planning, because sprint planning uses a capacity view of velocity.

Is velocity a useful metric?

I suppose velocity could be a useful metric, provided it is used consistently. The problem is that in different contexts it gets different meanings, often contradictory to how it is used in another context. Velocity also starts to break down when you start looking at special cause variations. For example, holiday seasons will have one-time low velocity, which should not really be incorporated into the next sprint.

Another problem is uneven work, for example in a maintenance project, you may have work for a day in one sprint, and for two days in another sprint. A flow based system is superior here.

Yet another problem is divided work, where someone works on two projects at the same time. The velocity could oscillate based on how time is divided among the projects.

So,

• if the team is stable
• and there is one project worked on at a time
• and special causes are not considered
• and there is enough work to use consistently the same capacity
• and velocity is applied with a consistent interpretation
• then velocity is useful

What is the alternative to velocity? I think Lead and cycle time are better metrics to look at. More on them in another post.

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.

I was recently reading the Aberdeen research report on The Value of “Agile” in a Distributed Environment (My thoughts on the report in another post). As I read the report I had a nagging feeling that a lot of people doing agile are missing the forest for the trees. Then I came across this definition of agile which confirmed my fears

Definition: Agile

The agile process for software product development is a philosophy and a collection of rigid procedures that enable a self-organized team of engineers to develop rapidly, and manage scope changes, functional and performance issues efficiently. Composed of a series of short “sprints” each punctuated by a functioning deliverable work product and including a daily stand-up meeting – a “scrum” – involving the entire team, agile delivers measurable results to project management frequently. A backlog of function (or story) points is maintained by the Scrum Master who produces a daily “burn-down” report to mark the progress of the team.

I’ve highlighted a few parts of the definition that are particularly troublesome.

• Rigid Procedures – Since when has agile been about rigid procedures?
• Manage scope changes – This term gives the impression that agile limits the amount of scope change, when in fact scope change is welcomed and is used as a leverage to deliver a better product
• Function points – Agile teams don’t track function points at all
• Maintained by the Scrum Master – The backlog is not maintained by the scrum master at all
• “Burn Down” report – The burndown is an indicator for the team to self organize, not a “report” for management to “mark the progress of the team”

What I see in this definition is all the values that are considered important in traditional PM translated into agile practices. Terms like “rigid procedures”, “manage scope”, “function points”, “mark the progress of the team”, these are terms that are important for a waterfall process.

But all this is missing the forest for the trees. In the bigger picture, the whole goal of software project management has been shifting over the past few years, from tracking tasks to delivering value.

Where do I see in the definition about “delivering continuous value”, “improving RoI”, “collaboration” and “increasing customer satisfaction”?

This is the big change in software development. People have been doing iterations and standups for decades. The single biggest development that agile brought to the table is to enable project managers to move away from thinking only about time and budget and start talking about the value side of the equation.

Yet, when I meet teams that claim to be “agile” all they can talk about is time and budget. They talk about managing the agile team, tracking the progress, measuring the burndown chart. Missing in the conversation is anything to do with improving RoI, or delivering better value.

If I ask most agile teams for their definition, chances are I would get a definition similar to the one above.

Are agile companies missing the forest for the trees?

A few days ago, the hard disk on my laptop crashed. I called up tech support and asked them to replace it. A technician came down and changed the hard disk and then proceeded to reinstall the operating system using the recovery disk provided by the manufacturer. Unfortunately the disk was scratched so the reinstall could not complete. Now instead of replacing the disk, the technician asked me to contact tech support and someone else will come down and provide a new disk. Knowing that the OS would have to be reinstalled, and something might happen, why didn’t he have a backup disk with him? So I have to make another call to tech support.

Executives see the rising number of calls and try to cut corners to manage it quicker, leading to.. even more calls. A broken process itself contributing to increasing the demand.

Thats failure demand.

So what does this have to do with agile teams?

Take a look at your backlog as it goes through a project. At the start of the project you would have all new features on the backlog. Somewhere along the way a few bugs start to appear as some conditions were not tested. You may also have a few change requests as features may not be exactly what the stakeholders had in mind. Thats ok.

But what happens next? In order to manage the bigger backlog the team starts cutting corners. Maybe more features are handled in a sprint, and there isn’t enough time to test them all. Suddenly you start seeing a whole lot more bugs and change requests. Suddenly the backlog starts increasing rapidly. All this is failure demand. While dealing with this the team cuts even more corners and you start seeing a new type of failure demand as refactoring tasks start going onto the backlog.

The team has two choices now – cut back on the velocity and fix the process, or cut more corners as you try to cope with the ever increasing backlog. Ironically, the second option only makes things worse.

So take a look at your backlog today. How much of it is value adding work? How much of it is failure demand?

Many teams find that the amount of failure demand exceeds value adding work. Don’t think about how you are going to handle it. Instead, think about how you can improve your process to prevent it from coming in the first place.

A lot of people think agile is something that it is not. So I thought I’d list three things that agile is not.

1. Agile is not a way to make development less diciplined: In fact, doing agile well requires more discipline than normal. Apart from cranking out code, you may have to do unit tests, refactoring, continuous integration, constant prioritization, one-piece flow. All these take discipline to do. If you think that you want to shift to agile because it’s less work, then you may want to rethink.
2. Agile does not mean you work without direction: If you thought that Agile means you can get started immediately, then think again. Sure, you don’t need to know the complete requirements before starting out. But you should at least be reasonably clear on what you hope to accomplish in the next sprint, even if it just means spiking out different possibilities. Some agile teams spend many sprints going here and there without any idea of what they are trying to do. Sometimes it is better to sit still than dash around aimlessly.
3. Agile does not mean there are no managers or leaders: Yes, Agile processes emphasize empowered, self-organizing teams. But that does not mean there are no managers or leaders. Every good team has good managers, who ensure that everything proceeds smoothly. Every good team has a good leader who can set a vision for the team. Don’t micromanage your team, but don’t leave them in the lurch either.

Got any more? Add it to the comments below.

Kevin Mullet was in Chennai yesterday and he gave a talk on User Experience Design. Thanks to Serendio for organising the talk. I’ve attached below a mindmap of the talk based on my notes. Click the image to see the whole mindmap.

There is a discussion going on in one of the Scrum lists about compensation in a scrum team. How do we reward individual performers when Scrum plays down individual performance?

It’s a mistake to think that rewarding individual performers does not work in a Scrum team. Forget Scrum, it does not work anywhere in the organization!

As much as thirty years ago, Deming listed as Deadly Disease #3 – Evaluation by performance, merit rating, or annual review of performance

This is because performance evaluation kills cooperation, morale and intrinsic motivation. Individual performance appraisal in particular can kill team cooperation. Why should I share knowledge if it would improve other team members appraisals relative to mine?

A particularly bad thing to do is stack ranking, i.e ranking everyone in order from best to worst. In a competitive environment, there are two ways to win – get better or keep others down. Which one is more common? The easiest way to get to the top of the stack is to keep knowledge to yourself.

Now, are these the kinds of behaviour that organizations want to encourage?

Consider this Harvard Business School case study on Hewlett-Packard.  When HP moved to a pay-for-performance system in the early 90s, this is what happened

The teams were frustrated that factors out of their control, such as the delivery of parts, affected their work. The high-performance teams often refused to admit people whom they thought to be below their level of expertise, leading to disparities among the teams. There was reduced mobility between teams, preventing the transfer of learning across teams. Employees built their lifestyles around the higher level of pay, and were angry when they could not achieve it consistently.

The case study also says “pay-for-performance can cast a pall over self-esteem, teamwork, and creativity” and “scholars have argued that the real problem is that incentives work too well. Specifically, they motivate employees to focus excessively on doing what they need to do to gain rewards, sometimes at the expense of doing other things that would help the organization.”

More recently, Jeffrey Pfeffer testified in the US Congress on Personnel Reform. He said in his testimony,

There are numerous examples of widely diffused and quite persistent management practices, strongly advocated by practicing executives and consultants, where the systematic empirical evidence for their ineffectiveness is just overwhelming. Third, the idea that individual pay for performance will enhance organizational operations rests on a set of assumptions. Once those assumptions are spelled out and confronted with the evidence, it is clear that many — maybe all — do not hold in most organizations. Fourth, the evidence for the effectiveness of individual pay for performance is mixed, at best — not because pay systems don’t motivate behavior, but more frequently, because such systems effectively motivate the wrong behavior. And finally, the best way to encourage performance is to build a high performance culture.

Finally, a quote from the classic Peopleware book,

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:

• Annual salary or merit reviews
• Management by objectives (MBO)
• Praise of certain workers for extraordinary accomplishment
• Awards, prizes, bonuses tied to performance
• Performance measurement in almost any form

Another book that comes to the same conclusion is Alfie Kohn’s Punished By Rewards.

Coming back to agile teams, here is a must read article by Mary Poppendieck on the subject – Unjust Desserts (PDF)

In the “old world” there was a certain flow that information would take.

Say you are a developer and you had a question regarding the testing. You would bring up the issue with the development manager. The dev manager would bring it up with the test manager in the next meeting (you, of course, were not invited). The test manager would ask a tester. Then the information would flow back in reverse until you got your answer.

You <-> Dev Manager <-> Test Manager <-> Tester

What if you had a question for the customer? Then it would be something like this

You <-> Dev Manager <-> Analyst <-> Customer

There are rather obvious sources of waste here. The Dev Manager is a bottleneck to the the entire conversation. Not surprisingly Agile processes disbanded the middlemen. So it is encouraged that the information flow is like this instead

You <-> Tester

You <-> Customer

All well and good. Conversations are better and waste is eliminated.

However, I’m noticing a pattern emerging, especially between onshore-offshore teams that have adopted agile recently.

Lets say you have a blocker that needs an input from a team member in another team. The information flow is like this – You’re stuck on something, so you raise an impediment. The ScrumMaster takes the impediment along to the Scrum of Scrums where it is passed on to the other ScrumMaster. The other ScrumMaster gets the answer from the team member and passes it back. Impediment closed. In other words

You <-> Your ScrumMaster <-> (Scrum of Scrums) <->  Other ScrumMaster <-> Team Member

Look familiar?

Similarly, many teams are touchy about giving the team member access to the customer or even the Product Owner (especially if they are remote). So the information flow is like

You <-> ScrumMaster <-> Product Owner <-> Customer

Hmm. Anyone see the parallels?

You <-> Dev Manager <-> Test Manager <-> Tester

You <-> Your ScrumMaster <-> (Scrum of Scrums) <->  Other ScrumMaster <-> Team Member

or

You <-> Dev Manager <-> Analyst <-> Customer

You <-> ScrumMaster <-> Product Owner <-> Customer

Are ScrumMasters the new bottleneck?

There is no way to succeed without good teamwork. Agile requires a collaborative environment in which a cross-functional team can work together. So here are five articles on teamwork from an agile perspective.

• Agile, Multidisciplinary Teamwork: A good article on how to get a diverse cross-functional team to work well, keeping them energized and productive.
• Seven Essential Teamwork Skills: Seven soft skills that every team member need – Active Listening, Questioning, Logical Argument, Respecting, Helping, Sharing, Participating.
• The Seven Pillars of an Agile Team: What are the abilities that team members need to posses? Product Sense, Collaboration, Focus on Business Value, Supportive Culture, Confidence, Technical Excellence, Self Improvement.
• How Not to do Resource Management: An excellent article on creating agile teams: Instead of assigning people to a project, keep the team constant and assign projects to the team.
• Meeting Facilitation for Agile Teams: Facilitation skills for meetings, retrospectives, standups and planning workshops.

I’ve found that the concept of Story Points is one of the most confusing for people to understand. People are so used to estimating in real time – days and hours – that the abstract nature of story points is a bit hard to grasp. To make matters worse, there are different and sometimes contradictory ways of thinking about points. Here is how I think about story points

• Story points are a measure of size, not time or effort. This is a change in perspective for many teams since they are used to thinking in terms of real time. Here is an analogy to explain the difference: Suppose I ask “How long will it take to go from home to office tomorrow?” The answer is that is depends – depends on whether you take a car or bus, depends on the traffic and a host of other random factors. On the other hand, if I ask “What is the distance between home and office?” then the answer is a constant. No matter what the mode of transport or the traffic, the distance remains the same. Story points are like estimating the distance. They remain the same, no matter who is working on the story. The actual time taken may vary based on many factors. The person working on the story, meeting time, wasted time, all contribute to the actual time taken, but the size still remains the same.
• Story points are relative. In regular estimating you estimate in absolute units or days or hours. With story points you pick a reference story and measure everything relative to that. This works out better because people are better at relative comparisons. If I give you a box and ask the weight, it is difficult to estimate it very well. Given two boxes it is easier to say that one is double the weight of the other.

Whenever I get a question, I try to keep in mind: Story points are like estimating distance, and story points are relative. In a future post I’ll write about how this helps resolve some common questions.