Agile Transformation — a happy fable
Once upon a time, there was a lady named Sarah. Sarah was a successful senior manager at FinCo who was put in charge of developing and delivering to all its global customers a new payment portal, to replace the numerous ones previously in existence. It was a big investment for the company, and a major strategic project.
Sarah looked at this challenge with wide-open eyes. She understood that, to be successful, the portal they developed had to meet hundreds of requirements from numerous types of customers — from independent coffee shops to global retailers. She also understood that traditional ‘engineering’ approaches wouldn’t work. If they had to collect, document and communicate all those hundreds of requirements, analyse them and design the perfect solution before development started, they would almost certainly not finish with a product that pleased everyone.
So Sarah gathered around her a group of highly skilled managers, experts in their fields — financial transactions in a global market, software development and testing, infrastructure and cloud-based development — and built her leadership team. They, too, understood that they didn’t have just one shot at this — they needed to build this portal incrementally and iteratively, with short feedback loops and frequent feedback from real customers who would pilot the new portal in Beta test mode.
Together, they understood that they had to create a different type of development team — a team that was highly collaborative, organised and structured around the key components or services within the proposed portal, with a high degree of autonomy. A team comprising young, talented developers. A team of diverse thinkers. A team small enough to fit into the space they had and not in another time zone. A team that could make good decisions — and act on them — quickly.
Each member of the leadership team recruited their own staff. After the first half-dozen had joined, they were invited to help with the interview process. This helped to create a team of people who wanted to work together, who respected each others skills and experience. Soon there were too many people for one team and they split into two, and so the portal team grew from one team into two, and three and four, and eventually there were more than a dozen of these small teams, across two cities. A team-of-teams, if you like. They came from countries all over the world, but they all came together in one of two offices in London or Manchester.
By this time, the leadership team had changed their own job titles. No longer were they “Heads of” whatever or “Director,” whatever; most became Chapter Leads, setting strategic direction and standards for Product, Development, Cloud Infrastructure, QA and others. This further helped change the culture to one where management supported their staff not the other way around. The Chapter Leads set strategy and standards, recruited good people and continually worked on building the culture they wanted.
They drafted a set of values that all members of the team had a hand in editing and finalising. These were values that they believed in and weren’t just meaningless words on posters that no-one paid attention to. They set the tone for a culture of quality.
And then they let their teams get on with it.
At regular intervals they held all-hands events where all teams could gather together to discuss product and technical strategy, review technical challenges and prototype solutions for them. They held ‘hackathons’ that solved practical problems and also reinforced the new culture of collaboration, quality and speed.
In just a few months, the team had a working portal that they demonstrated to existing customers; customers who were keen to share their views on how to improve it. Plans were reviewed and revised accordingly and the work carried on.
Sarah’s bosses were keen to understand how they had managed to deliver something so quickly, and asked Sarah to show them her plans. Proudly, Sarah walked them around the conference room she shared with her leadership team as an ‘office’, and pointed out the grid of sticky notes that covered all of one wall, and the other walls that were covered with marker pen drawings and scribbles — diagrams, decision trees and lists covered almost every inch; evidence of numerous productive discussions.
“What is this?” asked one of the executives.
“That wall of sticky notes,” Sarah pointed out, proudly “is partly our product roadmap and partly our delivery plan.”
“Has this been documented and signed off?” asked another.
“Nope,” replied Sarah. “We don’t need any signoff process. Anyone who cares about this plan is part of the process of creating it and is invited to be a part of evolving it at any time. To us, planning is not something you do once, it is a continuous process of looking ahead based on what we learn from what we have just finished. If we documented and got signoff on every version of this plan, we’d never get started. It changes weekly.”
“Then it’s always wrong!”
“Sometimes,” said Sarah to a collection of raised eyebrows. “A plan is simply an intention. That’s why we don’t plan in detail for any further than a few weeks. The knowledge we get, both from the work we do and the feedback from our pilot customers, continuously informs our plans. Sometimes we get it right, sometimes it needs to be adjusted to include the new information. To ignore that information and carry on regardless would simply result in a bad product that our customers wouldn’t use.
That top row” she pointed at the top of the wall “is our very highest level plan and shows the order in which we want major features delivered. We don’t know when they will get delivered yet, so there are no dates against those, just a priority order. There’s no point pretending we know something we don’t,” she smiled.
“Each level down is a progressively smaller, more granular objective. You can see down here that at this level we know enough about them that individual items can be allocated to — or rather selected by — specific teams to work on. And we can predict with some confidence when those will be delivered.”
There was a brief silence as the group digested this form of project management hypocrisy, but were unable to think of a suitable rebuttal. Sarah’s results were already speaking for themselves.
“And what’s all this… graffiti then?” asked another executive, waving contemptuously at the other walls. “We have rules about clean and professional office space, you know.”
Sarah smiled. “It has long been acknowledged that the most effective form of communication is face-to-face. And having some means of putting across your thoughts and ideas in the form of a diagram while others watch you is just so much more efficient than anything else.”
“But we have invested heavily in huge monitors and cameras and goodness knows what else — at your request I might add — so that you could do all this remotely!”
“And for that I thank you. We use the video-conference equipment every single day to synchronise the work across our teams in both sites. But it has its limitations. The software and the network isn’t always 100% reliable, it is very difficult for us here to read what’s on a whiteboard in the other site and if they zoom in the camera, we can’t see the other people in the room. Being in the same room together is just better in every way. Hence, this.”
“What are you saying, that we should bring everyone together in the same office? You know we can’t do that.”
“I do,” replied Sarah. “And because of that, we have organised ourselves so that the teams in each site have their own products that they work on to minimise dependencies and the need for cross-site collaboration. But funnily enough, these walls get used most when we have people from the other site visit us for the day. They seem to need to discuss problems and ideas together. This is just where they get to do that. There is a similar wall up there.”
Just then, the door opened and three people in jeans and tee-shirts walked in.
“Sorry, Sarah. Do you mind if we have the room? We booked it for 11:30”
“Of course,” replied Sarah. “I think you have all seen what you need to here. We can move to an open space somewhere.”
No-one said anything but they all noticed the senior executive in the group frowning as they left the conference room and walked to an open-plan area of sofas and tables.
“Are you often in the habit of letting your staff tell you what to do?” he asked
“No, but I have to respect both the fact that they did book the room, and that they have a greater need for it than we do.”
The executive spluttered for a moment, but Sarah continued.
“One of the reasons we have been so successful so far is that the people here are highly motivated. And they are motivated because we recognise that it is they who are the experts, they who identify the problems, come up with the solutions and implement them. They are responsible for building the product, releasing it into production and for maintaining it afterwards. They therefore need a lot of autonomy, which they have. If I refuse to leave a meeting room, they will have to reschedule their meeting and a problem goes unsolved or an idea gets forgotten or a decision is delayed. We can’t afford to waste time that way.”
“I get the impression you’re not really in charge at all; it feels more like a free-for-all”
Sarah had been expecting something like this, and she spoke calmly. “On the contrary. We have strict technical standards that govern everything we do. My leadership team regularly attend reviews and other meetings where we ensure that the teams are meeting those standards. We still make all the strategic decisions and make sure everyone is aware of them, the direction we are going and why. The teams can then make day-to-day decisions understanding the context.
It works,” she concluded.
With time running out and no further comments, the executive group shook Sarah’s hand and left.
Later that week, Sarah received an email from Internal Marketing, asking if they could interview her for a short video they were doing for the corporate website about the work her team were doing.
Sarah smiled to herself and agreed. It would be a great opportunity, she thought, to acknowledge the hard work the team had put in, and to give them a little more intrinsic motivation.
The conversation between Sarah and the executive group described above never actually happened in that way. But it could have. The characteristics of the FinCo team Sarah describes I have personally witnessed and am proud to have been a very small part of. They are an example of the sort of organisation that can genuinely call itself agile. It wasn’t about “ways of working”. It was about creating an organisation-within-an-organisation that could create a product that delighted its customers, and do so in a short space of time. An organisation with motivated people, who went the extra mile to achieve the results they wanted. An organisation that put business — and technical — objectives first, and paid lip service to frameworks and methods, applying whatever practices, processes and tools worked best for them. If you have any comments or questions about creating or evolving your own agile organisation, please drop me a line.
