Transitioning to agile? First prepare your environment

Published on the 29/05/2018 | Written by Owen McCall


It may well be the corporate buzzword of the decade, but proper business agility is all about setting the foundations say Owen McCall…

[Foreword: Owen McCall was a panellist in the lunch box webinar on Modern Project Management. Check out the recording to hear more on where agile fits into improving project success.]

I have had lots of conversations lately with CIOs and senior IT leaders about moving to agile [readers: please note the lower case a].  There was a CIO who has invested heavily in training and support for their team, but is experiencing push back on agile practices from the executive who still expect business cases and predefined scope and benefits. A long term industry colleague who is committed to transitioning to agile, but doesn’t really know where to start and another who thinks they are agile because they have employed a scrum master and have a Kanban board and is wondering why his colleagues don’t get it.

It seems that everybody is doing it or thinking about doing it. For many organisations moving to agile starts and finishes with changing the way they manage and deliver technology change.  They do this by implementing the agile methodology of their choice and while this is necessary, it is not sufficient.

Yes, you can and will need to implement Agile and DevOps methods, but that doesn’t mean you will be agile. There is a lot more to being agile than changing your methodology and, actually, that’s probably the least important thing you need to do.  Implementing agile is like going on a diet, whereas being agile is more akin to changing how you live your life day by day to support your weight, health and fitness goals.

A move to agile or DevOps is a “lifestyle” change not a diet and to be effective you need to review and change all aspects of your IT operating model if you expect to realise the intended advantages and benefits of this move.  There are a number of different ways to define an operating model, but you can start by considering these questions:

  • Why is being agile important?  Agile is a means to an end not an end in itself.  You need to understand what the end, or the goal, is and ensure your agile implementation is focused on that outcome.
  • How will we know we are being successful?  What measures do we need to be able to monitor progress?  No implementation is a straight line to success, consequently we need to monitor to what extent our actions are leading to success and adjust accordingly.
  • Does our IT organisation structure support our goals and new ways of working?  New ways of working often require new structures, roles and responsibilities that traditional IT lifestyle organisation structures may not support.  Do you need to change your structure to facilitate the new ways of working?
  • Do individual job descriptions support the new behaviours and skills we need to be successful?  What mix of specialists vs T Shaped [generalist] employees will we need.  Being truly agile requires a combination of specialist skills and flexibility.  Do you have the right mix of specialist skills and flexibility and do you have people who can excel in this environment?
  • Are the incentives for teams and team members aligned with our goals and preferred ways of working?  Most people are smart and they will act in a way that is consistent with their incentives. So if you want different behaviour and outcomes you need incentives that encourage the desired behaviour and outcomes.
  • Have we provided the team with the information and tools they need to be successful? New ways of working often require new tools and different information than we have traditionally used. For example, if you are committed to continuous deployment and continuous integration then you need to ensure the team has the tools and processes they need to make this happen.

Once you have your answers to these questions you can begin to map out all of the changes you need to make in order to transition your operating model to be supportive of agile / DevOps.  There is no one right way, no recipe to follow. The way you manage the transition will be a combination of your specific goals, your organisation culture and current ways of working and your leadership style.  That said, if I was a CIO and looking to transition to agile / DevOps I would most likely follow this process:

  1. Define your vision and goal for IT within your organisation. Socialise and agree this with executive, key influencers across the organisation and your team. This vision / goal will then provide you with all important context for all future decisions.
  2. Define and implement metrics to guide you on your journey, provide feedback and monitor progress.  Don’t forget to use these metrics to help you correct course and just as importantly as a means to highlight progress and celebrate successes.
  3. Review your organisation structure and consider organising IT around business functions / processes and the systems that support them (rather than around the IT lifecycle):
  4. One person, responsible for both Development and Operations for the systems they manage
  5. Align incentives for these teams that balance development / projects, system operations and end user / IT customer satisfaction.
  6. Engage business owners to own the content and prioritisation of backlog (and start to become a product owner)
  7. Begin to reduce the average size of “projects you deliver” to speed up delivery and improve learning cycles and reduce delivery risk.
  8. Move to “programme funding” and programme approvals rather than project funding and project approvals, then deliver small fast “projects” within the programme.
  9. Focus on business outcomes and benefits.
  10. Stop when benefits are realised (or rescope for more!)
  11. Redefine roles within the delivery process to be clear about business (or product) ownership
  12. Manage “project” / function / use case / requirement backlog within the programme
  13. Formally introduce agile methods across the team and into key relationships.
  14. Move towards T shaped employees and T shaped job descriptions.
  15. Invest in tools that support rapid / continuous delivery e.g. automated testing

Finally, ensure you have the right expertise to support you on this journey. That includes agile and DevOps expertise as well as IT operating model and organisation design expertise. The extra time and money spent upfront leveraging expertise will shorten your time to benefits and save you significant cost in the longer term. It will also equip leadership teams with the knowledge and confidence required to be successful in one of the most challenging change programmes of our time.


Owen McCallABOUT OWEN McCALL//

Passionate about using technology to make a real difference to businesses, communities, families and individuals, Owen McCall has focused his career on understanding and answering this question: “How do you harness the power of IT to deliver value?”
An independent IT consultant, he is a former CIO of The Warehouse.

 

FinancialForce_Modern project management & PSA webinar

Post a comment or question...

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Other Articles by Owen McCall

Digital transformation_Fosbury flop_Owen McCall

Digital transformation, incumbents and the business model conundrum

opinion-article |May 23, 2018 | Owen McCall

What Uber, Amazon and the Fosbury flop can teach us about innovation…


S curve_Owen McCall

Why CIOs must master the S-Curve

opinion-article |October 2, 2017 | Owen McCall

Thanks to Moore’s Law the S-Curves in technology are frighteningly short, writes Owen McCall…


Shadow IT: Not a new thing and nor is managing it

opinion-article |April 26, 2017 | Owen McCall

Many IT organisations are strong on wanting a mandate as a way of eliminating shadow IT – but it won’t work, says Owen McCall…


Desired outcomes technology projects

Outcomes don’t depend on where you begin

opinion-article |February 8, 2017 | Owen McCall

IT teams and professionals should focus on desired outcomes, rather than mire themselves in the problems of the day, says Owen McCall…


Gartner hype cycle

Of love, hate and the Gartner Hype Cycle

opinion-article |August 31, 2016 | Owen McCall

They’re great and they’re awful – find out why Owen McCall is ambivalent about Gartner’s Hype Cycle…


Experiment to progress

Failure is good. Yeah right!

opinion-article |July 14, 2016 | Owen McCall

Owen McCall says we should switch from ‘initiatives’ to ‘experiments’…


is the internet safe

Is the Internet Safe? Of course not!

opinion-article |June 15, 2016 | Owen McCall

The internet is not 100 percent safe, but that doesn’t mean you shouldn’t be using it to support the growth of your business. Owen McCall says we should approach it more like driving…


The problem with projects: not fit to deliver value

opinion-article |April 19, 2016 | Owen McCall

What do IT projects and fitness regimes have in common? Owen McCall exercises his theory of the business value creation process…


Digital competence

Driving digital competence

opinion-article |February 23, 2016 | Owen McCall

My daughter Sarah has just passed her learner’s driving licence…


erp disaster

When a disaster isn’t a disaster (and how to better deal with ERP implementation complexity)

opinion-article |October 28, 2015 | Owen McCall

Many years ago, writes Owen McCall, a contribution to a study on ERP implementation failures threw up a completely surprising response…


Processing...
Thank you! Your subscription has been confirmed. You'll hear from us soon.
Follow iStart to keep up to date with the latest news and views...
ErrorHere