Enterprise Agility Workshop

I recently held a workshop with senior management (general managers and executives) of a large enterprise company on agile methods. In this post I share the framework that helped me execute the workshop, sharing the experience and points for reflection. 

The situation with this client is a typical enterprise organisation structure, divided into broad areas of "Business" and "Technology". Divisions within the "Business" include Customer Care Operations, Marketing, Finance and a PMO. Divisions within "Technology" included IT Business Systems, Digital Media Product Development & Consumer Technology. Strategy is a separate division altogether. Added to this mix is the Technology Division supports multiple business units, with each business unit sharing similar (but unique) operational entities. The tech divisions were also unique in that each applied their own flavours of delivery: two were agile (but had different implementations of methods like scrum / kanban), whilst the third implements a hybrid waterfall / iterative life-cycle. And lastly, these three tech divisions had their own flavour of delivery PMOs (so count that as four PMOs in total, plus another PMO for BI/Analytics group - so that's five PMOs!).

The business people's request was basically:

We work with technology teams that are using this thing called Agile. What is it? Can we have a workshop to review agile methods, to decide whether / what / if the full enterprise needs to do / change to become more agile? How can we deliver faster? How can we get technology teams to respond faster, given that we in business operations can't move as fast as technology?

I was doubtful to say the least, because to me, timing was everything. The dust hadn't settled yet due to recent (and ongoing) organisational re-structures within both business and technology divisions, so I was hesitant this workshop would not add much value. Anyway, the client insisted the workshop happen, so I had to make it happen.

Was the workshop a success? Well, my client would argue yes, it was a success and it's great that we made a start.

Did the workshop run as I expected? No, what I had in mind (see mind map), what I planned for and what actually transpired did not fully meet my expectations, still there were some lessons learnt, and validation of my ideas & experiments are useful, hence I decided to share the framework publicly.

How to frame the workshop?

My mindmap design for the workshop

This picture is the mind map I used as a guide to planning the workshop. I applied my RAGE model as a guide, looking at:

• Reality - I needed to understand the current reality of the stakeholders, in terms of their knowledge and experiences with agile methods?
• Aspirations - Wanted to understand what problems they wanted to solve?
• Goals - How could I run the workshop to address some of the stakeholders goals?
• Expectations - What were these guys expecting as an output from the workshop?

1. Start with a Survey

So I created a simple survey using Google forms to gather input from the stakeholders. I kept the questions short and just light enough to give me a feeling of what to expect in the room, and for the type of personalities I'd be working with:

In addition to the stakeholders' expectations, for me, it was about creating a valuable experience. My workshop needed to address the following core topics at least:

• Describe agile in a non-technical way, high level principles (creating common understanding)
• Allow people to experience key components of agile interactions:
• Strict time-boxing
• Backlog management
• Unclear requirements / scope from product owner
• Limiting work in progress
• Velocity
• Self-organisation
• Defining what done really means
• Agreeing on a common vocabulary
• Retrospection & Discussions

In running the workshop I also used a simple board with the agenda items flowing from To Do | In Progress | Done, using time-box for each topic (brought a handy kitchen timer in). We had two hours to complete the following:

I used simple kitchen timer to keep time. This caused some amusement at first, but eventually the group realised I wasn't kidding, and when it came to the exercises, they were quite mindful about their timebox, which made them focus on their task at hand :-)

2. Framework for Hands-On Exercises

Vision

My goal with the hands-on was to explore the disconnects in the organisation when it comes to functional roles / activities that are assumed as part of a standard delivery project. The exercise must reveal the silo-mentality, the typical disconnect between ownership areas of "Business" owns, and "Technology".

The exercise was also meant to allow participants to experience the following:

• Self-formation of team and self-organising
• Sticking to a time-box iteration
• Dealing with uncertainty
• Dealing with conflicting and ambiguous requirements / terminology
• Seeing the bigger picture: how fragmentation in business units needs to be avoided

Exercise One

The first exercise asked the participants to select topics from a list of roles or activities. I had cut out in card strips the following topics:

Topics to choose from

We had three jars, labelled TODO, IN PROGRESS, DONE. The cards from topics list were placed in the TODO jar. As the team progressed each topic, the card would flow from TODO -> In Progress -> Done jars. Whilst this may at first seemed trivial, I wanted people to get a taste for the kind of work that goes on in agile teams.

My aim was to divide the group into two teams. 

The team must arrange the topics according to responsible area: Business or Technology.

As they finish each card, they move the card from ToDo to In Progress to Done jars.

Once the map was completed, each person would use their three votes on the cards they thought were most problematic.

Allow for a second sprint if the teams couldn't complete the exercise in the time allocated for the first sprint.

Once over, have a quick retrospective on the exercise.

Once done with the exercise, I led into a presentation on Agile in a Nutshell.

Exercise Two

This exercise follows after the team have had the overview of agile in a nutshell. With the concepts of agile in mind, the exercise was to be repeated - this time, place the cards into "Technology + Business" leaving some cards to an "unknown" parking lot for future discussion.

The aim of this exercise was to show that, from their original starting point of separating activities as solely belonging to silos of either "Business" or "Technology", that agile forces you to work as one team, that it is essentially one complete team that works together across business and technology to deliver a piece of work. The result would be something that calls for a fully cross-functional team approach, instead of a clear separation of business and technology roles.

3. Find a decent presentation (don't re-invent the wheel)

Agile in a Nutshell Presentation

Short of re-inventing the wheel (and because I sensed the interest just wasn't there so I needed to be careful not to invest too much of my own time on this), I used the work done by Jonathan Rasmusson's Agile Samurai book and his presentations available online. I've read a number of books on agile, and have done some of my own presentations, but felt that Jonathan's work covered all the ground I needed to, it was the best high level overview of agile for my audience, so I re-used his work. I clearly stated my reference at the start of the workshop, that I felt no desire to reinvent the wheel and encouraged all participants to get their hands on the Agile Samurai.

Jonathan's presentation that I referenced was pulled from his youtube channel. You can check it out here. 

4. Run the Workshop

In the run up to the workshop, getting senior management to complete the survey was quite a mission, but in the end, those that were interested completed in time. Acceptance of the workshop invite was also quite hit-and-miss: with some people unable to commit due to other priorities (why do they need a session to discuss agile methods, nothing is burning anyway!) or even send delegates with some decision-making powers. I began to feel like this was going to be a waste of time and energy, due to people's lack of interest in the subject, but I had to push on nevertheless due to my client's insistence the workshop had to happen.

Workshop Backlog

So on the day of the workshop, starting ten minutes later than planned, we had a quorum with just enough people to make up one team. At least we had the CIO present (overall owner for IT business systems, one of the three tech PMOs), along with business PMO & Customer Ops team. I had to make do with this and plod along.

Group Exercise

I was pleasantly surprised with the commitment from these senior folks, in actively participating in the workshop: allowing me the freedom to run it as I planned, first showing them my own TO DO list for the agenda, time-boxing myself to slots for each agenda item, and them carrying out the exercises, and patiently watching the videos.

Work Jars

Even though with the single team, the conversations highlighted the areas as I expected would surface, they appreciated the challenges that scrum teams face like: what's the real requirement, who's the product owner, constrained time-box to do work, customer changing mind, ambiguity in terms, and the clear separation / silo mentality that exists within the enterprise. They latched on to the common sense concepts of agile, and talked about the impact of cross-functional teams would have on the current organisational structure.

I found it fascinating how the different personalities interacted in forming the team, allocating tasks, who took charge of moving the cards across the workflow: To Do, In Progress, Done jars.

The team were quite slow in the beginning, realised they wouldn't complete in the time-box allocated, requested a new sprint, and reflected on the seemingly simple nature of the exercise, that turned out to trigger a lot of discussion around what the topics meant, and which area of the enterprise was responsible.

The fact that this interaction took place proved I was on the right track with my hands-on concept - validated!

5. Next Steps

Here is the mail I circulated to the management forum (anonymised):

Hi,

So we decided to have the workshop this morning with [PEOPLE REPRESENTING BUSINESS & TECHNOLOGY]. The workshop focused at fifty thousand foot view of Agile Principles (not how Agile is done in [COMPANY], but core fundamental agile principles & values), including hands-on practical exercise that allowed people to experience core concepts of: Backlog, Velocity, Requirements/Scope, TimeBoxing,  & Self-Organisation amongst other things. 

What was interesting the exercise proved there are fundamental terms and concepts that [COMPANY] need to come to terms with and implications of agile, and existing enterprise functions split between Business & Technology. This then leads to whether [COMPANY] is structured to support agile, and whether roles / responsibilities are clearly understood or not? 

We agreed the conversation needs to continue, and needs full participation from all stakeholders for it to be really worthwhile.  

The next workshop should be around: Problem definition (Deep Probing, Root Causes) – what is not working well, what’s the core desire that is not being fulfilled by Tech/Business? 

Topics, from customer-perspective:

1. Why is [COMPANY] structured the way it is, what were the principle reasons & working agreements (why does it feel like nothing really has changed)?
2. Does current org structure contradict and prevent us from being agile?
3. How should we plan for business & customer ops readiness tasks (we can’t train the whole call centre in two weeks, why can’t we switch on features as-and-when business is ready? How do we make customers ready for every build/new product? What is the equilibrium we need to reach?)
4. What is the extent of business input & involvement into product development? (It’s either not clear, or not working well in practice, even contradicting collaboration and one-team-approach of agile, CX v UX constant spinning)
5. Teams within Technology Divisions - ways of working are different even though business is told it’s “agile" – should there be a consistent way of working across all tech divisions? (How would business need to adapt if needed?)
6. What/How does business / customer ops need to change to be more agile?

These are big topics – not simple to complete in a single workshop of two hours, will have to follow-up with further sessions.

Regards,

MK

And so the journey continues, albeit slowly! If all goes well, I may end up running the agile transformation program for this enterprise (fingers crossed).

A note on the info videos

Just some parting comments on the supporting videos I used for the workshop. The first video was aimed at introducing general concepts, and to show people that agile principles could be transferred to other domains, like Team Wikispeed's car. I had a personal bias to this video as I was one for the earliest videos that I found fascinating, going back many years. In retrospect, this video is probably not the right one to show to executives, because the immediate feedback was: All very interesting, but I don't see how they will scale. And what are they doing now? 

The second video was meant to add some light humour to the workshop, showing Hitler running a sprint review. I think it may have struck a chord too close to home for some people. Nevertheless my aim was to show that not everything goes swimmingly well with agile teams, especially if the core software engineering principles are not adhered to. Focus on the right people, using the right tools with solid software engineering practices.