Delay your project, protect your future

One of the dangers of Agile is that teams are so busy sprinting and delivering potentially shippable projects, that they forget to invest in becoming more productive in the future.

Let's use some basic economics to illustrate this problem.  Assume your team has a top productivity of X. It doesn't matter the unit you pick - story points per iteration, function points per month -  but let's assume your team cannot produce more than X.

Now, one of the things you can do with productivity is move it around. For instance, google allows employees to invest part of their work week on pet projects. So if we put that on a vertical axis, we get something like this:

This curve is called a Production Possibility Frontier, or PPF, and it represents your team's limit in terms of productivity. This means the only way you'll make your team more productive is by moving the PPF! And the way to achieve this is through investment.

You may argue that google pet projects are an investment, but what I mean is direct investment in improving productivity. For instance, you could invest in improving your QA infrastructure, so that developers don't spend so much time building and fixing tests. Or you could invest in tools to improve your overall capacity to deliver, like the OutSystems' Agile Platform. (disclaimer, I work for OutSystems! ;).

When you do this type of investment, the end result is that you move the PPF to the right, therefore increasing your team's capacity to deliver.

Easy, right? So why isn't everybody doing these investments and increasing their productivity? Why do we meet so many inefficient teams and R&D departments?

Turns out there is a catch. These improvements are not continuous, and work in leaps. This means you need to go all the way to see the results of your investment. If you study a new tool for a couple of weeks and stop the investigation before something actionable comes out of the study, you're just throwing your time and money out the window...

But guess what happens as soon as a the project stars to slip? We choose the short term solution, and increase the productivity of the team at the expense of our investment.

Standing up to your stakeholders and delaying a milestone to protect your future is the hard part in making your team more productive. And I hope this short post gives you a bit of ammunition to go in the right direction! :)

What's wrong with ScrumBut?

When I talk to other Agilists about SCRUM, I usually get two very extreme reactions to this methodology:

On one side, I get people that say you've got to follow all the rules. That's what SCRUM is! There is no but!

On the other side, I get people saying that there's no such thing as a one size fits all methodology, so you always need to adapt SCRUM for your particular scenario.

Now, I don't agree that you need to blindly follow all the rules of SCRUM. That's not Agile at all... remember the 1st rule in the Agile Manifesto?  "Individuals and interactions over processes and tools". Seems clear to me that, if your team agrees that some part of SCRUM can be improved, the Agile Manifesto is there to back you up.

But...

Just because it is ok to change SCRUM, doesn't mean you should. Failing to properly implement SCRUM is not a valid excuse to change the process "to fit your organization". That's the the type of attitude that gives ScrumBut a bad name!

Before adapting SCRUM to your organization, you need to implement and use original SCRUM for a while. It's only when you finally get SCRUM running smoothly on your organization (and that will take some time!) that you and your team can move to phase 2: Analyze the process, do retrospectives, and improve the process to better suite your needs.

And that's when the real fun of Agile and SCRUM begins!

Sprint review meeting: It's all about Marketing!

I attend a lot of Sprint Review meetings, and sometimes I leave those meetings a bit sad...

It's not that the team hasn't done a great job! Quite the opposite. The teams I work with do miracles! But, like most engineers, they sell themselves short.

Sprint Review Meetings are all about Marketing! Your team needs to sell the work done during the Sprint to the audience!

Here are a few tips to effectively market your work:

• Show the value of what you did: Don't explain how you did it, and don't go into excruciating technical detail about what you implemented... explain the benefits of what you did!
• Do: "By improving the reticulating splines performance, customers have a much smoother checkout process"
• Don't: "We improved reticulating splines speed by using a really smart b-tree structure"
• Make a big fuss about what you did: Don't hide the great work you did in a bullet list with all the details of the Sprint. Pick 3 to 5 key points, and make a slide for each of them.
• Do:
  
• Don't:
  
• Make a real world demo: Be smart with your seed data. Use real data whenever possible, or some really clever examples to make your demo more effective.
• Do: "Peter Smith bought a Mega Chair and paid it with a Visa card"
• Don't: "Customer A bought Product 1 and paid with card X"
• Talk about the entire Use Case: Even if you don't demo it all, explain how the user got to the point of the demo and what the user is trying to achieve. It will make understanding your demo much easier.
• Do: "Peter Smith was navigating at our web site to buy a chair. He did a search for chairs, and clicked the 1st result on the list. What you see here is the page present to him at that stage."
• Don't: "Assume Customer 1 is at this page"
• Make a clean demo: The demo should be as near to reality as possible. Avoid launching the command line, use batch files, or employ other kind of odd gizmos during your demo.
• Don't dwell on what you didn't do: If your team made a commitment to this sprint that it wasn't able to keep, mention it, give a one sentence justification, and move along. Be prepared to answer any questions that may arise, but don't spend the time you have to talk about what you did, speaking about what you didn't do.

What other tips would you add to this list? How do you turn your Sprint Review meetings into huge successes?

The Secret of Agile Speed

Here's an introductory video on how Agile improves your projects' speed.

Reading burndown charts

Burndown charts are a fairly common tool used in Agile projects to measure the velocity of a team. It usually contains two sets of data, the actual missing effort and the expected missing effort.

The thing is, looking at a burndown chart is useless, unless you have a very good understanding of what’s going on with the project.

Here’s a sample of a burndown chart:

At first glance, it seems things aren’t bad. Although there is a “saw” look to it, every couple of weeks things go back to normal. The drops seem to occur at the end of each iteration (assuming 2 week iterations). But the thing is, the chart doesn’t show us why the drops occur!

One reason might be poor self management by the team. They only close the stories at the end of the iteration. This is a good scenario, because it means you can quickly coach the team to have more fine grained stories, so you can have better visibility on the project.

Another reason for these drops might be that, at the end of each iteration, the team reviews the backlog and realizes it will miss the date. With that in mind, they remove the last items from the backlog, and the project gets back on track. This is way more problematic!

The team is assuming the project is about 1/2 weeks late (marked by the dotted red line), so they cut 1/2 weeks worth of work from the backlog. But the reality is that the project is 5 weeks late! (marked by the dotted blue line).

The consequence of this is that the team will have to cut about half of the backlog to finish the project on time! This can obviously have catastrophic implications for the project....

There are several ways to deal this problem, but the important thing is that action is taken as soon as possible. And to be able to quickly understand what is going on, you cannot trust on the burndown chart alone. You need a very good understanding of what is going on with the project.