This post focuses on simple practical rules (you may call them practices) for self organization. Every team is different, so these are just samples but I believe they provide a practical perspective that I have not seen enough of (please comment if there are other posts that provide practical guidance on self organization).
Sample Rules (or Practices)
- As a team member, I will contact the ScrumMaster if we can tweak a user story, to maintain its business value, while reducing time, cost or risk associated with implementing that user story.
- As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint.
- As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Product Owner, and all team members, whenever that feedback will help the performance of the team, even when I feel uncomfortable doing so.
- As an agile team, we will define and continually refine rules and practices and use them to guide us in our work.
Hopefully this short post was of value to you and your team. As a reminder, other than number four, these rules are just samples, so have fun creating your own and write back to tell us what they are and how they are working. Also comment if you have seen other blog posts that cover practical rules for self organization on an agile team.
Subscribe to the RSS feed
6 comments:
interesting technique. I'd say this is an elaboration of general principles for self-organized teams, as in this blog post: http://www.targetprocess.com/blog/2009/03/simple-rules-complex-systems-and.html
Olga,
The post you point to is interesting and worth a read, so I encourage others to read it.
cool article! i wish rule number one said i will contact my product owner versus scrum master. contacting the scrum master for a story change gives the impression that there is a hierarchy and that a team member does not have direct access to the product owner for something as important as tweaking business value.
Brandon,
The post does say these are examples so you can change it : )
Seriously though, excellent point, specifying the Product Owner is a better choice.
Don't agile processes have rules for self organization?
I agree with the point made above, agile does have built in rules for self organization. For example, we can consider the daily standup to be a self organizing rule.
Imagine you knew nothing about Scrum, could you follow this rule...
All the core team members will meet every day, stand up, and each of us will answers three questions:
What I did since the last standup.
What am I working on.
What roadblocks do I have.
During this standup we will focus on answering the three questions to the extent necessary to co-ordinate our work. We will finish in less than 15 minutes and as such we agree to defer problem solving and other details, to follow up sit down meetings.
Post a Comment