tag:blogger.com,1999:blog-21080042.post8824147562696068401..comments2024-03-17T17:03:47.760-07:00Comments on Agile World: Self Organizing teams and New York soda banVenkatesh Krishnamurthyhttp://www.blogger.com/profile/11471239057569635943noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-21080042.post-30104334523586329732013-04-07T23:45:46.862-07:002013-04-07T23:45:46.862-07:00If i would have been in scrum master's positio...If i would have been in scrum master's position I would not have stopped the team from doing what they want to do. However, as a coach, I would have definitely challenged them and "make them think" about how & when would they reflect on their learnings, how & where would they capture those learnings and action items, how and when would they communicate it to the entire team, how would they measure their change etc... These questions are the essence of retro. If the team has thought through these questions, if they do have a concrete & better plan, if the entire team agrees and is willing to experiment, then by all means I would not stop them. <br /><br />You said scrum master would coach the team to follow the rituals. Or to follow the "rules". Thats the issue I have with your post and thoughts. <br /><br />There is a difference between coaching and mentoring or being a watch dog. Coaching is about asking solution-focused powerful questions that helps an individual or a team to step back and think through, have a different perspective, have a broader vision. Coaching is all about helping someone "think for themselves and not to think for them instead". <br /><br />There is also a difference between being agile and agility. You must have heard of ShuHaRi. The three stages of learning. Someone new to agile or scrum might start by following "rules by book". But once they start understanding why they are doing what they are doing, it is scrum master's job (and company overall) to make a fail-safe environment for team and let them loose; to experiment. By fail-safe I mean 'it is ok to fail. it was an experiment after all'. That is your Ha state. <br /><br />From your post it seems you do want your team to move beyond Shu state. You do want your team to experiment, to fail and to learn from failure. <br /><br />Observe and reflect closely and frequently to the team as a scrum master and coach so that they do not fail too much too often. But by all means let them decide and self-organize and fail and learn from it. Most of the times, they would not fail (with a good coach / scrum master who would help them think through it thoroughly)<br /><br />For example; when I was working with ThoughtWorks, our team decided not to do any sprint planning. In fact remove the concept of sprinting. They wanted more of Kanban pull flow in place in between of the project. But the team had a plan for how to reasonably predict release dates, when and how to give feedbacks and when and how to retro. We experimented and it was a huge success. To give you an idea (though I am against measuring team success using velocity) our velocity went up from 6 to 8 SP to 12 to 16 SP per 2 weeks. Somewhere team sought freedom from their past performance (velocity) by not doing doing sprint planning, though scrum says "do sprint planning".Anonymoushttps://www.blogger.com/profile/15991695661430687950noreply@blogger.com