實施Scrum的經驗談
When is Scrum not Scrum?
http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/
February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts
作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.
1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.
2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
*Ease and accuracy of burndown
burndown on tasks rather than hours
making the whole process binary: a task is done or it is not done
*It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.
When is Scrum not Scrum?
http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/
February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts
作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.
1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.
2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
*Ease and accuracy of burndown
burndown on tasks rather than hours
making the whole process binary: a task is done or it is not done
*It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.
全站熱搜
留言列表
