But we are “Agile”

I’ve heard that phrase many, many times.  Usually it’s used to justify not following the current processes, like mashing sizing and grooming together instead of having separate meetings, or making changes to a story after it’s partially (or fully) developed.

Developer:  The change you are asking for will require re-doing most of the development already done this sprint.  We’ll need a new story for this that we can work on in the next sprint

Product Owner (or any business lead):  But we’re agile, we should be able to make this change now.  You are already working in that part of the code…

It seems like being “Agile” is synonymous with not having to follow a defined process to some people.  In my opinion, this couldn’t be farther from the truth.  Agile works best when you strictly follow your process. Always, no exceptions, ever.  I think that’s worth repeating: Agile works best when you strictly follow your process. Always, no exceptions, ever.

Why?

Notice that it says your process. I’m not suggesting to follow some process in a book somewhere.  Follow the process Your Team created.  Assuming your team is following agile practices, the team has developed a very good process that works best for them, and is constantly reviewing and making improvements. If the business goes around the process, then the team is being robbed of the opportunity to improve it.

If having separate grooming and sizing meetings is too slow – isn’t it too slow for all of the other stories? If changes are needed after development is started, wouldn’t it be better to figure out why we have these late changes and how to avoid them?

It’s better to bring up the cases where the process is not working well and fix it for all stories/projects, not just the special ones.  If the process isn’t fixed, you’ll have to keep going around it every time you have tight timelines (or whatever the reason for breaking the process).

Agile works because it makes it very obvious when part of the process isn’t working well.  Everything is done in very short cycles – grooming, sizing, sprint planning, and retrospectives all happen every single sprint (if you are doing it “right”).  If it doesn’t work well, it doesn’t work well all the time.  People get tired of the process failing and will find a solution quickly.  If the pain is alleviated by not using the process, there is no motivation to fix it, so it stays broken.

My suggestion:

Follow YOUR process religiously.  If it doesn’t work well for something, fix the process, don’t avoid it.

Then, when this same type of issue happens again – your process will handle it. Sure, it might take a couple iterations to find a process that works, but you’ll be on the way to success.

 

Book Review: The Five Dysfunctions of a Team

I was recently given a copy of this book (The Five Dysfunctions of a Team by Patric Lencioni) by a co-worker. It is a pretty easy read. The majority of the book is a narrative/story about “Kathryn” taking over as CEO of a company with a very dysfunctional senior leadership team. She walks her new team through their dysfunctions and points out ways to deal with them.

The 5 dysfunctions talked about in the book are: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Results.
Reading through the examples displayed by the team described in the book, I could certainly see some of them in the teams I work with and have worked with in the past. “Kathryn” gives clear guidance on how to deal with these dysfunctions.

The last chapter or so steps out of the story and gives clear definitions, examples and suggestions for solutions to the various issues. It does not make the assumption that all teams are the same, but gives several different techniques to help overcome each of the dysfunctions, and points out that they are all inter-related. You rarely have only 1 of the dysfunctions, but instead have many or all but at different levels of dysfunction.

Given the relatively easy read and the quality of the information, I would recommend this to anyone who leads a team. It’s equally good if you are just part of a team and not leading it, so you can work toward avoiding the dysfunctions at least as 1 member of the team.