Tag Archives: Business Agility

Scaling Agile Doesn’t Necessarily Lead to Business Agility

What we now call “the Agile Movement” seems to have gone mainstream around two years ago. When it did, late adopters showed up and started trying to do what they always do… re-define a concept in their own image. Well, if that image is big, fat, ugly and slow, I would rather they just “opt-out” and go extinct (aka allow market forces to let their companies die, thus freeing-up resources and people for higher purposes.) The irony is that the organizations that came late to the agile game tried to “adopt and scale agile.” In most cases they have not seen the gains they expected.

My hypothesis is that most are simply missing the point. Here is a review of the background context.

  1. Agile is an adjective, not a noun. Defining “Agile” as a set of processes won’t make an organization more agile in the market.
  2. Being able to give the market the product feature it wants when it wants it and for the price it is willing to pay while at least covering costs plus a profit that offsets inflation is THE only thing that matters. Any other focus and the organization will become extinct…and they are, at an ever growing pace!
  3. You can create reinforcing “double loop learning” structures that may create a culture that enables the right team dynamic in multiple teams; however, because corporations are complex adaptive human systems, you cannot scale a team dynamic.
  4. Being agile doesn’t mean automatically lowered costs of new product development or product operations and maintenance. Nor does being agile mean delivering the entirety of a product’s features to market faster than more traditional methods. It just means delivering the product features the market wants close to when the market wants them.

Based on these basic market precepts, I say the following not simply to be critical but to engage in much-needed critical response for the purpose of opening up rational conversation.

You don’t scale agility. You create a business-market fit with adaption capability.

Yes, you can adopt a framework that allows the organization to scale agility-enabling practices. The first attempt at large scale agility that I was aware of was the Scrum of Scrums pattern. The second was Scott Ambler’s Agile@Scale model while at IBM (later renamed Disciplined Agile Delivery due to branding/trademark issues). The one that has garnered the most attention as of late is the crowd-sourced, Dean Leffingwell-owned, Scaled Agile Framework for the Enterprise (SAFe). All three of these are good frameworks, each with their appropriate context and limitations. None of them enable business agility by themselves.

Consider this example:

The SAFe framework talks about quarterly release planning. It talks about release trains of Potentially Shippable Increments(PSIs) of product features in the form of releases.

This is good… sorta.

You see… the way that most organizations have adopted SAFe, the PSI/Releases end up codified into release cycles. The SAFe materials talk about an 8 to 10 week time box. Most folks I’ve talked to have turned the quarterly release planning cycle into a quarterly release cycle. For those organizations, generally this has been a huge improvement. It doesn’t mean that the organization is adapting to the needs of the market quickly enough to remain a viable concern.

The 8 to 10 week release cycle and quarterly release cycle are remnants of the dysfunction of big delivery thinking. I keep seeing releases larger than one or two features, or enough just enough features to be able to deliver an experiment of the business model to the market. This implies the organization hasn’t figured out how to get their releases small enough to build-measure-learn what the market actually will pay for. This also likely means companies are delivering product features that won’t increase revenues, acquisitions, activations, customer retention or referral business. In other words, the market is still evolving faster than the organization and thus at some point in time in the future, the organization’s product will no longer be viable. For some companies this is just for one or a few products. For others, it means the entire business model is no longer relevant.

Speaking of business models, I also don’t see where companies adopting scaled agile frameworks are also learning to evolve the business model with each release cycle. There is this assumption that the business model is correct for the entirety of the product development release cycle, when in reality, there are very few ways beyond business model experimentation using the build-measure-learn cycle to even test that the business model is correct. So businesses get really good at delivering a product that the market may or may not want using a business model that may or may not completely work. Again… the business is ultimately doomed because it cannot adapt to the market fast enough.

In order for a business remain viable it must:

  • Manage its cash flow, maintaining generally a positive cash flow (I know… duh! It’s surprising how many people forget this, though.)
  • Release a functional product that contains only the product features that Kano analysis would call “must-have” and “exciters”, leaving off as many neutral/indifferent features as possible.
  • Release product features at a rate that the market demands as user-expectations shift as a reaction to the Minimum Viable Product (MVP).
  • Understand and attempt to out-deliver new product features at a rate faster than your competitors can react to each product feature release. Sometimes this is a feature-per-day. Sometimes this a unique feature-set per quarter. Either way, it means the company must be able to…
  • Understand the market demand cycle and adapt just before or at the point of inflection in the adaptation cycle.

Again, merely scaling “agile” (noun) won’t make a company agile (adjective). For most organizations, especially those late-adopters and laggards, it means fundamentally transforming to continuous, adaption of the business model for market-fit.

