It probably comes as no surprise that there’s a massive demand for DevOps and Agile development skills in the marketplace. Based upon the 2018 IT Priorities Survey conducted by TechTarget, Agile development methods and DevOps are top priorities for IT organizations that must fuel their digital businesses.

Part Two: Three Transformative Truths Essential to Success

Part One: Transformation as Rubber Band or Brave New World?

During a recent Agile coaching engagement I overheard this comment: "Agile isn't a big thing." This viewpoint was clearly negative, as in: "Agile isn't any different than anything else." To provide context around this comment, it was mentioned in relationship to the scope of an Agile Transformation in its pilot stage; this is the part of a transformation where we work to share the vision and provide a limited set of people in an organization with the knowledge, tools, and experiences to become change leaders.

The Need for Business Agility

A shortcoming of most Agile transformations is that they do not go far enough when implementing Agile within an organization. They tend to solely focus on the IT side of the organizational equation without addressing the business side of the equation. IT transformations allow organizations to become more efficient and effective at delivery value once that value has been defined. Once something has entered the organization’s internal system, it can then be processed quickly. A colleague of mine refers to this form of optimization as ‘internal optimization.’

In Part 1 of this series, we addressed the value that Agile delivers in terms of the change in working capital from which many companies can benefit. In this post, we turn our attention to another key factor that CFOs must consider when evaluating Agility and its impact for the business related to de-risking the income stream and standing by the organization's fiduciary responsibility to its shareholders.

Here's a scenario you might have encountered.

You are with a large enterprise and your team believes strongly that an Agile Transformation will have a major impact for the organization that will result in greatly improved efficiency and faster time to market. You start from the bottom up; the effort is heavily supported by a few key stakeholders and team members and you make progress. But somewhere along the line, the Project Management Office (PMO) jumps in and attempts to measure results using traditional metrics that do not illustrate the true value of the transformation. So things unfortunately fall apart, or more likely are crushed.  And maybe your organization tries again but after the second false start, the support for the transformation begins to melt away.

For those who aren't familiar with decision fatigue, it’s a condition where your ability to make decisions deteriorates with the number of decisions you make after a rest period (think nightly sleep). One of the most iconic counters to decision fatigue was Steve Jobs' seldom changing wardrobe. The number of decisions we make in a day is really staggering. And the impact of making the wrong one can vary from insignificant ("Should I wear the sand chinos or the tan chinos today?") to traumatic ("Can I make the crossing before the train gets here?").

Agile. Delivery of business value incrementally with a minimal amount of development work-in-progress (inventory) with such a short cycle time between plan and delivery that changes in market, technology, and legislation are immediately responded to with near zero “excess,” near zero “obsolescence,” and less “working capital” (cash) needed to keep the engineering machine running.

Agile transformations present significant stress to organizations. Much of this stress is derived from the realization that team members are expected to complete all of the tasks required by their legacy culture PLUS the new behaviors a successful Agile Transformation requires. And, we should be clear: Agile Transformations require new practices, techniques and events, all of which need to be learned, practiced and applied. And the time, effort, and energy required must come from somewhere. It is the proverbial 10 pounds of material in a 5 pound bag problem. It never fits and it is not Agile, because team members cannot sustain that pace indefinitely.

The million dollar question every software developer asks themselves is:

Software is strategic differentiator for companies and the ability to design and deliver this software effectively and efficiently is dependent upon agility. Back in the 1990’s companies started considering how they could deliver software more efficiently which launched the Agile Movement. And starting in 2010, we began to see large scale agile transformations - “Agile at Scale.”

In my last blog post, Asking the Question: Why is Agile Failing Us? Part 1, I set the stage for the presentation I recently gave at the TriAgile Conference in Raleigh, NC. Given this highly charged topic that I had selected, the day of the conference dawned and with trepidation in my heart, I prepared for the event.  Picking up my name badge at the entry way had me wondering if I was hexed already, since I was listed as ‘Rob Annis Rob Annis,’ perhaps so that I could easily be identified for the pitchfork-carrying crowd as it hunted me down afterwards.

I was one of the very fortunate people invited to speak at the recent TriAgile 2016 Conference in Raleigh, North Carolina. This was a great honor and a privilege for me and not one that I had undertaken lightly. Indeed, I had spent a lot of time pontificating over what topic I should speak about; should I delve into the right way to do stand-ups? Or focus on the difference between progress and status updates? Maybe give a master class on story pointing? All of these and many more appealed, but one topic kept coming back to my mind – if so many of us have shifted towards an Agile way of working, why is Agile not the de facto model for projects?