Using Agile Outside of Software

“There is a better way to do it. Find it.” – Thomas Edison

One of the core principles of the agile manifesto is the response to change in opposition to following a plan. That is not to say that development and following a plan is not valuable but there is a heightened value in remaining responsive to change.

I was approached this week by a colleague and friend who asked my opinion on a very structured change management framework for organizational initiatives. They have personally really grown to appreciate the idea of approaching things in an agile manner and the use of collaborative teams to find innovative solutions so the idea of this highly structured process framework seemed to raise some concern them. I thought about this a great deal and speculated that “change” could be managed just like a sprint or use of a kanban pull system just as easily.

I think that at its core, the agile manifesto (if taken out of the context of software) guides us to:

  • Value collaboration with people to solve a problem over rigid processes or elaborate tooling.
  • Produce a working value item as opposed to documentation defining what the items is to be produced so we can inspect and adapt a tangible item.
  • Remain close and communication often with customers to again help us reflect and review on progress to date and gauge possible improvement.
  • Embrace change and be open to adaptation when change occurs.

I postulated the following approach to them based on the scrum framework (these are not really new ideas, just a rehash of those before me but I find the idea of applying agile frameworks outside of software fascinating):

The Artifacts

  • A change initiative backlog consisting of specific items of change sought by the organization. This should be prioritized with highest value change initiatives first and lesser valued items much lower in the backlog. I might create these very similar to user stories with a persona who will gain value, a business value need and an expected benefit. In place of the typical acceptance criteria of a story, I might use something like expected result from change (maybe a benchmark) or maybe even some other type of indicator. Unsure there but think the key takeaway would be to split the concepts so that they could be delivered in one to two weeks but no more than a month to keep the inspect and adaptation horizon low enough to “pivot or persevere”.
  • Tasks could be decomposed by the team to address the change initiatives, again like you would with a typical backlog item and provide them an insight into progress during the change sprint.
  • In development of the initiative, I might even develop personas reflecting the target impact audience and their perceived benefits and perhaps even develop an initiative roadmap that reflected where logical “releases” of the initiative made sense.

The Rituals

  • You might perform some base forecasting to get a shared sizing indicator but I would probably forgo fibonacci and opt for t-shirt sizes, animals, etc. I would let the team determine the appropriate sizing rubric. I am really not sure that this would be necessary as you might better employ a pull system to visualize work process for something like this.
  • I would only consider keep sprint planning so that the team could make the commitment to the change owner if I were to use more of a scrum process than kanban. I think either could work effectively here although I do personally appreciate creating a sense of urgency and team buy-in with a stated commitment.
  • I would definitely keep a timebox  of 1-4 weeks to allow the team to remain focused and keep the end goals in mind. I think that this review horizon for progress with the team is essential so that they are invested and reflect the realistic amount of work that can be accomplished.
  • I would keep the concept of a stand-up and work to set the timeframe in relation to the need for risk mitigation of not meeting the commitment. I would probably stick with daily as it tends to level set people for things they have accomplished and remaining tasks to be performed. I also think that this helps reinforce the ideas of self-organization and self-management by allowing the team to reflect together on items done and undone and organize themselves accordingly. Even if using a “pull system”, I would use this opportunity to have a guided “walk of the board” so that the team could reflect on bottleneck areas, self-organize to impact them and visualize the overall flow. I would start simply with a “To Do, In Progress, Done” approach and tailor as the team learned more about its general workflow states possibly.
  • As I stated earlier, I would define a timebox for progress demonstration of the initiative items and team reflection like the scrum framework review and retrospective.

The Roles

  • A “change owner” (just like a product owner) represents a group of stakeholders for the organization and is the single voice to the team when it becomes stuck, needs clarification or needs an immediate decision. This person would need to be empowered by the business to own this change effort as they will have the ability to provide iterative feedback to adjust course accordingly at the review.
  • A cross-functional team. One of my favorite design firms is known for this idea. In applying this to the concept of of an organizational change initiative, I believe that you would need to ask yourself some clarifying questions:
    • Is it more important that I have all the skills necessary for the delivery of a change item?
    • Is it more important that I get a good cross section of my organization of all types of roles that are critical thinkers and “doers”so that I can get a better reflection of the organization as a whole and to provide broader context?
  • I would also use the concept of a scrum master type role to help keep the team focused and productive. I might tag them more as a team coach focused on helping them through the process, teach them heightened skills to work as a team, assisting with impediment removal and assisting them to reflect on the process for continual improvement of the team.

I think the key components to making this work in a non-software situation is to still be value and customer focused and treat the initiative like a product so that it could be developed.

Folks who typically read my blog may be saying to themselves “yeah, this just makes sense” but for people outside the world of software, sometimes the concepts of iterative building seem foreign and they see things in “final state”. This is just an idea for them to see how they might apply this to their domains of business. I do think that providing the team the concept of focused effort would make this more productive but in the context of business domains this might be difficult. Capacity management strategies, micro teams or just allowing them to suspend their daily effort and focus for a timebox (by having others manage the daily activities) could be an option. I do think using a pull system might allow for an interrupt driven process but I also would be concerned that most might have difficulty determining true criticality of work they typically are expected to perform today. Being an agile leader and allowing this focus may draw some criticism but you might treat it like an experiment, run a few sprints with focused effort, reflect on the work accomplished and adjust as needed.

One thing that I told my bosses when I pitched my first scrum pilot to help secure buy-in was “you will review progress every 2 weeks. At this time, you can choose to continue, adjust or stop funding the project altogether and abandon the effort. Failure should be an option but the goal should be to fail as fast as possible if we do so.”

We are already seeing this done a great deal in many industries, automotive, design, marketing, education and even in areas such as program development at NPR. So this is definitely not a new phenomena but it is interesting to take a step back away from the world of software and ask ourselves how might we harness what we know already about agile principles and processes and apply them in a unique way to build something other than software. It fascinates me. So take a moment, is there somewhere that you see complexity in an effort that would benefit from an empirical approach. Maybe you should be a catalyst to help someone try something new.

I leave you with this quote that I have always appreciated …

“Success isn’t about what you accomplish in your life. It’s about what you inspire others to do” – Unknown






Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s