Special thanks to Elinor Slomba of Arts Interstices for the kick-in-the-pants to get this out and for being the other set of eyes.

Lessons Learned From Five Years of Agile Implementation Failures – AgileDC 2013 Presentation

<

p><img class=”size-thumbnail wp-image-1142″ alt=”Picture of me taking a picture of Sprint Zero of the Wikispeed workshop courtesy Elinor Slomba of Arts Interstices.” src=”http://test.devinhedge.com/wp-content/uploads/2013/10/2013-10-08-09.58.52-150×150 Picture of me taking a picture of Sprint Zero of the Wikispeed workshop courtesy Elinor Slomba of Arts Interstices.

Well, another year of AgileDC is in the can. This year was another winner. Even though the flavor at AgileDC is always biased towards the Federal Government, it was strange that the topics seemed to be diverse and more engaging than those at the Agile Alliance‘s Agile 2013. I confess that the topics at Agile 2013 were so non-interesting that I didn’t even go this year. This is not to say I didn’t miss something. I did. First of all I missed hanging out with old friends. There was also a few sessions that I would have liked to attended. For the money, though, AgileDC was a much better deal. Additionally, we raised some $14,000 for a cause I’m deeply passionate about, the Juvenile Diabetes Research Fund.

Wikispeed Keynote

This year, the keynote was just as engaging as last year. Joe Justice of Wikispeed filled in the gaps between Agile 2012 and today. Always willing to put others before self, Joe brought J.J. Sutherland* of Scrum Inc. to talk about how he used Scrum to manage NPR’s coverage of the Arab Spring in Egypt. According to J.J. the situation was so fluid that rather and unifying the reporters, it had a tendency to put reporters at odds with each other, causing missed deadlines and misinformation. J.J. spoke of being reminded of a technique his father forced him to learn by attending a Certified Scrum Master course: Scrum. J.J. talked about pulling out sticky notes and pulling the reporting team together twice daily. It worked and NPR’s coverage remained some of the most relevant and comprehensive. ( Transparency: I contribute funds to NPR so it is good to hear that my money is being managed well. )

Finished product after three one-hour Sprints.

Finished product after three one-hour Sprints.

Another thing from Wikispeed is the phrase “eXtreme Manufacturing”. I like where Joe and the gang are going with this. It has all the makings of changing the world in the same way that Demming did. Yes… I just went there. Expanding beyond building a car that is posed to reinvent how cars are designed and built, Wikispeed is starting to focus on another one of my passions, solving the problem of involuntary homelessness using eXtreme Manufacturing to build MicroHouses. One application I could see of this refugee camps, displaced peoples from natural disasters, and a way for cities to set up transition programs for those placed in involuntary homelessness situations. (NOTE: I probably should talk sometime about what we are learning about why these programs fail and how Habitat for Humanity has overcome these obstacles to success.) Throughout the day, Joe and the folks at Scrum Inc. used the Wikispeed eXtreme Manufacturing workshop to teach pairing, eXtreme Manufacturing, Scrum and Kanban.

Personal Experience

Ballroom B where my session was at AgileDC.

Ballroom B where my session was at AgileDC.

My session went perfectly. I’ve never had that happen before so I thought I would make note of it. I was presenting on the topic of Agile Failures, something no Agile Coaching account manager or business development person is likely to ever talk about. I expected the session, Lessons Learned From Five Years of Agile Implementation Failures, or… What NOT to Do When Becoming Agile, to have about ten people show up. Ten minutes before the session, it was full. Five minutes into the session, it was standing room only.

Needless to say, I was nervous. This was also my first public appearance under the ResultLinq Associates monicker.  Would the audience get the message? That will still remains to be seen, but the feedback was overwhelmingly that I hit home. The feedback told me exactly what I expected. Everyone liked the format. The opening blew everyone’s mind. A lot of people were stuck in deterministic thinking headspace so they wanted a one-size-fits-all checklist when all that could be had are certain principles. Oh… and I thought the projector/screen combination was terrible, too. It made the smaller text unreadable and I was standing right in front of it.

I have to confess that I lied on one slide. The picture of an Agile adoption coaching plan was actually a release planning session. I couldn’t find my coaching plan pictures and had to substitute with something worked and looked the same as a coaching plan. I openly apologize and ask for forgiveness. I found the pictures today after some creative searching through my Dropbox history. I’ve updated the slide so that you can actually see what my coaching plan wall looks like.

Several folks have asked for the slides. I did one better this time around. Below is a corrected recording of the session and a link to the PDF of the corrected slides.

[vimeo 76835486]

PDF File

Feel free to ask questions and challenge some of my hypothesis and theories.

Enhanced by Zemanta