The future of IT Ops is collaboration and balanced judgement

Ever wonder why so many organisations struggle to become agile? I have watched, time after time, as Executives announced that their IT department was going to do things differently, that everyone needed to get on board to help them, and that the fortunes of the company rested on being able to increase collaboration with customers, change faster, and innovate more. Then the CIO/CDO/CDIO (or whoever) is tasked with kicking off a transformation programme, and maybe some money is allocated to make it look like they mean it. Then they go back to their day job of running the company. The 'Programme' looks at the delivery process and who is engaged with it, does some training and maybe hires or outsources an Agile Coach function, selects a couple of projects to get started with and then gets on with it (in the best traditions of the Agile approach!). The problem is that failure to transform is rarely based on the development method, or the 'project management' of it. Becoming Agile means that everyone is Agile, not just IT. To understand what it means to become 'Agile' you must first recognise why, of all words, this was the one chosen to describe it. In the Collins Dictionary it is as follows: (ˈædʒaɪl ) - adjective 1. quick in movement; nimble 2. mentally quick or acute 3. denoting a project-management system based on teams of workers who are empowered to adapt the development process in response to regular feedback Let's examine the difference between the first two simple definitions and the third, much more complex one. The first two are non-specific and can apply to any activity where some form of action needs to be taken quickly and/or safely. With the latter definition there is no sense of a lithe, nimble execution, but instead a depiction of a system involving many moving parts and activity phases. In the Theory of Constraints, a machine is only as fast as its slowest part (this is also known as the Buffalo Theory). With it's emphasis on engagement with the users, measurement and feedback, controlled investment through value prioritisation and autonomous delivery teams, Agile is a complex machine involving numerous actors, all engaged with a varying degree of cohesion. The Collins description is therefore wrong. It is focused only on Project Management, which is also the mistake many businesses make. Since Agile is inherently described as a system, a ll active participants in an Agile environment should be examined before we can use feedback to improve it effectively. This includes users, governance and control, finance, executives and even end customers where their engagement of feedback is critical to continuous improvement being undertaken at pace. My favourite definition of Agile is a simple one: Agile: q uick and well coordinated in movement For Agile to deliver its promise it must be quick - to be quick it must not over-promise in the first instance - to be quick it must be well coordinated and controlled - to stay quick coordination must continue beyond the kick-off and throughout ongoing delivery - to stay quick, controls should not unnecessarily slow things down. Looking at why businesses fail to become Agile, we can see that these are usually linked to the circumstances necessary for Agile to succeed: Whilst development teams and some members of the user community become trained in Agile methods, Design Thinking, and some of the tools like Mood Boards and Kanban Boards, critical 'other' stakeholders are not trained and therefore, at best, add little value or, at worst, create friction and hurdles. Limited experience in Agile delivery, combined with a false belief that planning slows Agile projects down leads to poor coordination between the delivery team and other stakeholder groups, and a lack of understanding of what interaction between them is designed to achieve. Product Owners are not given the financial or operational empowerment necessary to continuously develop and improve the product, but are instead onerously reviewed and challenged by Portfolio Managers and Financial Controllers who lack understanding of the value of the product and its various features or component parts. Definitions of 'Done' are too rigid in the first instance and seek too high a value return at the first development review by Executives or Portfolio Managers who do not understand the continuous improvement lifecycle and its investment profile. Critical: Poor early results (and a sense that money is being wasted) lead to the re-introduction of Project Managers and a return to some Waterfall behaviours and methods, which deliver a hybrid methodology that often takes the worst aspects of both and undermines the iterative 'learning' nature of Agile. Becoming Agile is the result of practice with learning As experience grows, so the expectations, coordination, interaction and controls are improved. This is the result of Agile's focus on the feedback loop and when combined with short, rapid development phases, quickly trains teams to deliver (particularly true of Scrum, DSDM and Extreme Programming delivery methods). However, it can take several iterations for projects to deliver these improvements to the point where project outcomes are improved. If you introduce project managers, project controls and apply Waterfall mentality to an Agile activity you increase the chances of switching off (or otherwise mangling) the delivery, and reverting to old ways. Just like learning any new skill, reaching a level where you are adept, capable and comfortable is hard work and takes investment. When those that review your progress are not a part of the transformation, early attempts will be unfavourably measured against the capabilities and outcomes of previous methods and the risk of failure rises significantly. Start by understanding who and what needs to be coordinated. In the next blog on this subject we will investigate how the moving parts of this system can be established, nurtured and measured to ensure that Agile is designed for your company so that how you finance, plan and execute your projects is aligned with how your business is designed to operate.