When I decided to update my home theatre and add some innovation to it I immediately assumed that I needed to invest in a specific configuration and brand of equipment in order to achieve my desired result.

I did the research, read some articles and then decided what I thought I should spend. When I actually got to the store to make the purchase I was surprised to find that the salesperson was more interested in understanding what my desired result was rather than just taking my money for the list of items I was ready to buy.

Shocking isn’t it! This individual stopped me in my tracks and began with a series of questions that ranged from solving a particular problem I had with my existing system to what I wanted out of the new home theatre regarding long term ROI. I thought this was odd but I discovered in the end that what I actually needed was an upgrade of only a few components and more importantly, someone to come and reconfigure my existing system to improve the overall output and quality.

This experience is not too dissimilar from what has transpired with agile over the last few years and still seems to be prevalent today. Many organizations that have either seen or heard about agile are making decisions to “get agile” or to “do agile” and have taken a label or brand approach to introducing it.

It would be unfair to say that all companies that have invested in agile have done so in this way but there is no doubt that we are all very good at buying a brand or a label and viewing it as something that will solve our problems and challenges.

The thing that is most interesting about agile is that it represents a way of thinking and working that has so many useful applications across a company and not just where it has traditionally stayed in IT, more specifically in application development.

Perhaps the most popular flavor of agile is Scrum. In an effort to produce better software sooner, Scrum has become a de facto approach for many IT organizations yet the real value is looming elsewhere.

Before a company assumes it needs agile, it needs to answer more questions starting with why it believes agile is needed. Often what a company is seeking is agility in the business and when we say “the business” we really mean the lifecycle by which the business makes decisions and brings ideas to market.

Agility is an outcome but also a competitive advantage. If I believe that agile practices will help me get my software to market faster and better then why wouldn’t I naturally look at applying the same thinking further upstream in my lifecycle process?

I suppose the answer is that we would look to apply it further upstream and now that several companies have experienced success with using agile in the application development realm there is a growing interest to see how it works elsewhere.

We need to point out, however, that agile alone won’t solve the problem. This is where organizations really need to understand what is available to them and how they can apply different approaches to develop their own. Lean, for example, can add tremendous value in the business also and when we understand what we are trying to solve and achieve then we can leverage the practices from industry that make the most sense for us.

So what is most important? I would suggest that there are three things we need to simultaneously focus on when we are looking to significantly improve our organizations. These three things are leadership, change and process transformation.

All three involve both IT and business and all three need to be joined up so that whatever practices are introduced and used, the continuity gets embedded throughout the whole lifecycle. Specifically, when we are seeking to get agility into our organizations we want to improve a number of existing areas such as:

  • Vetting ideas and projects quickly with smarter criteria
  • Removing the bloated processes and steps that contribute to waste and slow us down
  • Funding what is most valuable to the business and knowing what isn’t
  • Providing an agile and/or lean governance model that emphasizes continuous improvement with minimum bureaucracy
  • Embedding change incrementally so the company’s ability to consume it makes sense and is accompanied by wins not blanket policy
  • Leverage what exists and avoid “boil the ocean” approaches that just add more confusion and waste
  • Deliver our products and services well all the time

These are not just a list of goals and objectives that we would put on a slide to socialize our intent. They are actual outcomes we would expect from successfully applying agile (and other) practices into our organization.

The call to action is to assess how we introduce and achieve agility not just agile.

Recommended Posts
  • Andrea

    I was told about your site from Justin Grammens. Nice to see you guys fighting the good fight, so to speak. So if I get you, what you’re saying is more along the lines of Agility of a team is inversely proportional to the number of external people who are involved and also clueless. Like say I’m the customer of your system under development which will replatform my entire business, yet I’m so busy I can’t afford to talk to you because, after all, you guys are just supposed to just do it right and if it’s wrong, you will have hell to pay. Somewhere along the line maybe hell does get paid and the project fails. On an Agile project, this is a huge success because it happened very early, before $millions are wasted on building the wrong thing. Sound familliar?

Leave a Comment