A Decade in Agile: 2. CIO/IT Directors - What Agile Means to You
This blog is part of the Blog Series: A Decade in Agile and was first published in April 2010. My updated reflections are in blue italics.
Agile is a double-edged sword!
On the one hand, following a period of intense change, budget spend and organisational upheaval... your department will have quicker cycle times to market, be more predictable operationally, produce higher quality software, have better working relationships with its customers and will be more adaptive to changes of business objectives and requirements. On the other hand, all the department's problems that you know currently exist will become very visible and transparent very quickly. All those skeletons in closets you've been dampening down, or battles you've been fighting to secure funding will rise to the top of agendas.
If you're looking for an easy ride or at least some calm seas, don't start agile. Increasingly, I am discovering that the issue faced by CIO’s and IT Directors is not that they are needing or wanting to cover issues or mistakes, rather that there is a fundamental lack of visibility and transparency in the end to end process of software delivery which means they don’t know where the biggest problems are. There are lots of voices saying how bad things are, but little consensus on the scale of the problem or how to quantify it. Increasingly, the more pressing need of CIOs is for visibility and transparency in order to understand that changes are required. This is leading to the need to use Lean Thinking and Application Lifecycle Management (ALM) tools. Lean Thinking brings Value Stream Mapping (VSM) to the fore, which provides an overview of the entire E2E process by clearly articulating customer expectations and metrics covering process, delay and lead times as well and complete & accurate percentages. By using VSMs for agile adoption we are able to clearly identify and quantify where the biggest problems in the pipeline are and attack those problems first by applying A3 problem solving and agile solution patterns.
Creating current state value stream maps can be a painful experience when you apply cost data to a process with high levels of waste and low quality levels. ALM tools are the means by which software is created from idea to consumer usage and there are an increasing array of tools in the market – “Business innovation now drives the application life-cycle management (ALM) market. The contribution that application development and delivery makes to a company’s business goals – making workers more productive, creating engaging customer experiences, and brining new software products to market more successfully – must be more direct and successful. Software increasingly plays a central role in a firm’s ability to deliver new products and services or exploit new channels. Firms can no longer accept historical gulfs between business and application development and delivery teams as, increasingly, firms now expect to manage application development and delivery as a business and treat it as a competency.” (The Forrester Wave: Application Life-cycle Management Q4 2012) I expect strong growth in the areas of ALM tools and DevOps capability over the coming years as companies grapple with the integration of the business, application development and delivery/support teams in order to achieve Continuous Delivery. Agile methodologies expose the weaknesses in your value stream of delivering software, it exposes poor infrastructure, asset management, governance, processes, delivery, and most fundamentally, it will expose weak people...
Agile not only highlights these problems, it rubs your face in it by reporting all the dirty linen as impediments and waste, and directly attributes slow delivery to the specific problem. These could include lack of testing environments, or poor VM performance, or production support interruptions, or no automated tests, or poor architecture etc, etc, etc.
Not only that, but if you walk this road, your department will start to judge you and the success of the agile initiative by your personal ability to secure funding and remove organisational impediments i.e. your executive skills. This is a key point. I’ve seen first-hand the effect on morale and motivation when there is a lack of drive and courage from senior management. Teams that were excited and making great strides in changing the way they worked were brought to faltering halt. When you coach an individual person, regardless if they are from the business, learning to become a Product Owner or a seasoned Senior Developer, they ‘get’ agile and will accept/go-for a certain level of personal change. When you coach a Scrum Team, you can see the mind-set changes, the learning take hold, and the retrospectives become effective improvement triggers. Over a few sprints the team starts to race along faster than those teams around them… And then they start hitting organisational barriers: environment issues; business involvement; archaic deployment processes; bureaucratic change control… It is at this point that management/executives need to break-down some silos, build or re-build relationships, drive some change, spend some money. If these barriers or impediments are not over-come fairly rapidly, the change stutters and comes to a halt. Often this is most clearly identified and felt at the retrospectives where the same impediments and organisational issues are impeding the team sprint after sprint. So before you start down this road I think the first question for a CIO should be "Should building software be a core competency of this company?"
If the answer is no, then maybe the answer lies elsewhere in out-sourcing your software development to a good agile house. Forrester is a good start for compiling your short-list of agile companies such as Thoughtworks.
However, if there is a need for a strong software development capability because technology is fundamental to your business strategy, and the board of directors are in agreement, then agile is the best approach. This is because Agile development, specifically Extreme Programming, is one of the most disciplined approaches to software development in the world.
So, let's assume you're a pro-active CIO/IT Director, with a supportive board behind you, ready for the challenge... Where do you start?
Fundamentally, you're initiating a change programme to completely overhaul the way your company builds software. Don't fool yourself into thinking you're doing anything less!
The change will affect everyone involved, your consumers, your internal customers, finance, marketing, HR, Operations and your own area.
Forget the Hype - Moving to Agile is a large organisational change programme that will overhaul your approach to software delivery.
Make no mistake, it's about people, its about change and therefore we all know it won't be easy!
The good thing is that each change is incremental, there's no big bang, you just have to keep removing barriers, impediments and keep the budgets going.
It's continuous improvement, not revolution. Every company is different, and every implementation of agile is different. Some companies adopt it with ease, others find it hard, and again others take the bits that they ‘like’ or are relatively ‘painless’ and stop there. If you want to get the best results and productivity from adopting agile then it really should hurt a bit! You're going to need help!
There's plenty of agile consultancies out there at the moment flooding the market, but fundamentally I think you need to look for experience and named resources to cover 3 fundamental areas; the organisational change, the delivery process and the engineering practices:
1. Experience of managing organisational and cultural change including the stakeholder communications, business case creation, and internal marketing. And be able to demonstrate the energy it requires. (regardless of if its agile or not).
2. Delivery management expertise, commonly Scrum is the predominant process adopted by agile teams. So look for Scrum Practitioners or Coaches with at least 5 years experience and references to back it up.
3. Engineering Practices - Extreme Programming expertise, automated tools usage, and deployment specialists... basically strong agile engineering experience - ex-Thoughtworkers and Conchango Devs are a good start.
With competence in these 3 areas, you won't go too far off track but do not underestimate the need for the Engineering Practices as it is fundamental to the quality of product and reducing cycles times to market.
And as with all change programmes... this will take months not weeks. "The propensity to exploit Agile delivery to achieve business success is directly proportional to the capacity of a company to change and continuously improve."
Agile is a double-edged sword!
On the one hand, following a period of intense change, budget spend and organisational upheaval... your department will have quicker cycle times to market, be more predictable operationally, produce higher quality software, have better working relationships with its customers and will be more adaptive to changes of business objectives and requirements. On the other hand, all the department's problems that you know currently exist will become very visible and transparent very quickly. All those skeletons in closets you've been dampening down, or battles you've been fighting to secure funding will rise to the top of agendas.
If you're looking for an easy ride or at least some calm seas, don't start agile. Increasingly, I am discovering that the issue faced by CIO’s and IT Directors is not that they are needing or wanting to cover issues or mistakes, rather that there is a fundamental lack of visibility and transparency in the end to end process of software delivery which means they don’t know where the biggest problems are. There are lots of voices saying how bad things are, but little consensus on the scale of the problem or how to quantify it. Increasingly, the more pressing need of CIOs is for visibility and transparency in order to understand that changes are required. This is leading to the need to use Lean Thinking and Application Lifecycle Management (ALM) tools. Lean Thinking brings Value Stream Mapping (VSM) to the fore, which provides an overview of the entire E2E process by clearly articulating customer expectations and metrics covering process, delay and lead times as well and complete & accurate percentages. By using VSMs for agile adoption we are able to clearly identify and quantify where the biggest problems in the pipeline are and attack those problems first by applying A3 problem solving and agile solution patterns.
Creating current state value stream maps can be a painful experience when you apply cost data to a process with high levels of waste and low quality levels. ALM tools are the means by which software is created from idea to consumer usage and there are an increasing array of tools in the market – “Business innovation now drives the application life-cycle management (ALM) market. The contribution that application development and delivery makes to a company’s business goals – making workers more productive, creating engaging customer experiences, and brining new software products to market more successfully – must be more direct and successful. Software increasingly plays a central role in a firm’s ability to deliver new products and services or exploit new channels. Firms can no longer accept historical gulfs between business and application development and delivery teams as, increasingly, firms now expect to manage application development and delivery as a business and treat it as a competency.” (The Forrester Wave: Application Life-cycle Management Q4 2012) I expect strong growth in the areas of ALM tools and DevOps capability over the coming years as companies grapple with the integration of the business, application development and delivery/support teams in order to achieve Continuous Delivery. Agile methodologies expose the weaknesses in your value stream of delivering software, it exposes poor infrastructure, asset management, governance, processes, delivery, and most fundamentally, it will expose weak people...Agile not only highlights these problems, it rubs your face in it by reporting all the dirty linen as impediments and waste, and directly attributes slow delivery to the specific problem. These could include lack of testing environments, or poor VM performance, or production support interruptions, or no automated tests, or poor architecture etc, etc, etc.
Not only that, but if you walk this road, your department will start to judge you and the success of the agile initiative by your personal ability to secure funding and remove organisational impediments i.e. your executive skills. This is a key point. I’ve seen first-hand the effect on morale and motivation when there is a lack of drive and courage from senior management. Teams that were excited and making great strides in changing the way they worked were brought to faltering halt. When you coach an individual person, regardless if they are from the business, learning to become a Product Owner or a seasoned Senior Developer, they ‘get’ agile and will accept/go-for a certain level of personal change. When you coach a Scrum Team, you can see the mind-set changes, the learning take hold, and the retrospectives become effective improvement triggers. Over a few sprints the team starts to race along faster than those teams around them… And then they start hitting organisational barriers: environment issues; business involvement; archaic deployment processes; bureaucratic change control… It is at this point that management/executives need to break-down some silos, build or re-build relationships, drive some change, spend some money. If these barriers or impediments are not over-come fairly rapidly, the change stutters and comes to a halt. Often this is most clearly identified and felt at the retrospectives where the same impediments and organisational issues are impeding the team sprint after sprint. So before you start down this road I think the first question for a CIO should be "Should building software be a core competency of this company?"
If the answer is no, then maybe the answer lies elsewhere in out-sourcing your software development to a good agile house. Forrester is a good start for compiling your short-list of agile companies such as Thoughtworks.
However, if there is a need for a strong software development capability because technology is fundamental to your business strategy, and the board of directors are in agreement, then agile is the best approach. This is because Agile development, specifically Extreme Programming, is one of the most disciplined approaches to software development in the world.
So, let's assume you're a pro-active CIO/IT Director, with a supportive board behind you, ready for the challenge... Where do you start?
Fundamentally, you're initiating a change programme to completely overhaul the way your company builds software. Don't fool yourself into thinking you're doing anything less!
The change will affect everyone involved, your consumers, your internal customers, finance, marketing, HR, Operations and your own area.
Forget the Hype - Moving to Agile is a large organisational change programme that will overhaul your approach to software delivery.
Make no mistake, it's about people, its about change and therefore we all know it won't be easy!
The good thing is that each change is incremental, there's no big bang, you just have to keep removing barriers, impediments and keep the budgets going.
It's continuous improvement, not revolution. Every company is different, and every implementation of agile is different. Some companies adopt it with ease, others find it hard, and again others take the bits that they ‘like’ or are relatively ‘painless’ and stop there. If you want to get the best results and productivity from adopting agile then it really should hurt a bit! You're going to need help!
There's plenty of agile consultancies out there at the moment flooding the market, but fundamentally I think you need to look for experience and named resources to cover 3 fundamental areas; the organisational change, the delivery process and the engineering practices:
1. Experience of managing organisational and cultural change including the stakeholder communications, business case creation, and internal marketing. And be able to demonstrate the energy it requires. (regardless of if its agile or not).
2. Delivery management expertise, commonly Scrum is the predominant process adopted by agile teams. So look for Scrum Practitioners or Coaches with at least 5 years experience and references to back it up.
3. Engineering Practices - Extreme Programming expertise, automated tools usage, and deployment specialists... basically strong agile engineering experience - ex-Thoughtworkers and Conchango Devs are a good start.
With competence in these 3 areas, you won't go too far off track but do not underestimate the need for the Engineering Practices as it is fundamental to the quality of product and reducing cycles times to market.
And as with all change programmes... this will take months not weeks. "The propensity to exploit Agile delivery to achieve business success is directly proportional to the capacity of a company to change and continuously improve."
Comments