In a recent project the tasks were always delegated and pointless deadlines set on everything. This seems so counter productive and ineffective compared to my past 5 years of agile based projects (inc maintenance).
As for task delegation I will need to evangelise more about the benefits of self organising and ownership through bottom up delegation, WIPs, velocity projection, prioritisation benefits etc.
My current beef is about noisy deadlines. Deadlines are for product owner / project managers. The team should never need to deal with deadlines. Especially when not meeting them has no consequence, so why have them at all? The team deals with prioritised tasks and if needed time boxed tasks. The tasks are divided up so that they are small enough so that a slip of 300% from estimation has no really impact as you are only talking about hours or days. However if the project velocity overt time does not seem to meet external deadlines then the scope of the backlog need to change, not to push developers/testers harder.
In agile teams they should not confuse deadlines for an estimation of how much work is left. If your current task may seem like another 2 days worth of work, do not set a deadline in two days. You may have interfering meetings or get stuck on a small issue that extend that tasks into next week. (Or hit an coding-happy-zone or eureka moment and finish in a few hours). Setting a deadline do not make you finish earlier and pushing developers/testers harder does not improve code quality. A task based deadline is only noise and stress.
Product owners can plan, communicate, etc with dates to customers, company boards or steering groups etc but they should be soft, movable dates and based on current project velocity, and no minor deadlines. If the velocity slows down, then reduce the scope of the backlog, or move the dates. Do not put pressure on the team with more micromanaged deadlines. It will only be noise and slow down development. The team does not really need to know specific dates apart perhaps from general roadmap (lavalamp?)for big releases.
True, some dates can not be moved, such as Christmas promotions, larger entities' deadlines etc, but with enough balls you would be surprised how many customer, senior management deadlines can be moved with good communication, even completely removed. Good project transparency and communication, and thus project velocity visibility is usually a much bigger relation and delivery benefit.
I agree that some pressure of delivery should exist but no cutthroat stress inducing deadlines. An agile process of pride in delivering tasks may quickly vanquish need for deadlines.
As for task delegation I will need to evangelise more about the benefits of self organising and ownership through bottom up delegation, WIPs, velocity projection, prioritisation benefits etc.
My current beef is about noisy deadlines. Deadlines are for product owner / project managers. The team should never need to deal with deadlines. Especially when not meeting them has no consequence, so why have them at all? The team deals with prioritised tasks and if needed time boxed tasks. The tasks are divided up so that they are small enough so that a slip of 300% from estimation has no really impact as you are only talking about hours or days. However if the project velocity overt time does not seem to meet external deadlines then the scope of the backlog need to change, not to push developers/testers harder.
In agile teams they should not confuse deadlines for an estimation of how much work is left. If your current task may seem like another 2 days worth of work, do not set a deadline in two days. You may have interfering meetings or get stuck on a small issue that extend that tasks into next week. (Or hit an coding-happy-zone or eureka moment and finish in a few hours). Setting a deadline do not make you finish earlier and pushing developers/testers harder does not improve code quality. A task based deadline is only noise and stress.
Product owners can plan, communicate, etc with dates to customers, company boards or steering groups etc but they should be soft, movable dates and based on current project velocity, and no minor deadlines. If the velocity slows down, then reduce the scope of the backlog, or move the dates. Do not put pressure on the team with more micromanaged deadlines. It will only be noise and slow down development. The team does not really need to know specific dates apart perhaps from general roadmap (lavalamp?)for big releases.
True, some dates can not be moved, such as Christmas promotions, larger entities' deadlines etc, but with enough balls you would be surprised how many customer, senior management deadlines can be moved with good communication, even completely removed. Good project transparency and communication, and thus project velocity visibility is usually a much bigger relation and delivery benefit.
I agree that some pressure of delivery should exist but no cutthroat stress inducing deadlines. An agile process of pride in delivering tasks may quickly vanquish need for deadlines.
- agile-commentary.blogspot.com/2009/06/are-deadlines-important.html
- developers.slashdot.org/story/06/09/28/1242257/Good-Agile-mdash-Development-Without-Deadlines
- steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
- www.slideshare.net/jurgenappelo/agile-management-authority-delegation
- www.noop.nl/2009/10/why-we-delegate-the-darkness-principle.html
- www.informit.com/articles/article.aspx?p=1675546&seqNum=6
- blog.adsdevshop.com/2010/02/09/task-delegation-has-no-place-in-agile/
- stackoverflow.com/questions/63100/scrum-process-management-tips-pitfalls-ideas
Unless otherwise specified, all content is licensed under Creative Commons by Attribution 3.0 (CC-BY).
Externally linked images and content are not included and are licensed and copyrighted separately.