Make IT Work: Burndown should point down

Hi, my name is Markku Rontu, and I work as a Sustainability Engineer and Senior Software Architect at Nitor. Some people call me "Make," hence the name of this series. I have been working on Enterprison (pun intended) systems for over 20 years, and I wish to give you my 20/20 hindsight, or at least some tips and viewpoints to consider and have a laugh at.

My #2 tip is a rule of thumb that you can use to gauge success. As a product owner or buyer, how can you know it will work out this time and that you will get results? 

I have been fortunate to work in some fantastic teams. As an agilist, I can always see room for improvement and have seldom considered my work extraordinary. I know I do my part, and I've gotten used to success. I started to think that shipping code and delivering value were routine until I saw firsthand the other end of the spectrum. We can all read about failed IT projects in the media – some big and costly failures. It's not easy to predict how a project will go, but this rule is to help you. Visualize the work, calculate the burndown, and then:

Burndown should point down.

It's as simple as that! A good team can ship consistently, and the rest is details. Failure is often painfully obvious, in my experience, especially in outsourcing cases. In the Nordics, we have a high standard of teamwork, so the situation is less problematic and less clear. But occasionally, we get to dive into details, which I will discuss next

Expect difficulties if you don't get working code delivered in the first week or two. There is also a problem if you can see that you pile on more tasks than the team can solve. The tasks will start accumulating after a few sprints already. If burndown shows that the team does not get the job done, replace the team, cruel as it may seem at first.

But wait, you say, suppose the team does produce good features that they demo in a real environment (the only acceptable Definition of Done) but just not fast enough? In that case, you could be burying them with too much work that is likely not essential. It's indeed not always the team's fault. It could be the product owner not managing the backlog. Keep the focus, protect the team and help them do the essential tasks first.

An important reason for failure is that the organization can be such a mess of technology and practices that the team's skills are not aligned with the organization, or the team does not have enough local experience. Then you know that their skills and time are wasted. Be prepared to invest time and money for them to learn, or part in good terms, for it was not the right place or time. It means you have the wrong people or the wrong organization, and you can’t always change the latter.

Face reality. It's not a good team if they can't deliver solutions sooner rather than later. In my experience, the more agile organizations see the reality sooner and can adapt faster than organizations that are slow pyramids of bureaucracy and political games. I’ve witnessed downright fraud in the technical capabilities of consultants sent to do development work. This is something you will catch sooner by following the burndown rule. Paraphrasing the old saying, organizations get the results they deserve. In my experience, the bad teams were let go only after 6 to 18 months. All good teams showed results in the first sprint demo.

What is your pace? How long does it take for you? What is the team that delivers in your organization? I'd like to hear about it! Until next time.

P.S. Remember that you get what you measure. Also, don’t ever compare the burndown of two teams or even one team over a long period. Productivity will fluctuate as people come and go, and the so-called life happens.

When you hand good people possibility, they do great things

– Biz Stone

Symbols of productivity ARE NOT productivity.

– Richie Norton

Resources are hired to give results, not reasons.

– Amit Kalantri