In my last blog, I stated that a Scrum Master that truly understands Scrum attempts to create "...a process /atmosphere of empowered optimizing evolving value delivery". When you say it out loud, it does sound like a bunch of buzzwords strung together, like leveraged synergies or synergized leverages. However, honestly, it does mean something.
Empowered - The process should be empowering. The Scrum process is not one where the team is treated like a bunch of mushrooms (kept in the dark and fed, ummm, dung), but rather it should be an open transparent atmosphere. It's a atmosphere where the team is not ordered and micromanaged, but rather an atmosphere where goals are set forth for the team and the team is empowered to do what they do best in achieving these goals.
Optimizing - The team is constantly look at what they are doing and looking to improve and become more effective. Looking at velocity charts and burns down charts, identifying patterns and cause and effect relationships. These things the Scrum Master works with the team to identify and optimize.
Evolving - Similar to optimizing, but grander. Optimizing is tweaking and improving, evolving is deeper, it is questioning base concepts and accepted process and questioning the value and delivery. It is a team feeling optimized and hitting a plateau, then self reflecting and determining what can be done fundamentally different and better.
Value - Not only having a prioritized product backlog, but ensuring the priority is accurate. It is truly understanding what your company / team / project mission is, identifying where the value lies, and using your resources to work on the value. On my last team, we did something pretty interesting. Once our Scrum team had worked together for awhile and there was a sense of team maturity and safety, we tried having value estimation meetings. Similar to a backlog story points estimation meeting, however instead of effort for points, we started addressing value points. How much value would each feature request deliver relative to each other. Turned out to be a great exercise, but the key was that a sense of safety had to be there for the exercise to truly be of value.
Delivery - This is key. Without delivery, all of the above is just a bunch of co-worker sitting around signing Kumbaya. By delivery, I mean actual working software (assuming your team is ultimately producing software). For example, requirements in themselves have no business value (unless you are in the business of selling/producing requirements, and in that case I have a bone to pick with you as well), rather it is a tool/artifact/side effect of producing software. If that same software can be just as responsibly made without those requirements, then are the requirements truly needed? Now, one common misconception is that Agile states no requirements, which is not true. Often it is more the form and standards in which requirements must be made and applied with which Agile has conflict. Anyway, requirements aren't the point, the point is that delivery is key.
Ok, so I hope I have convinced you that I did not just string together a bunch of non-sense industry words when I said empowered optimizing evolving value delivery. Now, I'm off to synergize my leverages.....
Back From The Dead - BlogEngine.NET
11 months ago