Almost every technology department in an enterprise organization has discovered the “agile bug.” Recruiters are calling anyone with “agile coach” on their resume. I have friends whose phones are ringing off the hook with offers to coach “agile” in many different types of organizations. From the outside I would say agile has reached the “early majority” stage. This is where as a practice agile has crossed “The Chasm” and moved into what is becoming the new normal.
Image courtesy GEO Jobe
But what about “bad agile?” Every agile practitioner has some sort of horror-story around an agile adoption/transformation gone awry. The root cause these practitioners encounter are varied. Some examples of root cause are organizational inertia, cargo cult agile (a.k.a.“agile theater” courtesy @MsMcCalla_1), and lack of an executive change champion. The technology landscape is full of organizations that half-tried/half-succeeded/half-failed in their agile adoption efforts. Many enterprises are now going through the Lean Startup continue/pivot/kill exercise to see where to go next. I believe the hope is these organizations will choose one of the first two options. Yet as one of the wisest minds in the Agile world that I know once told me, “hope is not a strategy.”
Any enterprise opting for agile is making the right choice. I think that if an organization sets out with the correct expectations they are more likely to achieve success. Agile practitioners owe it to the enterprise to help set the right expectations for the transformation. The agile way of thinking is admittedly quite different than previous norms. In trying to achieve consistency I think presenting the core tenets of an agile transformation in a simple, familiar format will aid in absorption.
The first value: Drive results by FEEDBACK over Drive results by a PLAN
Image courtesy iLifeGeeks
Project plans. Any seasoned agile enthusiast who encounters that term usually reacts with a frown (followed by a retching sound). In traditional delivery most of the emphasis lies on the project plan…do you have a plan? What does your plan say? If you don’t have a plan, do you have a “plan for a plan”? Anyone who’s EVER written a project plan knows that it is quickly outdated. Any organization that places faith in a static document shows blind obedience to the “way things have always been done”. And this coming from a project manager!
Agile methodology places the emphasis on FEEDBACK. This feedback is received through daily “stand-ups”, recurring retrospective meetings, or even through co-location. Prompt, constant feedback is essential to success and will lead to a better solution. Minor “course corrections” based upon feedback results in a better product. The lack of a proper “project plan” is quickly forgotten once the leadership level sees the excitement during the collaborative journey.
The second value: Emphasize VALUE over Emphasize PREDICTABILITY
The Cone of Uncertainty, courtesy Agile In A Nutshell
Many traditional development organizations have utilize either a strict waterfall or quasi-waterfall methodology. To whit: there is the concept of phase gates, milestones, and a view of software delivery being a synchronous process. An outcome of this process is that the feeling that delivery will be “predictable.” Anyone who’s ever been on a waterfall project knows that nothing is completely predictable. Plans are in constant flux, so to assume the authorship of a plan makes things predictable is unwise. The emphasis on predictability comes (in my experience) from the Leadership/Executive level. Predictability is what helps drive the forecasting for resources, budget, and a myriad of other project-related items. Emphasizing predictability puts things “into stone”. This violates the triple constraint from the get-go, and sets what more often than not is an unrealistic goal.
In lieu of predictability let’s emphasize VALUE. Is what we’re delivering providing value to the client/customer/etc.? Would they rather have something value to them in their hands,or a plan? Said plan “predicts” when the value will be delivered (which is usually overly-optimistic, and sets the wrong expectation). If we emphasize the importance of value we place the majority of our efforts on providing something worthwhile to our sponsor. The other option is deliver a plan which may or may not happen.
Tossing the false safety net of predictability for value will be a hard pill to swallow for most if not all organizations. However with a little faith and some positive results most organizations quickly see the error of their previous ways.
The third value: Judge on OUTCOMES over Judge on OUTPUT
Image courtesy Monique Bozeman, LinkedIn
Inextricably linked to the above value is the concept of output. Even though organizations are trying to adopt and transform the way they do things (the new way) said organizations want to persist with using the old way of measuring progress. How many stories did we deliver? How many epics? How many story points were completed? This volumetric approach to judging progress is a false arbiter of accomplishment and places emphasis on quantity NOT quality.
The smarter approach for the path forward is to judge your success on OUTCOMES; did we accomplish our intended goal? Does what we delivered to the client/customer/etc. meet their expectations? Are they happy with the results? This is a vastly more efficient way of measuring of the team’s/company’s/organization’s success. There is a saying in management circles “what gets measured gets managed, what gets managed gets done.” If we keep this in mind it becomes even more imperative to place emphasis on positive outcomes, not checking off a box.
Image courtesy Keep Calm-O-Matic
The fourth value: Deliver what the client NEEDS over Deliver what the client WANTS
Image courtesy Don Cooper
Every agile practitioner I know has spent time as either a business analyst, project manager, or comparable position. The one thing these roles have in common is they all interact with an organization’s program or project office at various levels and points. It is common for practitioners to have seen/been involved in the traditional project charter process and it’s requisite “fuzzy planning work.” One thing many notice is that when a business unit/department/team is creating a charter it contains a laundry list of what they WANT. The fact that is never taken into account is that the list of WANTS is point-in-time. Is it comprehensive? Occasionally. Is it all-encompassing? While the author may think so history has proven it unlikely. These types of project charters usually amount to a giant “bucket of asks” for a multitude of reasons. due to funding constraints, timelines, or other political/bureaucratic concerns. with the hope that more than half will be completed before time or budget runs out.
Instead of coming up with a giant list of WANTS that will change, we should guide the author to describe what they NEED. These items can and will change over time, but if the team concentrates on smaller deliverables it will drive learning quicker and lead to insights. This helps ensure that the team is consistently delivering what is needed versus what the author wanted when the request was written.
This list is by no means complete, and by no means does it attempt to cover every single facet of agile adoption. If any of the above prescriptions are sticking points within an enterprise there’s a chance that there are obstacles to full adoption; these obstacles of course are merely unrealized opportunities! Changing an organization’s culture and operating paradigms is never easy. By setting the correct expectations up front (as well as helping the customer visualize the end-state) agile practitioners may increase their chances of success. At that point agile adoption becomes more formulaic, and frees up us practitioners to concentrate on other thornier issues!