# Thursday, 31 January 2013

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.

clip_image002

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."



.
Tags:

Thursday, 31 January 2013 15:34:33 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Wednesday, 23 January 2013

This blog was first published in February 2005. My retrospective comments are in blue italics.

As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines.
And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders.

The key difference in approach is the way it is done, not the artefacts themselves. These pieces of information are more likely to form part of a kick-off workshop with the team defining their roles & responsibilities, the Product Owners defining the Vision and Minimum Marketable Features (MMFs), the team identifying risks and then rather than logging them, creating stories that investigate the risk to minimize or remove it. I think the key shift underlying this paragraph is the removal of the “I create” to “we collectively created…”. In Agile, the Scrum Master is not the leading voice, not the commander leading the troops. The Scrum Master is the facilitator, obstacle remover, a servant of the team.

But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager:
· The Iron Triangle
· The Role of Project Manager
The iron triangle of cost, time and scope (or quality) is typically the responsiclip_image001bility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group.
Previously on traditional projects I owned and was responsible for this triangle and reported to the project board if any risks or issues were likely to break the tolerance levels.

I have a wry grin on my face as I read this… I have recently seen a few Scrum Master role profiles describing the need for Scrum Masters to manage the project to time, scope and budget. At least when you read the job spec, you gain an indication of the level of agile adoption.
In a traditional project a deliverable-focused approach to planning is used (Prince = configuration plan), whereby all the intermediate work products and “pieces” of the solution are identified and a plan drawn up to show the route to delivery usually utilising a gantt chart or network diagram. From which timelines, resources, and costs can be identified and critical path analysis and risk management conducted.
Now scrum doesn’t throw this all away… rather we open out the Iron Triangle and share responsibility across the team, and recognise that no matter how well we plan the project, things will change, and problems will occur.
So… lets make time and cost fixed for a set period, say 4 weeks. The resclip_image002ources I’ve identify for the project will work for 4 weeks together which will cost a fixed price…
Now, let’s not set the scope as fixed, but accept that scope is variable within this part of the project. The amount of work and quality of deliverables achieved within the fixed cost/time axis will depend on people… it will depend on the team’s productivity and practices.

Let’s remove focus from the iron triangle established at the beginning of the project, and instead focus on making the team as efficient and productive as possible.
This is the key statement within the entire blog. Rather than trying to plan up front how long everything will take and then spend all your time trying to make sure the plan is followed… why not understand what the customer wants, how long we’ve got and then spend all your time helping the team achieve this by removing obstacles, inspiring them, giving them autonomy and ownership.
So the role of the Scrum Master is one of maximising the productivity of the team by removing obstacles, inspiring, motivating, and ensuring the scrum methodology is followed.
The responsibility for what is built (the scope) is then given to the business. Scrum identifies a Product Owner, a business stakeholder who has a list of the requirements for the project prioritised by business value.
Maintaining quality levels can be aided through the use of agile development practices such as automated testing, continuous integration and refactoring. http://www.martinfowler.com/articles/continuousIntegration.html

A common pattern for defining and maintaining quality in modern Scrum teams is through the “Definition of Done” (DoD) and the Extreme Programming practices mentioned above. The team defines its quality criteria for each software feature created collectively and hold each other accountable for that quality. The DoD is often printed out and placed somewhere very visible for all team members, so that everyone can be challenged on the quality of product features being created.

Obviously, many teams are not developing in isolation and therefore standards from the wider organisation, or across multiple teams of developers will naturally be included in the DoD.

Some typical problems I’ve witnessed in adopting a Definition of Done:

Aspirational: The Definition of Done should be the quality criteria by which every software feature is completed. Every team member should understand the DoD and be adhering to it every day. One of the problems that re-occurs regularly is that someone has written a beautiful DoD (back to the old PM style – commander in chief) which bears no relationship to what the team can or will achieve. I’ve regularly seen this solved by pulling the team together (usually at a retrospective) and walking through each line of the DoD asking the question “do you do this right now for all features?”

The result is a much smaller DoD, of maybe 4 or 5 lines that everything will meet and everyone can adhere to. You then encourage the team to build it up again with the rules that it is not an aspirational list, it is an operational list.

Evidence / Metrics: I’ve now grown accustomed to seeing one particular line in a Definition of Done: Adheres to coding standards [What does that mean?]

When I see this line item, I usually to ask to see a copy of the coding standards… Responses vary. Assuming that we have some standards to reference, I’ll then ask “to what level are you all following these standards?” And finally, “As a team, how do you know you’re all following the standards and none of you are creating poor code that will impede the team at a later date?”

In 2013, there is little excuse for any team not to be using static analysis tools. These tools can be configured to match your coding standards if required. Your automated builds can treat any violations of coding standards as errors to ensure no poor code is allowed in the source code repository, and beyond that, code productivity tools such as ReSharper help developers identify problems with their code as its written so it can be resolved before going into the build.

