Agile, Agile Estimating, Project Management, Scrum

#Agile means never saying never and always saying maybe – #Agile #Inertia

Recently at a few Agile discussions I have noticed people saying things like:

“You should never provide estimates”

“You should never start to code without automated tests”

“You never need Business Analysts or Testers”

“You should never create requirement documents”

To me, Agile at its heart is always seeking to understand first. Many of these absolutes are diverging from seeking to understand. They even remind me a little of the waterfall method and the absolute rules that were in place that defined the mandatory deliverables that needed to be in place.

Now while I would agree that most of these statements are true most of the time, if you are not modifying your approach with each and every situation and client, I would suggest you are not Agile. If you are executing iterations and you can’t respond to a request from the client on how you execute iterations, then you probably aren’t Agile. If you read the book of Agile and can’t respond to a client request to have requirement traceability, then you probably aren’t Agile. Remember that Agile is being able to deliver the most value to the client and the client defines that value. Not you, not the Agile Manifesto, not bloggers, and especially not me. ūüôā defines Agile as “quick¬†and¬†well-coordinated¬†in movement”. The antonym of Movement is Inertia. If you have Inertia to move, change, customize, or adapt Agile methods, then I would suggest you are not Agile. To be Agile, you need to be without Inertia. Is Agile Inertia better than waterfall Inertia? Of course it is. But it is still Inertia and it is preventing you from delivering maximum value to your client.

Without Inertia means you are able to move between situations based on what fits that situation. Perhaps that is why I have problems with Scrum and the Core Protocols. I don’t think either provide the freedom to allow people to be truly Agile to tailor the approach to best fit the client and deliver the most value to the client.

If you have been delivering multiple Agile projects using the same methods and procedures then I have some bad news for you. You may have developed an acute case of Agile Inertia. In fact if you have been delivering subsequent iterations using the same methods and processes then you probably have a mild case of Agile Inertia.

Sadly there is only one cure for Agile Inertia. Never say never and always say maybe.

About Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?


2 thoughts on “#Agile means never saying never and always saying maybe – #Agile #Inertia

  1. So what you’re saying is always do exactly what the client asks you every iteration?

    A client will always ask for new features and eye candy, and never ask for the infrastructure, refactoring, or other aspects that the system needs because they aren’t engineers.

    It seems like a recipe for disaster to let the customer run the show, especially if the customer is non tehcnical.


    Posted by postagilist | December 18, 2012, 10:36 pm
    • @postagilist, my apologies. Perhaps I wasn’t clear in my post. I wasn’t suggesting that you just do everything the client asks without validating, negotiating, and hopefully persuading. It is our roles as professionals to provide this technical perspective and expertise. My intent is that the client defines the priorities of the features but not the how of the architecture and infrastructure. That is left to the technical experts. But they may have input to items like the level of estimates and traceability of requirements. (i.e. they may require more formality than stickies on a board and no estimates)

      But it would be equally wrong to just take what the Agile books say and implement those practices without listening to the client’s needs and requirements.

      As usual, the optimum solution is in the middle…

      But I would say that yes, we do exactly what the client wants us to every iteration in regards to features. But the team and client will jointly define how the process will be implemented, and the team will define the how the technical solution is implemented…

      Posted by bornagainagilist | December 19, 2012, 9:40 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: