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.
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?
It’s no surprise that many organizations are seeking a complete Agile Transformation these days; clearly the results that Agile brings are worth the challenges inherent in the transformation process. These include:
Recently, Eliassen Group hosted our latest installment in our Agile Roundtable Series over breakfast at Fidelity Investments in Durham, NC. The topic this time was “Business Agility,” one that has seen a lot of press recently, including an article in the May 2016 Harvard Business Review entitled, “Embracing Agile.” The discussion was moderated by Tom Wessel, Enterprise Agile Coach for the Eliassen Group. Panelists included:
In The Product Owner Journey, Part 1, we addressed the challenges faced by the product owner and how these are manifested within an organization that is going through an agile transformation. So how do we mitigate these challenges? What are the strategies that will enable you to remove these obstacles to true agility? In this post, we offer up some perspectives that may help you do just that.
Most teams never explicitly state how they commit to working together. They just start working and may eventually get better. I’ve found, however, that teams can get better faster if they spend some time up front talking about their working agreements. Here are some examples:
For many professionals who have seen the value that Agile brings to the table, becoming an agile coach is the next logical step in advancing their careers. If you have benefitted from the knowledge and experience of an agile coach, then you know that this is a role that values the following sentiment: