It's tempting to micro-manage anything not producing what we want.
Sometimes it's appropriate. For example, if we're trying to maximize the power of a race car, there can't be anything about the car which isn't highly measured/controlled. Cars have to be micro-managed because they perfectly do what they're told. In other words, all our mistakes are its.
On the other hand, people function best when they understand (and are accountable for) a goal and have the freedom to find the best method. It's better to micro-measure business value (which stakeholders define through acceptance criteria) than story points and velocity.
Scrum is about ensuring people have a common understanding at critical points in time:
(1) Release Planning - Does the team understand what it needs to solve over time?
(2) Sprint Planning - Does the team understand what it needs to solve in the short term?
(3) Story Tasking - Does the team agree on the best software design to deliver the solution?
(4) Daily Stand-up- Does the team understand what others are working on today?
(5) Sprint Demo - Will the solutions delivered by the team solve the problems of the product owner?
If the team isn't delivering solutions which remove business problems (determined in step 5), the scrum master and team members should identify the root cause why it's not working. Product owners should hold teams and scrum masters accountable which means failure is shared and not transparent (micro-managed) down to the individual team member.
No comments:
Post a Comment