We’re approaching three years of Agile/Scrum development in my office, and I believe that we’re really starting to come to grips with the advantages and pitfalls of Agile development. Overall, I feel that there are significant gains possible with Agile, but “getting it right” looks easier on paper than in actual practice.
It’s certainly easy to get the wrong impression of Agile and Scrum, and there are still far too many implementations using the ScrumBut approach. (“We do Scrum, but we don’t have a Product Owner,” or “We do Scrum, but we don’t have daily stand-ups…”)
I’ve come across an interesting perspective of Scrum in the blogosphere, 7 truths about Agile and Scrum that people don’t want to hear, posted by Kai Gilb. In his introduction, Kai states, “In this blog series that will be written in 7 parts, or blogposts, I will highlight 7 major challenges and hint as to what needs to be done to rectify them. Most writings on Agile, talk about its glory, here I will write about the faults: faults that are so serious, that if not rectified will ensure that your favorite Agile method will become last year's fad.”
Personally, I believe that Agile development provides many benefits, some of which I outlined in my post Achieving Higher Productivity, Stimulating Innovation, and Maintaining Morale. However, there does seem to be a great deal of confusion about the implementation of Scrum. I agree with Kai on this point, a problem with a methodology like Scrum is that it is very lightweight. But perhaps the problem is that we’re collectively doing a bad job of explaining what Scrum is and what it isn’t. Before I begin examining Kai's posts, I'll take a stab at providing a high-level description of what Scrum is and isn't.
Scrum is… Scrum is a set of protocols that allow a team of multi-disciplinary of knowledge workers to collaborate together to represent the business in software. Software development is all about understanding and meeting the goals and needs of the business while operating within the constraints (e.g., time, budget) of the stakeholders.
Scrum recognizes (assumes) that these knowledge workers have the greatest expertise and insight about their own work, and as such the Scrum framework supports and fosters open communication, accountability, and cross-functional participation. It defines the mechanisms for those knowledge workers to use so that they can understand, interact, and monitor their work as a team.
The advantage is that Scrum teams don’t have to go through extra time and effort establishing their own protocols for operating. They can use the Scrum framework, incorporating whatever technical practices works best for them. This leads me to what Scrum is not.
Scrum is not… Scrum is not a paint-by-numbers methodology where everything is explicitly and rigidly defined. For example, Scrum does nothing to define technical practices. This is why many industry gurus recommend incorporating XP practices into Scrum.
Succeeding with Scrum requires competent, capable, engaged professionals who are applying more than just technical practices. Because Scrum relies on cross-functional, collaborative teams, these professionals need a blend of both technical and interpersonal skills to succeed. The framework is simple, but solid execution requires disciplined action by capable professionals.
Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai has his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.
I'll delve into Kai's post in my future posts on this blog, responding to them individually, in the order that Kai posts them. I invite you to share your experiences and thoughts!