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.
Between these presentations and my daily coaching practice, I am reminded yet again at the importance of forming a good scrum team. This, along with proper backlog compilation and maintenance, can make the difference between success and endless frustration. In my experience, proper scrum team formation is the area where companies who are unsuccessful in Agile transformations fail most often.
My topic this week is the fall of a company I (still) have a great deal of affection for, one that I continue to support. To me this company “was” the internet and their rise and past prominence represented what was best of Silicon Valley. More troubling is their subsequent lack of direction and downfall represents what can be thought of as the worst of Silicon Valley. I am not the first (and will not be the last) to weigh in on the tragedy that goes by the name of Yahoo!
I am often faced with explaining the various aspects of Agile to people new to Agile and I have come up with a very simple way to remember (and explain) Agile. I present to you now the “3Ps of Agile Software Development” with the hope you find this useful to your own understanding and an aid in your ability to explain Agile to others.
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.
I expect that coding interviews will be with us for some time to come, but at least I can look forward to the day when I write the blog “Company X abolishes the coding interview (and Admits Earth is Round).”
With scientific evidence questioning the effectiveness of brainstorming vast, the real question is why does the use of brainstorming persist? The question is at the heart of much of my agile practice in that the prime issue is not whether one is merely effective, but that one is optimal. It is obvious to me that several cognitive biases are in play in keeping brainstorming around.
As I think back on my coaching work in agile, the blogs I have written, the many discussions I have had and the presentations I have made, I think that all of these boil down into one very simple thing – my work is all about helping people understand the true nature of the software development business process and, thereby helping them to make better decisions.
Israel’s assertion is now that there are ways to rather easily assess technical debt (like SonarQube with SQALE plugin), technical debt could (and should) be added to a company’s balance sheet. I applaud and support his efforts.