You may have already heard people commenting that agile practices are hard or impossible to use in the "Real World", it usually starts like this: This is all nice, but in the real world...

There are always a huge list of excuses and exceptions why a company or organization cannot adopt all (or any) of the agile practices: there's no time, we have too many projects, too few developers/testers, we don't have money for training, etc...

In this short series I want to cover some examples of how to slowly adopt agile practices and get better at delivering value in any organization, even

The first technique is the most powerful one - the Burndown chart.

You don't need to have estimates, time boxes, definition of done or stable team, if you have a list of tasks that the team need to develop, you can make a burn down or burn up chart over time, and show to your team and managers what is the current status of the work, and a very accurate estimate of when (or if) all tasks will be done.

Every morning you count the number of tasks remaining, and put it on a big daily graph on a visible wall (if your project is really chaotic, this number of tasks will be actually growing daily, instead of going down). Once people start asking what is this paper, what are those numbers, and why does the graph does not reach the bottom, you can slowly introduce the team members to the agile ideas and practices, and suggest possible next steps.

Here you can see 3 of such burn down graphs. The first chart is totally cahotic, taking 8 weekly iterations (roughly two months), but on the second chart you can see some improvement (4 iterations, roughtly one month) and finally on the third chart the team almost hit deadline within 4 iterations, and in a more agile way.

This technique is really powerful, as it shows that you are dedicated to the team, project and to Agile, and can answer a very common question: "when will it be ready?" - after a few days you can have a guess of team velocity per tasks, and assuming tasks have similar size (same order of magnitude) you can have a good enough answer.  And as a bonus, this approach is one of the newest trends in agile: #NoEstimates.

What do you think of this approach? Is it doable, would you give it a try?
Share your thoughts in the commens.