The Impact of Not Understanding the Agile Principles
One of the most common comments, Mike Stuedemann, Certified Scrum Trainer and Agile Coach in Minneapolis, MN receives when training clients on Agile and Scrum is “We already know the Agile Manifesto and the Principles that support it” or “This is too much review”.
When confronted with these comments, I practice Agile and take the issue of whether we are doing too much review to “the Team” by turning off the projector and asking them to close their books. With these “crutches” out of the way, I ask the participants to discuss both the Manifesto and the Principles. I am not looking for rote memorization of these foundational items, but instead seek to understand how deeply participants have grasped the concepts embodied within them.
In conducting these reviews, I often times find that people lack a solid conceptual understanding of the Values and Principles that define “Agile”. Without understanding these items, people seeking to adopt the methods and practices of an Agile method such as Scrum will achieve limited benefit. Agile, and the methods that fall under it, are not comprised of “recipes” that can simply be taken off the shelf and followed explicitly to achieve the desired results. Instead, methods such as Scrum provide a framework from which a Team can operate while using the Values and Principles as guardrails as they inspect and adapt both their product and process.
While understanding each of the Values and Principles is important to establishing Agility – or the ability to respond to customers based on their changing needs and business conditions – within an organization, one principle stands-out for special attention in this post. The ninth Principle that supports the Agile Manifesto states,
“Continuous attention to technical excellence and good design enhances agility”
In discussing these principle with Jeff McKenna (CST), coach of the first Scrum Team ever, Jeff mentioned that he holds this principle as non-negotiable. When asked why, he had a very common sense response – “Without following this principle, all Agile will allow you to produce is more crap, more quickly”.
As I have worked with Teams attempting to become Agile, I have come to realize the truth in Jeff’s statement. Agile doesn’t allow you to be simply adequate in regards to your technical practices. In order to achieve agility, you must practice your craft as a carpenter practices his or hers – with care, attention to detail, a focus on quality and continual improvement.
Teams that are dedicated to working on existing products with large amounts of technical debt (note that technical debt is not sloppy technical practices) often feel overwhelmed by what they are called to by this Principle. In order to evolve beyond this feeling, Teams can take the following actions:
- Invest in Automation – Investing in automation, even incrementally, will improve the Team’s responsiveness by allowing them to more quickly ascertain the status of the product following a change and by increasing their confidence, post change, that they haven’t broken anything.
- Incrementally Improve – Technical debt has some of the same attributes as the financial debt on which the metaphor is based. One of these attributes is that both can’t often be paid off all at once. Instead, Teams need to incrementally improve – write one test case each day, try practicing Test-Driven Development (TDD) in your next Sprint. The only way to eat an elephant is one bit at a time – improving your technical practices is no different.
If you are interested in learning more about supporting the Agile Manifesto values, principles and practices that you can use to deliver quality products, please sign-up for an upcoming CSM course:
