Before I explore the main topic of this article, I want to pose a question to you: What is Digital Transformation?
Let’s admit it, we don’t really know. The fact is that even though this is the question uppermost in the minds of the CEO and the C-Suite, no one is brave enough to say they haven’t got a clue.
As a practising CIO, I get asked this question a lot. For some people it means building a new mobile app or launching a web-site.
In reality the word Digital is irrelevant. Mainframes are digital, they function on 1’s & 0’s and if you have a set of good API’s into the behemoth System of Record, you can deliver wonderful Customer Centric digital solutions.
However, the more important word is Transformation (the subject of our book).
Transforming business processes, increasing competencies & skills, whilst leveraging new digital technologies can super accelerate your business in order for it to be relevant now and for the future. Change or die.
Ok, got it. But how the hell do you do it?
Many organisations believe that Agile is going to give them the overall transformation they need.
I wrestled with Agile for three years with my teams before I realised it was not going to be the framework I or they needed to create a new type of work.
I say this in the spirit of having used Agile and being inspired by its founders and practitioners. But in the end I found what I needed and what I had were not Agile.
We needed a degree of agility that the rules and sometimes rigid procedures and often aggressive culture of Agile could not deliver. We were quickly moving towards vastly more adaptive software frameworks like micro-services. In that context, Agile became a drag on our ability to adapt. It is just too slow for this new area of work.
What I had also was a team that wanted to find the right answers, whether those lay in Agile, Scrum, Lean, Kanban or within their own heads, or in that massively important story telling culture that exists in Ireland.
They didn’t want to do somebody else’s discipline. They wanted to interact more, try stuff, argue it out and chew on the more difficult problems.
You can imagine any culture bringing something novel and valuable to the mix of skills we have all now developed through Agile, Scrum, KanBan, Lean etc. it’s important to embrace that. And in my teams I encourage a lot of cultural diversity so we get a range of perspectives and experiences in our interactions.
So, as work became faster and as the scope of our activities broadened out under pressure from our markets, I found my teams wanted, and still want, to push the limits of Agile rather than just follow the rules.
That took us to FLOW. And within FLOW we have introduced techniques that you won’t find within traditional Agile, such as:
- An Executive Portfolio Wall which we encourage the C-Suite to own, so they can shape and prioritise the work we are doing
- Customer Walls that show our segments and help us prioritise
- Dramatically reduced cycle-times and intuitive budgeting and planning
- Fast Customer feedback loops to allow experimentation and pivoting
- Advanced collaboration techniques (Thank You walls, Cool walls, Ministry of Silly Walks sessions – CIO’s meetings with staff of all levels to find out what’s on their minds rather than doing surveys) etc.
- Work breakdown walls that encourage IT and business owners to interact and iterate work not just the software but also the goals we set ourselves as a business
These add up to continuous innovation. We have been taking Agile out of the IT department and encouraging everyone in the Company to become involved because continuous innovation is necessary and really good fun. In fact, in Paddy Power, even HR had a daily stand-up and a whiteboard with “To-Do, Doing & Done” columns. They didn’t care if it was KanBan or Scrum.
I hope that you can gather from this is that doing good work is about really good social interaction. It’s about giving a lot of permission to try things in an interactive, social environment, and when that happens letting the emotions play their own part.
Probably the biggest breakthrough in terms of method in FLOW is the quality of social interaction around finding the right way to get things done. It is an emotional journey and it inspires belief.
CIO’s don’t build systems. Teams do. And hence being agile, responsive, curious, risk taking and energised at the team level is the key.
In our Book FLOW, Haydn and I demonstrate a number of techniques to help you on this journey. We’re doing more of it on the website – www.flow-acdemy.net.
One point we make in the book, and this is an opinion I hold really dear, is that digital transformation happens when people believe. The workplace is a very emotional venue and your people have to believe in you, the leader, and each other.
I could say they have to believe in what you are trying to achieve and while that is true it is less important than this personal thing. Belief is emotional and emotions are all about people. They have to believe in each other, and you, the leader, have to believe in their ability to find the right way.
You’ll find it difficult to build a plan for improving belief. It generally comes about when people are liberated to do good work and therefore give permission to the people around them to care more and to also work better. it is infectious.
I’m not sure where belief fits in Agile. I don’t hear that many conversations about it to be honest.
So how does this play out unreal life?
Creating A Permission Culture
In Paddy Power, a company where I was previously CTO, we had a small team who used visualisation techniques and Scrum to address an important new project.
They and I were trying to work with Agile but we still hit delivery issues and long lead times.
I had come from the lastminute.com world where we had used KanBan to great effect – it’s very similar to Scrum but it is really centred on limiting the current work in progress and making it more streamlined….thus flow.
Let me explain that one. In most organisations you are doing a project, with a budget and a timescale. That means you set out to deliver more or less everything in the specification – even if not everything is written down and isn’t well articulated, it’s your job to deliver the project.
This traditional way of working gives you no control over the work-in-progress. Nobody can budget those traditional projects. There will always be temptations to do more. Work-in-progress becomes something of an infinity pool, filling up with new resources as existing resources are wasted.
The team, in this case, adopted KanBan and began to get work-in-progress under control. They went beyond that, pushing the limits of KanBan as as well as the limits of Agile. They began to think of work not as projects but as simple units of work that would help deliver a set of business objectives.
The other teams using Scrum saw them as the enemy. I kid you not. The KanBan team was moving beyond Agile and beyond KanBan to something else, and in the process posing a threat to the comfort zones people were in with their stands ups and sprints.
My teams were enjoying a much more disaggregated form of work that seemed to be much better suited to the business environment emerging around us. Competitive companies are beginning to offer multiple products to market multiple times a day. Something new is in the air. We had to keep pushing to find new ways to respond to that.
I’m going to look further at how that journey progressed in part 2 of this article.
Blog post by Fin Goulding, Co-author of FLOW and International CIO at Aviva