So for every part of the DoD (not just coding), we should look for ways to automatically measure adherence to the DoD. The advances in Application Lifecycle Management (ALM) such as automated builds, automated testing, automated deployments, and automated virtual environment provision & configuration, means that teams can much more easily measure the quality of what they are producing… And if you can measure it, you can improve it!

Pressure to Deliver: This problem exists in both the traditional and agile worlds, that of sacrificing quality for a short-term delivery that creates technical debt and will slow you down in the future. Often the person applying the pressure that leads to the short-cutting is unaware of the long-term issues being created, and in less mature agile teams, developers are often not in a position to directly influence the decision. Short-termism is becoming an increasingly common problem which I will cover along with technical debt in a future blog. 
The project team select the highest priority requirements (as specified by the product owner) they think they can build in 4 weeks. So time is fixed, cost is fixed, the highest priority business needs are defined, and how much is achieved (scope) is based on the team’s productivity level.clip_image003
So whereas PMs own the Iron triangle and spend their time, directing, planning, mitigating, and monitoring progress, Scrum Masters give the responsibility for the scope of the project to the business, set time and cost as fixed, and focus their efforts on the productivity of the team. The team is responsible for delivery, the business defines the direction or scope, the scrum master helps the team meet its objective for the 4 weeks.
The role change from PM to Scrum Master is not easy… releasing control and sharing the responsibility with others can be a little disconcerting. However, I’ve seen at first hand that the productivity gains in adopting this approach are impressive.

I cannot under-emphasize the fundamental mind-set shift a traditional PM will need to undergo/experience in order to become an effective Scrum Master. Many of us became strong PM’s through taking control of the situation, understanding every facet of a project, exuding assertiveness, confidence, and strong leadership and epitomising dogged determination. As a Scrum Master you have to release control, or as in my case, realise there was no control in the first place, only the perception of control.

Scrum Mastering requires a completely different style. Putting the team as the focus of attention and sinking into the background to quietly remove impediments, coach, motivate and ask questions is not for everyone. It’s the team’s responsibility to deliver the software, it’s the Product Owner’s responsibility to define scope, the Scrum Master helps the team follow the process, and removes impediments.

This can prove even more troublesome in some organisations where promotion, reward and recognition systems  have not moved with the adoption of agile methods. Companies that do not embrace wholesale change will still reward heroics, hitting a plan and getting it done OVER resolving root cause problems, innovation and sustainable growth. Promotion through how many people report to you OVER Promotion through providing business value or profitability.
The business sees its highest priority requirements built and delivered every 4 weeks. The team continually improves and increases its productivity levels, and every 4 weeks everyone knows exactly how far the team has progressed because the software is there for everyone to see, test and review.



.

Wednesday, 23 January 2013 16:10:08 (GMT Standard Time, UTC+00:00)  #    Comments [0]


10 years…

Ten whole years of my working life dedicated to creating software through agile methods. A lot of things have changed since those first few sprints. Lots of lessons learned, (usually the hard way), plenty of experience from working with lots of different people, with difference perspectives, in different locations, with diverse cultures and in unique companies.

As I went through the highs and lows of agile adoption I wrote a small but detailed blog along the way. These ‘epistles’ were usually written when I had considerable motivation to tell the story – when on a high from success, or a low from learning things the hard way. These blogs became a vehicle to vent frustration or expound virtues of some new insight or shift in mind-set.

Over these first weeks of 2013, I’m going to take some time to review these blogs, and retrospectively comment, amend and critique the thinking at the time, against the years of experience that have followed. Maybe I’ll learn something new along the way and I hope you’ll enjoy the journey too. There are 2 main categories of blogs I’ll be reviewing:

Category 1: The Basics & Tactics

These blogs are more for the people in the trenches actually using Scrum in anger (or bliss!) and consists of lessons, insights and patterns that have proven useful.

· Breaking the Iron Triangle: Project Manager v Scrum Master

· How Adopting Agile Increases Business Benefits

· The 10 Commandments of Agile Planning

· Which Agile Method?

· Launch, launch, launch

· Agile Metrics & Scorecards

· Constraining Agility

· The Machine that Changed the World

· A Nod to a Solid Team

Category 2: Transformational & Strategic

These blogs are aimed at the executive or change management audience emphasising key concepts, mind-sets and expectations when leading agile change initiatives:

· CIO/IT Director – What Agile Means to You

· Implementing Agile: Top-down or Bottom-up

· Inversion Management: 21st Century Leadership

· Agile & Transformational Leadership

· Lost in Translation

· Organisational Patterns

· Fearless Change

· Emotional Intelligence

· The Cellular Business Model

I hope you’ll share your comments with me as we go.



.
Tags: Agile | Lean Thinking | Scrum

Wednesday, 23 January 2013 15:30:08 (GMT Standard Time, UTC+00:00)  #    Comments [0]