Entries

To manage a lazy team with a Burndown Chart???

Burndown Chart is a very common useful artifacts in Agile Software Development teams.

The main purpose of the Burndown chart is to keep track of the development progress and compare with what is planned at the beginning of the iteration.



However, this is not a mean to check if the team has (intentionally) selected less work than they are capable to complete.

Firstly, Burndown chart is not the artifact to blame the team for having "slow" progress. It is simply too late to realised that the delay existed where it showed no clue on why the delay existed.

Futhermore, if the team deliberately selected work that is less than they are capable of, the story points to finish in the "planned velocity" should also look "lower" than that if they planned to work in full speed. So, what would happen is the team is likely to finish the work they selected (since they should be more than capable to finish). The Burndown chart would then look very perfectly well. And this only leaves the PO obtaining small piece of done work by the end of the iteration. This is why Burndown chart is not the right artifact to check if the team selected less work than they are capable of.

Coping with a lazy team is a very often discussed topic in the Agile communities. I have basically two points on this:


  • Daily standup meeting - This is when each developer answers the question of what he/she did in the past 8 hours, what he/she plan to do in the coming 8 hours, and what are the obstacles he/she encountered.

    Product Owners are welcome to attend this meeting. This is an important way to build confidence with product owners and other project stakeholders that the team are fully committed in their work.

  • Questions - It is very true that ScrumMaster is not the person who dictate what the team does. I certainly don't expect a ScrumMaster could come out and say: "Hey, how come you signed up for that little work for the entire iteration?". However, ScrumMaster should ask questions when he/she notices something wrong.

    A team picking up sustainably less work than they should be capable of (in the sense of the ScrumMaster) is probably having some other problems behind. Asking questions could reveal more information what the team is thinking about the work they selected. This could be very fundamental reasons like they think they are working on something unfamiliar with; they could be under some other external pressure to avoid lagging behind in the Burndown chart; or simply some other authorities asked them to work on something else during that time.

It is very true that the ScrumMaster, nor the Product Owner, aren't dictating the team for how much work the team should complete in an iteration. Agile teams always rely on trust. At the same time, when it comes to the very worst scenario, the Product Owner always have the right to choose to finish the project after the end of the iteration as he/she has to be responsible for the ROI of the project.

Share with:
引用此文章(FC2部落格用戶)
http://stevenmak.blog124.fc2.com/tb.php/5-aa81009c

引用

留言

發表留言

發表留言
只對管理員顯示