From the agile business to the agile CIO
Reed.co.uk CIO Mark Ridley talks about his organisation's journey with agile, and of his decision to leave the company for a possible career as a 'gigging CIO'
Mark Ridley, director of technology of recruitment website reed.co.uk, has taken the difficult decision to leave his organisation after 19 successful years. He joined the business as a developer in 1997, and moved up to head of technology, then director of technology (being effectively the CIO) in 2007.
Before explaining his next step, he describes his firm's journey with agile, and in it are many lessons for any organisation with an interest in product or software development - in other words, every business.
"We decided to become agile in 2007, which came out of consultancy work with McKinsey looking at how we could go from a free to a paid model," begins Ridley. "We were left with quite a big chunk of work to do, which was essentially taking a product which had been developed to be free, and turn it into a real commercial offering in about three months."
That was a big ask, and the only way to do it, Ridley realised, was to embrace agile. But that was easier said than done, as he soon discovered.
"The biggest mistake that I made at that point was thinking I understood agile and knew what to do. We threw together three or four different agile styles, because there were things I liked and didn't like about each of them.
"We had a guide book that said we do this like [agile methodologies] XP [Extreme Programming], and this like RUP [Rational Unified Process], and this like Scrum. And actually we lived with the legacy of that rather egocentric decision for quite a long time.
"If someone came in for interview and asked if we're agile, we'd say we are because we use Sprints, and we do things in two week iterations, and we follow the ceremonies, but we didn't really understand the philosophy. We'd read lots of books, but not enough people really understood the core of what we were trying to do."
Ridley explains that it's impossible to be completely agile as an organisation, rather it's an ideal to continually strive for.
"If you want to start adopting agile principles there are a few important things know," he continues. "One is that not only can you never get to perfect, but every time you take your eye off the ball, you slip further away. The ideal is that the teams absolutely get the principle of agile, and can self-support. It takes a real institutional commitment and constant effort to keep pointing out to people what agile means, and it's very easy to backslide into waterfall.
"Agile is hard and you need champions for it who coach, manage and monitor, and challenge and remind. It's a set of habits you need to develop, and some people like it and some don't, and that's a challenge for the hiring and coaching processes."
Ridley is an advocate of the Mary and Tom Poppendieck Book Lean Software Development, which he describes as "...the real culture of agile distilled down for developers".
He explains that the first time he read it he understood the ceremonies and the need for constant collaboration, but didn't really grasp the philosophies behind it, admitting that he "didn't have enough scars to understand how it was going to be applied".
In the book co-author Mary Poppendieck tells a story about a team within a large business that adopted agile practices, and was quickly seen as such a high performing unit that executives demanded that everyone follow their example.
"It failed abysmally," says Ridley. "Nobody else could replicate their success. It comes down to understanding the reasons behind agile rather than just telling people you're going to meet in the morning for 15 minutes, and you'll meet at the end of the week to talk about your feelings.
From the agile business to the agile CIO
Reed.co.uk CIO Mark Ridley talks about his organisation's journey with agile, and of his decision to leave the company for a possible career as a 'gigging CIO'
"There's a caution there," he continues. "We adopted agile in 2007, then about five years ago realised we were suffering from growing pains, and we wanted to deliver faster. We didn't think there was much wrong with the way we did agile, but we were a large and growing tech team needing to deliver and to be seen to be contributing."
The realisation as to what was wrong came when they hired consultancy firm Endjin to work with them for a time.
"Endjin sat with us for three days and talked through some of the big projects we were running and what we saw as examples of success and failure. We realised the project we considered a success because it was delivered on time and it was proving commercially viable, wasn't necessarily a success if you looked at it in other ways. We hadn't necessarily gone in with a clear strategy, we had got lucky. We had heroic effort from fantastic people which meant we delivered value, but it wasn't necessarily the process that had delivered value.
"Endjin helped us understand not just what we were missing in terms of the process, but also that we were missing the understanding. It's very hard to have a truly agile development team if you're not working in an agile business. So at that point, a lot of my time was spent coaching the executive board about how to exist in an agile workplace."
This was the crucial turning point. It wasn't enough just to have the development teams working in an agile way, the whole business had to reflect agile philosophies - right from the very top down.
"Suddenly it starts impacting everyone," adds Ridley. "Previously we'd run projects on anything up to 18 months, and at that time we went down to seven week releases and still thought we were agile. And then at the same time you're still in board meetings talking about a product release in six months.
"We suddenly realised when we talked to finance, HR or other teams, we talked about autonomy, giving teams ownership, but actually unless you're very clear on your strategic direction and the way that strategy is communicated through the business, it's very hard to truly give autonomy. You have to be very clear on what the consequence of failure is.
"So after working with Endjin we threw out the Ridley agile manifesto; this list of rules where we said we do this like XP, and this like RUP. We said we'll just do Scrum, at least that way we can hand someone a book and say ‘we do it like this'. My personal misgivings with some of the methodologies turned out not to matter. So we got people certified [in Scrum] and then people had a common language. Whether there are good or bad things about that particular methodology, it became very secondary to the fact that there was a universal understanding of what we used."
So the business changed to follow a pure Scrum methodology, only making their own tweaks to some of the processes after they fully understood it and had "developed the right habits", as Ridley puts it.
"We learnt lots of lessons about where Scrum is and isn't appropriate, and how to deal with interruptions. You can have problems with operational issues. If they're constantly cropping up, that can be detrimental to a Scrum team that has agreed what it will commit to over two weeks, knows the speed at which it will develop, and knows its burn down rate."
So can other businesses take reed.co.uk's interpretation of Scrum, together with the tweaks Ridley and his team worked out through bitter experience, and employ it directly for themselves? According to Ridley, these tweaks are something every organisation needs to work out for itself.
"You can't just hypothesise over what works and then make changes to the framework, you have to develop the scars for yourself. One company's implementation of Scrum will be very different to another's, that's part of the reason agile is so challenging.
"We're starting now to be able to run our own experiments around our implementation of Scrum. So we're looking at how long-lived teams work, how you apply resources to problems, how you talk to the board about strategic backlogs, and how you talk about risk. At the moment we're running our own way of assigning resource, which we call ‘bubbles'. We assign a business objective, then the teams try to understand what resource should be applied to that objective, and when it's achieved, the team ceases to exist, so the bubble bursts. Then the team go back and wait in a pool to be reassigned.
"We're trying to focus the business much more on explaining the business outcome, and taking resources from anywhere - it could be sales, finance, marketing or whoever, depending on the lifecycle stage of project. If we're just testing a new idea, we might just need a product owner and a salesman. That philosophy takes it outside IT, or even the technology function."
From the agile business to the agile CIO
Reed.co.uk CIO Mark Ridley talks about his organisation's journey with agile, and of his decision to leave the company for a possible career as a 'gigging CIO'
He explains that this idea sprang from some research he conducted into the ideal size for a team. He believes 25-30 people as the optimum size for an organisation.
"It's fantastic, you know everyone, and you can probably still just hire a pub for your Christmas party! But when you start scaling out of those levels it becomes harder. If you have 100 people in your product team for instance then connections can become difficult to foster, so some of that bubble methodology is about moving people around to foster relationships and keep that creativity."
The gigging CIO
Ridley finishes by asking if there's a role for CIOs to play in the gig economy - the idea that some workers can take a series of short-term engagements instead of permanent roles.
"I'm interested in CIOs and CXOs in the gig economy," he says. "I spent some time recently with a Swedish post-startup. They run a website, so they're a digital company, but they don't necessarily have visionary thought-leadership from a CIO type. They certainly have a very strong CTO who can keep the lights on, but they haven't got someone saying you can do this amazing stuff with machine learning or predictive analytics, and here are the companies you could talk to.
"You can see this area where a good CIO with strong relationships could be massively beneficial. The area I'm thinking is not in startups, but maybe in the mid-market space [which he describes as 150-1,000 people], where they couldn't necessarily afford a permanent top-flight CIO, and they wouldn't have enough to keep them busy all the time."
He argues that there are lots of permanent CIO positions where what should be a strategic role is filled with operational tasks.
"You're spending a lot of time filling in approval forms or expenses or doing administrative tasks, which isn't strategic! You're being paid the salary to do the strategic stuff, but you're backfilling the role with stuff that just needs doing.
"So maybe there's something in the gig economy where you can say I'm not here long enough for you to give me administrative and operational tasks, I'm here two days a week. In that time we discuss brilliant ideas around the things you want to achieve. You can say here are the things you can do, here's how to plug them in together, here's the list of suppliers I know and trust who can help you out. Then you need a project manager to do it, not an expensive CIO full-time to help delivery.
"Or maybe you need help with procurement or governance. It's about sitting down with people who care about their companies and want them to succeed in this new digital innovation economy, but need some assistance and leadership without going to a ‘big four' consultancy. It isn't getting someone to come in for 12 weeks, but a more sustained relationship, just not all of the time.
"It's not wildly different from non-exec directors," he admits. "But typically CIOs come with a network of other CIOs, their vendors and their trusted suppliers, and people that they'd never touch. That's hard won over many years.
"You don't want to lose that, part of the value is that you've done it and continue to do it, but the very nature of having different clients at C-level is that you form these small networks of other C-level people. The gigging CIO would keep these client lists varied in different industries, so they're not competing, then maybe you can bring those companies together so they share more experiences than they would otherwise.
"If it works for one C-level person, would it work for CIOs? Is there a gig economy CIO role in the future?"
Computing's DevOps Summit 2016 takes place in London in July - and places are going fast. Learn more about how other end-user organisations are approaching DevOps, and their advice for doing it right. Places are free to qualifying IT professionals, so register now.
Read other extracts from Computing's interview with Mark Ridley here:
Struggling to recruit data scientists? Look to sociology and economics grads
Airbnb Syndrome: CIO warns about boards asking for 'more innovation'