I am pleased to announce that my first book, Understanding the Agile Manifesto: A Brief & Bold Guide to Agile is now available as a podcast. Over the next few days / weeks I will be releasing the book, chapter by chapter, on this website and through the iTunes store under my “Agile Doctor” podcast.
There is an Agile principle which states, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. It has become obvious to me, the word “sprint”, which, although it may have a specific meaning in scrum, generally is understood to mean “an act or short spell of running at full speed.”
Scrum teams that work are small, co-located, dedicated, stable and cross-functional. These elements are essential in working in the complex world of software development. Recently, I stumbled across another reason that may explain the gains found on proper scrum teams – friendships.
This particular problem manifests when a company desires the potential benefits of Scrum without really understanding Scrum. Without a good understanding, people attempt to map their existing roles with those of Scrum. Let me make one thing perfectly clear. The role of Scrum Master is unique to Scrum and any attempt to map it to existing roles will only result in confusion, frustration and less than optimal outcomes.
If we want to create better software we would be well to head Glass’ fact. We need to stop treating software development like we are building a house or assembling a car. Software is much too complex to be built using the tired old mechanistic means. Remember that as complexity of the problem increases, the complexity of the solution increases at a much higher rate, along with the risks attendant on increased complexity.
If people cannot fail a test how good can the test be. Given this fact I am not even certain that a CSM should be part of the job description. A few months of “boots on the ground” scrum is better than the two-day training.
“Zombie stories” are a great indicator of team maturity, the origin of which is mostly related to either stories that are too large, poorly written and poorly refined or teams that are pressured to plan more in a sprint than is possible or are victims of “false” dependencies.
When I talk to people about good Agile teams, especially good scrum teams, I talk about five attributes – size, co-location, dedication, stability and cross functionality.
I am often asked as an Agile Coach when I know that I have been effective at my job. The answer is simple- my work as a coach is done when the team in question is capable of being predictable.
And what, you may ask is predictable? For me it is a team that is capable of consistently delivering 90% or greater of points that have been planned for an iteration. I have given this capability a name. I call it the Gold Standard.
I gave the Larry’s Top Ten Agile and Scrum Myths talk to the Java Users’ Group in Phoenix recently and … More Larry's Top Ten Agile and Scrum Myths