I recently took part in the Agile Confessional podcast with Giles Lindsay. This podcast explores the agile sins people have committed in a confessional format and for me, there have been many.
I have fortunately been granted absolution for my agile sins, however as penitence, I agreed to confess my 7 agile sins on video to all who wish to hear them.
You can listen to the podcast here;
I have been guilty of committing the agile sin of being gIuttonous.
Let me paint you a picture. I once was working with a team. The environment was consulting. The client? New to agile, and the perception was that agile would deliver more, and faster.
You probably guessed it folks, I have been gluttonous when it comes to story points. When I was learning as a Scrum Master and still adjusting towards an agile mindset, I took story points to mean results. The more, the better. I allowed external client & stakeholder pressures to influence how I worked with my team. I'm sure I haven't been the only one to do this either.
I'm sure you can imagine the detrimental effect this had on the teams I worked with. I was under pressure to deliver by my management, to demonstrate excellence and I pushed the teams i worked with to deliver more work in the same time. Books from Agile pioneers titled 'Twice the work, in half the time' definitely contributed to this.
Those who are familiar with my content will be very aware that I am very much against this approach nowadays.
I have learned from my sins and am now proud to be fighting the battle for sustainability with the teams I work with on a regular basis now. The Agile Manifesto itself promotes sustainable pace indefinitely which is something I am an advocate for.
When a stakeholder or client focuses on story points, velocity, or unsustainable pace, I am the first to challenge and ask what outcome is being sought. I then seek to coach, or suggest alternative ways to achieve those outcomes without harming the teams I work with.
How can you avoid committing the agile sin of gluttony?
Understand that velocity is a team metric, not your own - Velocity should primarily be used by teams to understand what they are capable of. Not as a metric which serves as a target, or challenge for teams to hit, or to always improve upon.
Consider alternative measures for a teams success - Focus less on velocity and story points and more on how often customers are engaging with users, and what value their users are getting from what we're shipping them
Challenge deadlines where they are given to you or your teams - Ask for rationale, to understand the why of a deadline being given, particularly if this has been set before the teams doing the work have had the opportunity to see, and confirm if the date is achievable. Protect yourself and the team from arbitrary timelines
The next agile sin video will feature the agile sin of being greed.
Don't stop believin folks