Fin Goulding, international CIO at Aviva, recently spoke at the DevOps Enterprise Summit London about using flow principles to advance agile capabilities throughout an organisation. InfoQ asked Goulding to expand on some of the points that he made during his talk:
InfoQ: You mentioned "ineffective offshoring" in your talk - in your experience, what causes an offshoring strategy to become ineffective, and how can a CIO and their organisation right themselves if the partnership is struggling to operate as intended?
Fin Goulding: All too many companies treat their offshore suppliers as cheap staff augmentation and that in my humble opinion is a flawed strategy. I worked in Buenos Aires heading up an offshore division for a number of years and by far the most successful teams had end-to-end responsibility for delivery - including product ownership and production deployment. But that requires trust, minimum viable governance and a true partnership. However, one does need to find the right partner, give them a chance to prove their end-to-end capability and then scale appropriately.
InfoQ: You were open about your dislike for Scrum; how would you recommend organisations new to agile approaches embark on an evolution in this area without falling into the traps you believe Scrum lays?
Goulding: It's not that I dislike Scrum, I just enjoy poking fun at it because I believe that it needs significant improvement and is likely to be fundamentally disrupted. But I must admit that my wife is an excellent scrum master and agile coach and we do have great debates!
For me, the scope of Scrum (and DevOps to some extent) is too narrow and technology focused. Flow principles extend agile to the business teams and to customers and hence injects agility into the management of everything. However, to fully appreciate the latest agile techniques such as Flow, one needs to have experienced the Scrum methodology. But I would not recommend sheep dipping everyone in scaled frameworks or pushing your agile aspirations from the top down. Allow teams to self-manage, collaborate and improve to an optimal way of working.
And for me, an excellent Agile Coach is worth their weight in gold but I would make sure that you hire someone with a broad range of skills including Scrum, Kanban, Flow and Value Management.
InfoQ: We heard a lot about being a learning organisation from various speakers at DOES, but lots of organisations find it hard to create the habit of embedding learning in their daily work. Do you have any advice on how to change behaviours so they can model your advice to have a learning mindset?
Goulding: Start with yourself. If your teams or colleagues see that you are continually learning via meetups, presenting various topics at conferences or blog writing, you will inspire them to follow. You must also take every issue that a team or individual faces as a learning opportunity and not as an opportunity to blame. Simple techniques such as capturing at a stand-up what the team has learned during the week, is a great sharing exercise. The sailboat retrospective is also a fun way to address even the most gnarly of issues to drive learning opportunities.
InfoQ: "Agile is dead. Long live agile?" - what should readers make of Ron Jeffries' article?
Goulding: My interpretation of the articles by Ron, Dave Thomas and the other original authors of the Agile Manifesto, is that they believe that we have lost our agile north star.
No longer are we being agile but we are buying agile, in terms of tools and frameworks devoid of continuous improvement. Hence when I talk about "Agile is dead" I focus on the bad aspects of today's methodologies, roles, tools and leadership behaviours and show the advantages of cultural transformation which underpin Flow principles, the minimal framework for business agility.
In fact, I have always said that within Flow, you can use any tools, methods or techniques you prefer as long as they result in valuable quality outcomes for your organisation. So, in my opinion, agile will survive because it has no choice but to pivot away from today's constraints.
InfoQ: You mentioned you have a DevOps team. Some people think that having a DevOps team is an anti-pattern and that DevOps is everyone's job - what's your view on this?
Goulding: We have flow teams who use DevOps practices which is how things have evolved for me. You have to remember that DevOps is 10 years old now and its original objective was to resolve the issues between Developers and Operations. Today we are seeing DevOps expanded across a wider selection of business and technical teams which, is why I prefer the term 'flow teams' rather than DevOps or DevOps 2.0. And I fundamentally believe that these holistic teams will be at the heart of the most successful enterprises of the future.
InfoQ: A lot of organisations really struggle with getting any or the right metrics - you mentioned you only really care about lead time and cycle time. How did you come to that conclusion and how are these metrics made visible, shared and used?
Goulding: There are metrics which demonstrate where I can directly make improvements and then there are those whereby I cannot (such as conversion rates, NPS or profits) hence my focus on a small set of key measures. But there is also a danger that metrics are used to beat up teams or even worse individuals, due to productivity targets.
My focus has always been on ensuring that work items or stories are uniform in size and hence problems in the flow of work can easily be identified for improvement. Maybe a new team member needs help or a story is too complex and needs simplification. Hence cycle and lead time will highlight this. But in my talk at DOES, I also emphasised wait time and this is the true productivity killer, sometimes leading to excessive context switching. I reckon that wait time between development and operations was one of the driving forces behind DevOps in the first place.
InfoQ: What should people do if they feel their leaders don't understand DevOps and aren't exhibiting the kind of behaviours (e.g. removal of blockers) we expect from them in the DevOps world?
Goulding: The Puppet Labs State of DevOps report is a very powerful source of information regarding what high performing organisations are doing and I would also recommend sharing with the leadership any Use Cases from similar organisations.
Additionally, technical jargon, with no articulation of business value, can really hinder the adoption of DevOps and most of all leaders hate to admit that they don't understand something, so it's best to help them on the journey in order to gain support. However, be prepared for them to claim all the glory for a successful implementation! If you are in the middle of implementing DevOps, invite the leadership to a weekly stand-up and assign the blockers directly to them.
InfoQ: You mentioned comb-shaped people - how common are these do you think and is everyone capable of being a comb-shaped person?
Goulding: I've been pushing what I call the HR 2.0 agenda for a number of years and have spoken to many HR professionals about T-Shaped, Pi-Shaped and Comb-Shaped people. In the technology world, many individuals can design, code, build databases, test and deploy applications, so I wondered why has this evolved into separate job functions?
Well, in many Enterprises, it's become enshrined in the delineation of responsibilities and perhaps how many companies have tried to scale. However, I believe that due to new paradigms such as the gig economy, we will move away from single skill-sets and adopt a life of multiple trades.
This, coupled with DevOps 2.0 or Flow Teams expansion of DevOps across a wider selection of Business and Technical teams) will make those individuals the most valuable people to hire. And guess what, you can grow comb-shaped professionals yourself if you are prepared to let them work outside of their traditional job descriptions.
In additional to being the international CIO at Aviva, Fin Goulding is also the co-author of 'Flow - A Handbook for Change Makers, Mavericks, Innovation Activists and Leaders', '12 Steps to Flow: The New Framework for Business Agility' and 'From DevOps to Flow: Creating Teams That Win the Future'.
