Agile Business

Constraining Agility

2010-09-10T13:13:00.009Z

An outsider walking into an organisation can almost feel the waste and bureaucracy impeding it's progress. On the same day, a person of similar skills, beliefs and capabilities that works within the company feels they are working in a clearly organised, functional entity.

Perceptions
The difference between the 2 people is their perception of impediments and constraints.

CONSTRAINT - (courtesy of dictionary.com)
con-straint [kuhn-streynt]
-noun
1. limitation or restriction.
2. repression of natural feelings and impulses: to practice constraint.
3. unnatural restraint in manner, conversation etc.; embarrassment.
4. something that constrains.
5. the act of constraining.
6. the condition of being constrained.
7. Linguistics. a restriction on the operation of a linguistic rule or the occurrence of a linguistic construction.
-Synonyms
1. force, obligation, pressure.

For me, the difference between an impediment and a constraint is whether the individual, team, organisation, enterprise, or industry considers the obstacle as removable. If whoever is working with the obstacle believes it can be removed then it is considered an impediment, if the same person doesn't not believe it can be removed, or doesn't wish to work towards it's removal, it's considered a constraint.

THIS IS THE FUNDAMENTAL CRUX OF AGILE ADOPTION!

For the opening statement of this blog, we could infer that the outsider has not fought any battles within the organisation to effect change, nor do they know how to work through the bureaucracy, they have not had to live and be successful in this environment and so can see all the waste.

Conversely, the insider understands the process, how things get done within the existing bureaucracy (be it slowly) and has invested time and effort in understanding how it works. They are themselves valued on their ability to be successful within this constrained environment - pushing to change it does not help themselves or those people they are working with.

We are Constantly Categorising Obstacles
Our categorisation of an obstacle as a constraint or an impediment fundamentally defines how agile we are, and an organisation's ability to see impediments rather than constraints and remove these impediments will ultimately define the success of their agile adoption.

Example:
A team are adopting agile and have 20 guys in the UK and 20 guys in India. What's the best way to run Scrum?

The best way to run Scrum is to have a co-located team. Now, is the above obstacle an impediment or constraint for your project, and what are you going to do about it? Will the organisation remove the obstacle of a distributed team to become more agile, or is it a constraint to be worked around introducing waste in administration and latency in communication.

Obstacles come at us at every layer of an organisation trying to develop software:
The individual team member who doesn't want to do the scrum until 10:30am because they start late and want their coffee first
Or
The wise experienced senior developer who is so good he doesn't need to pair program
Or
The project portfolio that needs to be defined and estimated in Q3 of the previous year
Or
the industry regulator-imposed legal standards that require multiple product backlog items.

Which of these obstacles are impediments and which are constraints?
In my experience the answer is different for every individual, team, organisation, company and industry that looks at it.
BUT... Those of you that see them all as impediments are thinking like scrum masters rather than project managers. The next step is to work out how to start removing them all piece by piece. Essentially this continuous improvement is lean thinking and this takes years of work to achieve.

We need to develop organisational mindsets (or dominant logic) that sees only impediments!
A collaborative organisation that knows its vision, understands where its trying to get to, and works collectively to remove impediments, eliminate waste, create flow and therefore increase velocity.

A Nod to a Solid Team

2010-08-23T07:48:00.059Z

In this blog I've often lamented the lack of capabilities or understanding of agile practices and how few people understand what it is or what it's benefits are. There is a dilution of agile taking place that is undermining the industry.
I'm fortunate to be currently working on an agile project, and I thought that I would articulate why I am comfortable to call it an agile project.

Firstly, we are using Scrum:
2-week sprints, scrum masters, product owners and teams.
Product Backlog, Sprint Backlog, EPICs, User Stories.
Sprint Planning, Scrums, Sprint Reviews and Retrospectives.
There are a number of additional indicators that for me help to separate the wheat from the chaff:

A Business Driven Backlog with Integrated Teams
Clearly Defined, Understood and Adopted Definition of Done
The Project's Development Practices
Test Automation at Unit, Integration & Acceptance Level
Impediment Tracking & Removal

A Business-Driven Backlog with Integrated Teams

Annette Warbrick is the Product Owner for this project. Everyone on the project knows who she is, understands her role and there is a very clear prioritisation of stories. Beyond this, the project has an 'ideal-team' structure that we constantly aim to maintain. 4 x developers, 1 x technical analyst, 1 business user and 1 x proxy-product owner.

The Proxy-Product owners are responsible for ensuring the user stories are well structured and understood with acceptance criteria prescribed for each story. That is to say they do not necessarily write them all, but work with the business users, the team and various business stakeholders to ensure they understand the acceptance level for a story.

An EPIC for this "phase" of the project has been written with clear acceptance criteria, and all stories created can be traced back to the EPIC's overall objectives and acceptance criteria. Sprint zero for this EPIC was a collaborative effort with all project team members contributing to the creation, articulation and definition of acceptance criteria.

All the identified stories were story-pointed and a sampling took place to provide an indicative estimate of time. By applying this sample data to the entire EPIC backlog we created an "Agile Roadmap" for use as a communication tool beyond the programme. The roadmap is updated regularly based on releases into production every 4 weeks.

We used index cards for visibility, prioritisation and transparency of progress toward the EPIC backed up with the use of JIRA.

We've moved from an infrequent, ad-hoc deployment process to delivering new functionality into the production environment every 4 weeks. The impact of this is the rapid and constant "pruning" of the Product Backlog on an almost daily basis.
Roll Call: Laurie Brown, David Singleton, Jonathan Walters, Annette Warbrick (Prod Owner), Ben Williams. Business Users: James Curtis, Graham Baughan, Gus Croudace.

Definition of Done
Critical to the successful continuous improvement of a team is a constant assessment and revision of the definition of done from retrospectives and review throughout the project.
There are 5 elements to this team's definition of done:

1. Covered Functional, Performance and DR Criteria
- Acceptance tests run and passed to satisfaction of all acceptance criteria (with any outstanding defects accepted as not locking release and raised as story on product backlog).
- Includes acceptance of all functional and non-functional criteria.

2. Unit Tests
- Are automated (not 100% coverage but to include full automation of unit tests and to ensure maximum coverage that is reasonably possible).
- Are part of the Continuous Integration Build
- Continuous Integration build compiles successfully and 100% tests pass

3. FitNesse Tests
- Are automated in FitNesse
- Are in the Feature Sets hierarchy in FitNesse
- Contain detailed acceptance criteria and documented to describe what is being tested, how, and the expected behaviour
- Final acceptance test results have been stored in relevant sprint SharePoint folder
- Continuous Integration build compiles successfully and 100% tests pass
Impacted Regression Tests/Suites:
- Updated and /or extended as necessary
- Executed and passed in Acceptance Test environment (no blocking defects outstanding and remainder as stories)

4. Acceptance Environment
- Acceptance is performed in an Acceptance Test Environment using appropriate code, configuration levels and data

5. Configuration Version Control
- Automated where possible (using Configurator or other mechanism).
- Release Run Book and associated documentation complete
- Final release candidate regression iteration involves refresh from PROD and full runbook as pre-requisite

Any deviation from the definition of done is not acceptable as normal working process. However, there are times when either business drivers or technical impediments may prevent completing a story to the full definiton of done. The team discusses each situation and if this occurs, a new story is written to ensure the debt is re-paid in a following sprint.

Development Practices
The project is using most if not all of the Extreme Programming practices. Simon Ashdown has led the recruitment of a strong team of Java XP developers. The developers use pair programming as part of the recruitment process to try to establish candidate's real capabilities. A blend of product knowledge, business knowledge and XP knowledge has been achieved.

Pairing is the default start point for every piece of development effort. Test Driven Development is used by all developers obviously with Continuous Integration and Refactoring. The results of this approach have been good. Noting that the creation of business functionality has been the priority, not 'tidying-up' code, within a few months the following outputs have resulted as a direct consequence of extreme programming practices.

Code coverage has increased from 2.7% to 22.5%. (much of the code base was inherited from a development team who didn't write tests)
Complexity/Class has decreased by 70% across the entire code base.
Duplication of lines has decreased by 35% across the entire code base.
Rules violations have decreased by 30% across the entire code base.

The guys have been working under the informal rule of "always leave the code in a better state" and I can categorically state that the priority has been on delivery of functionality rather than fixing or improving the code. Yet they have accomplished the above through the adoption of XP practices whilst maintaining the fastest velocity of any project at this company.

Roll Call: Jason Annadani, Doug Carolan, Gareth Chapman, David De Florinier, Gijsbert Deelder, David Dunwoody, Andrew Gray, Patrice Guerreschi, Ka Fi Kan, Paul Keeble, Simon Maxen, Pawel Pabis, John Pither, Alex Powell, John Rae, and James Shiell. Analysts: Robin Roos, Julian Smith.

Test Automation
Gojko Adzic and Tom Roden have been at the centre of the project's acceptance test process. Evangelising, coaching and implementing the use of FitNesse as the automated acceptance test suite, it has become central to everything the team does.

As stories come into team sprints the product owners, business users and rest of the team assess the acceptance criteria and create automated tests in FitNesse upon initiation of the work, this provides developers with immediate acceptance results to any code they create using TDD.

Developers create their unit and integration tests as the software is written and then the FitNesse tests are ready to help the developers understand when the acceptance criteria has been met.

Most of the entire application's business functionality is automatically acceptance tested on a daily basis. The effect of automated acceptance testing using FitNesse is a dramatic reduction in man-days to complete the job of regression testing a release, as the graph below articulates.

This strategy has been key in the reduction of time to market for development and allowing the team to confidently deploy software to the business every 4 weeks. The yellow line on the graph below shows that a full regression test of the solution used to take 100 man days of effort, whereas now, due to automated acceptance test suites, it takes 3 days of effort. The graph also shows an estimated projection of what the actual number of days would have been by the end of the project in the dotted line of 500+ man days of effort.

Impediments
I guess this is the crucial element in any agile implementation. The ability of an organisation to remove impediments. The removal of impediments increases the velocity of software production, improves the quality of software production, and increases the morale of team members as their environment and their problems are being removed, and work is made easier.

At the Scrum of Scrum level, we have been tracking impediments through every sprint. We have been using an agile balanced scorecard to help inform our conversations around progress on backlog burndown, technical debt, continuous improvement & impediments and waste. Rather than nail people to changes in metrics, we use the trends to inform us of areas to improve and the impact of impediments.

The developers instigated the idea of the use of the waste snake and the scrum masters regularly reviewed the type of waste being created and the means to remove it.

In spite of all of these practices, I personally feel that we haven't really faced into the key issues in the business. The Scrum Masters, (myself included) have been proficient at removing impediments at the programme level i.e. direct area of control and influence, but wider ranging impediments that require action from departments beyond the programme area have not been successfully removed e.g. Environments, PC performance, Executive mindset and portfolio management.

I think that within this organisation, the most effective way to remove these impediments would be through executive sponsorship. As although at a programme level agile practices are understood and endorsed, beyond this level there is little understanding of how the executive role needs to evolve to correctly support agile adoption. - My experience tells me that this is not uncommon.
Roll Call: Simon Ashdown, Steve Garnett, Nik Patel, Tom Roden, Ian Shimmings.

The Future for the Team
Over the last few months, the team - from ad-hoc feedback - has become an example within the business of how to conduct software development. I am sure there are many executives reading this that would like to have a large team of strong XP developers, with business domain knowledge, automated acceptance test suites, teams integrated with business users, strong product owners and a 4-week delivery cycle from story to production.

Well, unfortunately the portfolio has changed based on valid business priorities, but rather than move this team toward the next strategic priority, the team is being dismantled. I certainly understand the need to shift portfolio priorities, but surely the learning, processes and rhythms of this team could be utilised elsewhere within the business, rather than losing the people and have them take their knowledge to the competition?

Regardless of this, I think all members of the team will have learnt a great deal from this project to take on into their future roles. I for one have enjoyed the experience, and hope my next project is as rewarding.

One Size Does NOT Fit All!

2010-07-20T12:18:00.011Z

Alot of people marketing themselves as CSMs are clearly not good enough, and have misunderstood the key concepts underlying Scrum... Some of the questions I see on groups from CSMs about the very fundamental basics of scrum are shocking.

This is evidenced in the increasing reliance of people on tools for scrum. Additionally, there is an increasing "cost" of the "infrastructure" that is coming with scrum projects is pushing the scrum community further and further away from its core values.

Scrum is about people thinking for themselves, in their specific environment, with the variables the team faces, collectively identifying potential options, experimenting with approaches, reviewing the results, inspecting and adapting...

It seems to me that too many people using Scrum are asking for help from external people, rather than working with their team to progress a problem. Scrum Masters should be talking to the people around them, the stakeholders, the team members, the 3rd parties and helping everyone to identify potential ways to move forward through innovating, iterating, communicating and negotiating.

External, anonymous people in web communities cannot possibly understand the variables your team is working with, or how best to remove impediments within the company, or how best to improve the capabilties of your specific team.

Your team know far more about the problem than anyone else!

I'm not saying that you should work in isolation, never looking at how others are resolving similar issues, but I do think that the act of thinking and problem solving is being lost in favour of "one size fits all" solution that someone else will tell you on a group discussion or from a couple of days consulting.

I believe in reading around a subject to gain knowledge and understand how others are resolving similar issues, but, the first action should be to think about it yourself, then with the team, or the customers... work with the people who are living through the same problems with you.

Learn to take on the challenge of defining a potential solution with your team, measuring the output and adjusting the solution until its resolved. Learn to communicate under pressure where not everyone agrees, learn to accept you don't know all the answers, and learn to trust in those around you and that together you'll find a solution, and then review and improve together.

And maybe your initial solution is not the best way to resolve a problem, but more importantly, you'll have worked on it together as a team in the right way. You'll have a joint feeling of having achieved a goal, and you'll be building the working relationships needed to continuously improve and adapt... You'll be better at solving the next problem together.

Generally, across the Scrum community, there needs to be more focus on people and communication, and less focus on tools, frameworks and asking for help outside of your environment.

Yes, the easy money is providing something tangible like a scrum tool, but the more important and fundamental change is achieved at the people level, by changing how teams interact and improve. This part is less tangible, takes longer, is harder, but is really what we're supposed to be doing.

Rant over!

The Machine that Changed the World

2010-05-07T07:47:00.025Z

First of all, I apologise for the length of this blog, but there's some serious stuff to be said!

The Machine that Changed the World by Womack, Jones & Roos
This is a book that has been on my reading list for a few years. I finally started it last week, and will probably have finished it by the end of next week. It's quite brilliant! Hard going at times... but brilliant.

A historical view - the story of the car manufacturing industry from Henry Ford to Toyota - from the creation of the mass production process in the early 1900's to the lean production process of Toyota in the 1980's.

For anyone interested in agile development or lean thinking, this book should be on your list.

Insight and parallels fly off the pages at you and I am finding that history is repeating itself within the agile movement. There are strong parallels between the problems faced by car manufacturers to adopt lean production, and the problems faced by IT departments / corporations in adopting agile or lean software development.

And at the heart of the entire book are the fundamental philosophies of lean thinking which resonate strongly with the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Matching Observable Behaviours, without Understanding Underlying Concepts
One of the key insights I've identified throughout the book is that companies attempting to adopt agile are making the same mistakes that western car companies made in trying to adopt lean.

Example 1:
At Toyota:
Within the lean supply chain, Toyota had a "just in time" approach to supplier fulfilment. This meant that Toyota only needed more parts when they emptied a box of parts, and therefore an empty box returned to the supplier WAS the purchase order. So Toyota only order what they need, and have hourly cycle times.

Western companies:
By observing the Toyota process, what western car companies saw was not the lean process, but the observable behaviour of suppliers conducting multiple small deliveries of parts on a daily or hourly basis. So western car companies got their suppliers to do the same i.e. delivery more frequently in smaller batches. Now for the car company this had the advantage of reducing inventory... but instead of removing the inventory from the supply chain, rather they pushed the costs of more frequent delivery and inventory onto their suppliers.

Example 2:
At Toyota:
A car consists of around 10,000 parts and various car companies (assemblers) manufacture a certain percentage of their own parts and "out-source" the rest. Toyota in the 80's was about 37%, whereas GM was 70%.

Sourcing these parts externally is an expensive, protracted process, so Toyota created a "tiered" structure where they dealt with a few hundred suppliers that provide a specific system for the car and the Tier 1 supplier then manages their out-sourced parts themselves. The approach is collaborative and in partnership, and in addition to this Toyota invests in the supplier companies, owning between 10-20% of these Tier 1 supplier companies.

Western companies...
Typically western car companies had about 1500-2500 suppliers to a car, and at one point GM employed 6000 people in their purchasing department. They made the observation that lean car companies had smaller numbers of suppliers and by having smaller numbers their purchasing costs could be lower.
So they reduced the number of suppliers... But importantly, they didn't change the relationships - they just extended the contracts from an average of 1 year to 3 years and continued to measure the value of the supplier by cost and defects per shipment. In contrast to Toyota, they did not collaborate and try to make continuous improvements to the people, process and technologies across their supply chain.

Supplier Behaviour

Highlighting this lack of understanding of fundamentals, a western supplier won a contract with a lean car company and observed that quality standards were the route to maintaining the relationship. This western component supplier focussed on delivering high quality parts, and once it established itself in the relationship tried to increase its prices. The reason for this was that it was unsustainable for this company to maintain the quality level of products delivered.

This for me, highlighted the underlying problem perfectly, i.e. aiming to mimic the output without fundamentally changing mindset, processes and the culture of the company and its relationships. This supplier did achieve the quality goals but at what cost?

Agile Programmes are Copying Observable Behaviours, but not Changing the Fundamentals!

Hopefully, from the examples above I have clearly articulated the problem western car companies faced in the 1990's in adopting lean production processes. They were observing and copying behaviours without understanding the fundamentals and making change happen.

I believe that history is repeating itself for companies trying to adopt agile practices. The fundamentals are not right. Here's a few key areas where companies are trying to adopt agile practices by mimicing behaviours but failing to grasp the fundamentals

Lack of ability to change
Fundamental and at the heart of agile practices is an empirical process. Building software with multiple feedback loops, where continuous reflection and improvements are made.

In order to support this philosophy, everyone from developer to CIO, should be focussed on impediment removal, retrospectives and continuous improvement activities.

An agile programme shouldn't be a "planned" activity, it should be an entity focussed on helping teams to become more productive, more innovative, and more efficient at delivery business value through technology.

The agile programme should therefore be driven by the needs of the individual software teams whether its environment provision, training, process change, governance change, organisational change - whatever is at the source of an impediment, defect or element of waste.

By focussing on creating a culture of continuous improvement, companies will become "agile".

Relationships over Contracts
Toyota has often been quoted as stating that transforming to a lean organisation takes 10-12 years. I believe them. I'd also add that transforming a company from traditional to agile development will take years not months.

So what relationships do you want in place if you know you're embarking on a 3-year change programme? Long ones!

Therefore supplier relationships need to be fostered and framework agreements put in place that encourage a collaborative continuous improvement process, with transparency of costs AND profits where both parties can profit from the joint activity.

AND a key change for the organisation is to focus on the retention of staff, even if this means significant pain! Software development people are knowledge workers, and when they walk, the knowledge walks.

Still Measuring Against Cost and Time Instead of Demonstrable Value
Even relatively strong agile teams are still subjected to time and cost deadlines. The purpose of software development is not to deliver to time and cost, the purpose is to deliver business value - to help the business meet opportunities and threats in the marketplace through the provision of technology.
Companies need to learn and adapt and find a way to measure the success of projects not on hitting deadlines or getting it live, but delivering business value. There are plenty of ways to do this, but changing executive mindsets is not easy and individual teams need to build enough trust with their executive to be able to work in this manner.

Still Structured in Functional Departments Instead of Value Stream Teams
All the agile methodologies are focussed on adding incremental value, of constantly focussing and business value... So why aren't organisations that have been "doing agile" for a couple of years structured on providing value to customers.
Teams need to have the skillsets to create an increment of value within the company's value stream. This does not mean a BA function, Test function, Dev function, PM function, Infrastructure function etc.

Still planning portfolios in yearly cycles instead of responding to customer demand
How many commentators do we hear say that technology changes every 6 months, for the web its faster! So why do companies persist with annual portfolio planning? I can understand it for a piece of work that will take multiple years, and then, only if broken into incremental business value. Most work is not a whole year, most opportunities in the marketplace require rapid delivery, and annual portfolios are not the answer.

The Burning Bridge
If you're still reading this, congratulations I'm impressed and I've saved the best until last. My final observation is probably the most poignant and may well be at the heart of the problems of implementing agile.
All the innovations that Toyota made, that collectively became known as Lean Thinking were forced upon them.
Toyota had to evolve and had to change. They were being threatened by US imports, did not have the capital to copy the US system of manufacture. They also had union issues which resulted in Toyota's "job for life" contract where all their employees were guaranteed a job for life. This meant that employee salaries became a fixed cost, and therefore they needed to "sweat the asset" which means pushing more responsibility towards the coalface and reducing management heads.
In a competitive market with considerable constraints they needed to constantly reduce costs in order to make a profit and build consumer trust - there was a compelling need for change otherwise they wouldn't exist.

Most change management books and guru's talk about and allude to "Creating the Burning Bridge". Scaring everyone enough so that they will feel uncomfortable and see the need to really change." And lets be honest, if you're making profit and fairly comfortable, why change?

Thoughtworks pretty much established its business by taking on failing projects, because when something's so bad, maybe you'll be willing change things and do things differently!

This may well be the true reason why significant and continuous improvement is eluding agile teams.

Agile change programmes need to create the burning bridge, and then spend their efforts removing impediments, actively working on retrospective data and continously improving the organisation.

Human nature is getting in the way!
Evolution through fight or flight, but what if there's no impending threat?

CIO/IT Directors - What Agile Means to You

2010-04-28T14:55:00.007Z

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.

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.

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

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."
Steve Garnett 2010

The 10 Commandments of Agile Planning

2010-03-11T08:37:00.015Z

Agile planning is a subject that can cause a disproportionate amount of noise, frustration and misunderstanding across agile projects and programmes, departments and companies.

Let's start at the beginning by quoting part of the Agile Manifesto:
"...through this work we have come to value: ...Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more."
So, first of all there is value in following a plan, but we value responding to change more.

The problem we are dealing with exists at a deeply engrained cultural and organisational level, and that is corporate governance. Most corporations run on an annual planning basis steming from accounting and investment cycles. Quarterly updates are expected against this plan and any deviation from this forecast (whether positive or negative) has an immediate impact on the share price, investor confidence and ultimately the well-being of the company.

This fundamentally means that costs are planned on an annual basis, portfolios of work are planned on an annual basis, and therefore resources are budgeted and assigned on an annual basis. So... How can an iterative process be planned for!

If your company works in this matter, you either have to change that process (not for this blog), or adapt, and provide a project roadmap/ longer-term plan/estimate. The problem we all face is that no matter how many caveats and assumptions we provide with this forward looking view, expectations will become set as milestones because the rest of the business needs to plan marketing, budgeting, resource allocation activities etc off the back of the software you are producing. "When will it be ready!"

So, unless you can change the entire company, you have to provide a long-term estimate.
But HOW you produce that estimate IS in your power.

The 10 Commandments of Agile Planning

Commandment 1: Thou Shalt Create the EPIC
Create the EPIC with the sponsor - get them to write it or at least review and verbally say yes this is kind of what we're after.
Write a user story that encapsulates what the person paying the bill wants. e.g
As the person on the line for this software and paying the bill,
I want lots of good software,
So that... things improve in certain areas,
And the value to the company... is that we make lots of money.
The Acceptance Criteria is that there are lots of ticks in lots of boxes.
For more info on User Stories: http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development

Commandment 2: Thou Shalt Make the Plan a Backlog Item
Write a user story to create a Project Roadmap with associated value defined and acceptance criteria.

Commandment 3: Thou Shalt Timebox the Planning Activity
Discuss with the sponsor how important a long-term view is and whether it is the highest priority item on the backlog, and ask them how much time/money they want to spend on completing the plan. Once the time/money is agreed calculate/set the timebox.

Commandment 4: Thou Shalt Go Forth and Communicate
Recognising that this is an estimated guess and working hard on the communication of this fact is a critical activity... It is an opportunity to educate your peers, sponsors and stakeholders in the nature of software development and the difficulties of trying to predict a non-predictive process.
Once you start this communication, ensure that you promise to update the long-term view on a regular basis e.g. every release or every sprint - I'd suggest at least every 6 weeks depending on sprint/release length.
Agile development is an iterative process, and therefore the roadmap will be iterative and regularly updated. You can also talk about the ability for the business to change it's mind as it goes and talk about velocity and how it is grounded in actual performance.

Commandment 5: Thou Shalt Engage the Entire Team
Involve every team member in the process. This will help to ensure everyone understands WHY they are doing the work, HOW the product backlog has been prioritised, and WHERE they fit in making it happen. Encourage the team to challenge each other throughout the process - what's the minimum required to achieve the business objective? Is that the best fit of solution? Is this really a high priority? Is the acceptance criteria clearly understood?

Commandment 6: Thou Shalt Iterate Throughout the Process
Have you ever been in those planning sessions where you've booked a room away from it all, and the entire team goes through the backlog trying to assign story points. And the points get bigger as you go because less is known, and the issues and assumptions list becomes as big as your arm? Take a chunk at a time. Divide the backlog into buckets of stories in priority order and ask the teams to take on stories for estimation, then close the meeting and allow time for the teams to go away and investigate and properly assess the work.
This way they can collaborate, challenge and communicate about the backlog and priorities and find out more about those assumptions and issues. Then meet again and take on the next bucket of stories until all stories required to meet the acceptance criteria of the EPIC have been looked at.

Commandment 7: Know Thy Backlog
The Product Backlog is probably one of the most, if not the most, important artifact to enable a project to provide business value. Ensure adequate resources are supporting the Product Owner to be able to articulate the stories, prioritise the stories and define acceptance criteria. Reviewing and updating the backlog becomes part of the planning process and there is no reason why all team members can't get involved in this activity.

Commandment 8: Thou Shalt Say How Big It Is
Separate the estimation process into 3 parts:
Firstly, how big is this story?
Secondly, how long will it take?
Thirdly, when will it be done?
To define how big the story is use Story Points. In relative terms, how big are each of the stories. Discuss and agree with the team a points systems e.g. fibonacci. Then agree a range ie. 1, 2, 3, 5, 8, 13, 21, and agree the largest points "allowed" on the backlog. Part of the process is to break down larger stories so that they fit the agreed scale.

Commandment 9: Thou Shalt Say How Long It Will Take
So this is the crunch part where everyone gets very uncomfortable, because to be honest no one knows. So why spend too much time on it? I like the sampling approach.
Each team, once they've sized (story pointed) their stories, takes a small, medium and large story. They should be stories that the team has a high level of "confidence" or "knowledge of" or are "comfortable" with.
For these 3 stories, go into a task identification and estimation process and task out everything required to complete these stories. Adjust point sizes and debate within the teams until the team recognises or identifies a ratio of number of points : number of days estimate.
This ratio is then applied across all stories regardless of the level of knowledge.
From this sampling applied across an entire backlog, the "when will it be done" can be extrapolated as a "numbers game".

Commandment 10: Thou Shalt Repeat This Process Regularly
Depending on your sprint and release length, repeat this process regularly as required by your sponsor. At the end of each release, use the actual velocity of story points burnt down in the release to update the roadmap to provide an indicator of how effectively the team is achieving the roadmap. Hopefully, you will only need to create a roadmap once for an EPIC, and then normal release planning can resume and the roadmap updated based on velocity as an admin/numbers task.

Summary
No one who is experienced in software development and agile development in particular, wants to try to predict a non-predictive process. But... Until companies change their governance structures to match the planning period of release cycles (unlikely for most people), longer-term agile planning will be required.
But, by using these commandments I think you'll benefit from the following:
1. Transparency with sponsor on scope and acceptance criteria of project.
2. Transparency with sponsor on the cost and time taken to provide the plan.
3. Buy in from the team because it's the highest priority item on the backlog and the sponsor wants it and is willing to pay for it!
4. A better product backlog by the end of the process.
5. A joint understanding across the team of why the project exists, and what the business expectations are.
6. Open communication channels with sponsor and stakeholders.
7. Expectation of updated roadmap on frequent basis, based on actual velocity being achieved.
8. A consistent means of measuring velocity.

Which Agile Method? Some Considerations

2010-03-10T08:51:00.024Z

Hi,
We are not here to do agile, we are here to deliver technology solutions to help our businesses realise opportunities, strengthen weaknesses and fend off threats.
We use agile tools to achieve this.

If you and your team are unable to deliver, then it doesn’t matter how good your "agile" capability is, you’re failing to meet your primary objective.
A few years ago, I was working on a project with a number of issues and lots of noise and luckily for me, Ken Schwaber was working with us at Conchango at the time. When I talked to him about some of these project issues he gave me some priceless advice...
“...just get the software out of the door!”
This is the essential part... if you keep delivering stuff, you’re helping the business and adding value. Too many so called “agile” developers focus on how “well” agile is being done rather than how much value is being created for the business.

Recently, our programme adopted Kanban for a period of time to solve a particular phase of the project and it was deemed extremely successful, now we have reverted back to Scrum for a different phase.
A critical blog that helped the entire team understand the logic and goals behind Kanban.
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
If you are considering using Kanban, you should definitely read the above article first. It's a great piece of work to describe the differences and relationship between the methodogies.

The following diagram created by Henrik Kniberg shows methodologies along a range that includes the number of their artifacts and their relative position with regard to adaptive and prescriptive approaches.
So how do you decide which method to use?
It's all about discipline and trust!

Software development is a complex, non-predictive process, and just because you might adopt an adaptive or non-prescriptive methodology, it doesn't mean you reject all the other activities and artifacts! It means you pick and choose the ones your team thinks it needs in order to produce the software.

So, implicitly, the adoption of adaptive methods means that you trust your team to make those decisions, that you trust your team to be disciplined in approach, and that you trust the teams to take responsibility for their actions.

I would suggest that anyone attempting to adopt agile methods consider this very carefully. Is the team adopting the methodology proficient? Are they responsible individuals, are they disciplined in their work? If not, don't do it.

There are too many teams out there seeing agile methods as a way to cut corners... there's no shortcut. If you have fewer artifacts within the methodology, then you have to think more for yourself, you have to be more disciplined in your individual activity, you have to communicate better than you ever have before.
Personally, I would never adopt Scrum without XP development practices.

The question comes down to "how good are your people?" Where agile techniques have been successful, teams have shown value to the business in creating better software quicker through removing "prescriptive" activities and increasing their own discipline and responsibilities.

Software development is a complex process, and removing the prescriptive activities does not lead to immediate success. These prescriptive activities need to be replaced by strong development practices (XP).
Are your teams using strong development practices?
Are they all working to a clear definition of done?
Are they disciplined in approach?
Do they coach and mentor each other so the team and product is always improving?

If the answer is no, you are increasing the risk to your business.
Do not adopt increasingly adaptive methods without considering these points.
Oh... and Good luck!

Agile Metrics & Agile Balanced Scorecard

2010-03-03T15:11:00.013Z

Certainly within the agile circles I am working, there is a growing focus on agile metrics. This for me, is both a blessing and a curse.

The blessing stems from the lessons I've learnt from Six Sigma and Lean about measuring success and being able to demonstrate value. The curse is that invariably metrics becoming a big stick for executive management with little understanding or consideration for the context, environment or mitigation...

Only the number is remembered.

There is an inherent human instinct around numbers. Because they are a quantitative representation, they are often preceived as concrete, and are rapidly communicated.
The next time you state or hear a number in conversation, note how easily it is remembered and communicated.

Numerical values are finite, can be made readily available, easy to put into graphs and presentations... but don’t really tell anyone what’s going on. Numbers are a very small representation of a large amount of work and effort and information.

Lesson 1: Remove the Numbers
We value “Individuals and interactions over processes and tools."
The use of metrics within an agile environment should be seen much as Stories are...

A sign-post to have a conversation.

By removing the numbers on the scale you’ll probably start a conversation, that hopefully you can move to a discussion on trends, retrospective and improvement areas rather than focussing on a number and debating a single instance.

Lesson 2: Create Your Balanced Scorecard Around a Discussion
There are plenty of blogs on the web prescribing agile balanced scorecards, any of which, from what I can see, may be of use.

But before you go and grab a ready-made template... think first about why you're doing this.

The original balanced scorecard
http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx

was about ensuring companies remained sustainable and executive boards maintained a balanced view of their company even when financial pressures would dominate their individual focus.

The original balanced scorecard focussed on 4 areas: the customer; the finances, processes (inc IT) and the people.

It's a simple concept of realising that in order to please customers you need to spend money, but not put yourself out of business pleasing customers.
You need good people, so don't under reward them otherwise you'll lose them.
Hire good people but ensure you have robust processes to help with consistency of service etc...

In other words... ensure you have a balanced business.

An Agile Balanced Scorecard is about ensuring your projects are balanced... And before figuring out which to use, first think about what your project cares about.

Burndown is often considered a key indicator, and with my current project was the only indicator being measured at the enterprise level. But what about technical debt? It's no good burning down huge amounts of product backlog if you are accumulating huge amounts of technical debt.

And if retrospectives and continuous improvement are essential to your project (I hope they are!) then capture a measurement of waste to demonstrate how much improvement is being achieved.

An Example of a Balanced Scorecard
There are a wealth of conversations you may wish to have with executives in order to get them to help you improve the delivery capability of your team. Examples might include: More money for environments to increase velocity; more business involvement to build more usable software; money for automation tools; specialist resources to improve your people.

The first area of my most recent balanced scorecard is about discussing the balance between rate of burndown and levels of quality and to know that the team is incrementally improving its velocity. So the scorecard includes burndowns and technical debt indicators.

The next area of my scorecard would be a discussion point for activities related to continuous improvement. So its important to ensure that the team is learning to improve and that retrospectives taking place, actions are being identified, and impediments are being removed.

Finally, I want to know how efficiently we’re doing all of this and measure our progress and this area I've called "Lean". I want to understand the trends for cycle time to market - from adding an item to backlog to delivery into production how long does it take.

I also want to know how much waste exists in the process and the type of waste so that I can initiate conversations for change in other areas of the business, which may increase my speed to market.

So my own Balanced Scorecard would consist of a dashboard of 4 areas:
1. Business Value Creation – product burndown
2. Technical Debt –non-adherence to definition of done, and code quality
3. Continuous Improvement – retrospectives, action plans, impediments raised and removed
4. Lean – Cycle time, types and amount of waste

Summary
The Agile Balanced Scorecard should be a "discussion sign-post".
With no numbers stated in them the discussion is about trends and progress towards the goals of the project or enterprise.

If you are adopting metrics or scorecards, think long and hard about who needs to see the metrics and what for...

Do not create them as reports for emailing upwards, create them around a meeting to discuss what needs to be done next.

The Cellular Business Model

2010-01-12T13:53:00.008Z

Hi,
I've just published my first white paper which might be seen as a bit "left-field" but sometimes its nice to read something different.

It's free to download via Linked In Slide Share at http://www.cellularbusinessmodel.com/
or via Google Docs at http://docs.google.com/fileview?id=0B7WeMa-zlDRuNzRiNDRmNzctMjhkZi00MWMzLTg1NmEtNmVlMzhjZWY3ZDI4&hl=en_GB

Here's an abstract to whet your appetite!

In my opinion, last year, the two biggest news items were the banking collapse and its impact on the economy and businesses, and the terror threat and terrorist organisations. I remember thinking at the time that some of the businesses making cuts were taking preventative action and trimming their fat. This led me to think that this should be a continuous activity not just initiated when major threats appear.

Additionally, I recognised that although the terrorist actions are despicable and cowardly, they are successful, and the terrorist organisations are winning the battle. They have global coverage and continue to disrupt normal life, whilst working against the considerable resources of western governments.

In concert with thinking about these news items, I found myself focussing on the abundance of waste within large corporations and comparing that with the efficiency of some of the agile software teams and military teams I’ve worked with in the past.

From considering the combination of these thoughts and concerns, the Cellular Business Model has evolved. The paper sets out the tenets of the Cellular Business Model which takes lessons from the structure of terrorist cells and small teams, and aims to achieve the same level of effectiveness at the enterprise level.

Following an introduction to the Cellular Business Model, the paper goes on to introduce lean thinking, scrum, pattern theory, open book management and cloud computing as a means to establish the Cellular Business Model.

Through publishing this paper I hope to spark ideas, energy and thought around corporate agility.

The Goal is not Scrum!

2009-11-20T10:39:00.008Z

Increasingly, I am becoming concerned with how Scrum is being perceived, adopted and implemented. I've read a number of blogs bemoaning the fact that the fundamentals of scrum are not being followed, and then when the process is followed the mindsets are not shifting.

Scrum is just the beginning of the transformation of software development for a company. Implementing the Scrum process correctly is the critical foundation. Don't leave retrospectives out, or do scrum every other day, just follow the whole process as defined.

Once you've established and are following the scrum process other less tangible changes will take place. Individual team members will experience a change and shift in their mindset and perspective, teams will change their culture, velocity will increase and then you'll hit the next brick wall...

Product quality and the ability to adapt it. This is where Scrum needs Extreme Programming practices, a company can run Scrum well and still have poorly architected and constructed code with high costs of on-going support, and low levels of flexibility.

So Scrum and XP coding practices need to be adopted. When you're up and running with Scrum & XP you've come along way... But then the next level of complexity hits you.

Your velocity as a programme or department is out-stripping the rest of the business. I.e. Support teams can't keep up, or procurement can't handle the speed of decisions or respond to impediments, or the business hasn't the capacity to support the development etc.

At this point, I think its time for Lean Thinking. Lean thinking is a tried and tested approach to rapid business improvements across multiple verticals. It is coached in business terms, using business language, and rapidly transposes both into agile software development and other departments across the enterprise.

Scrum is not the goal, an agile, adaptive, responsive supply of products and services to our markets is what we're trying to achieve. You need Scrum, XP & Lean thinking!

"Launch, launch, launch..."

2009-11-18T08:26:00.013Z

What follows is a suggested approach to tackling impediments on the critical path within a scrum environment.

In another life, I was in the Royal Navy serving at sea in an operational environment, and we used to "play" war games. During a war, the control of the ship shifts from the captain and the bridge to the Ops Officer and the Ops room.

Various teams across the ship are working on understanding the threats to the ship and the opportunity to attack targets. The sonar team will have contacts that they are assessing, radar will be picking up contacts, communications intelligence will have information on aircraft chatter etc.

The Ops team are assessing threats in real-time and the individual teams are all working on providing more information to the Ops Officer on when to launch weapons or countermeasures...

"Missile away"
"Launch, launch, launch, bearing 274 degrees"

Upon a communications analyst hearing missile away on aircraft chatter, they scream that a launch has occurred and the bearing. The Ops Officer then turns the ship towards the missile to present a smaller target and the entire ship focusses on the immediate threat...

I'm currently working with a team who ARE the critical path for a major programme of work, we're hitting impediments on a daily basis and have adopted an approach similar to the above.

As soon as an impediment is hit, we pair up. (Alot of people will already be pairing). The pair is then time-boxed at 20mins to identify potential solutions and move to resolution. If no resolution is on the horizon within 20mins, the entire team stops, the problem is white-boarded and discussed to identify a way forward.

The negative side is the 30 mins that could be lost for the entire team during this period which is why I would only suggest this for critical path items. However the benefits are transparency, lots of minds on a single problem, sharing the load and risk, building team cohesion.

Just a thought for your toolbox.

Scrum is Dead, Long Live Scrum

2008-11-19T10:48:00.008Z

Hi,

"The king is dead, long live the king!"
People continue to be subject to the king even though the new king may be far less of a monarch than the previous one.

I recently attended the Scrum Gathering 2008 in Stockholm, Sweden.
It was great to see some of the old faces again and its great to recharge and re-energise by talking to like-minded "agilists".

The best day by far was the Tuesday when we did Open Space. This is when you're able to vote with your feet and be involved only in those topics you're interested in.

As a Scrum Practitioner I was able to both support people new to scrum, as well as talk to other practitioners and trainers about larger issues. These issues included integrating scrum within corporate governance models, contracts for agile methods and lean initiatives across companies outside the direct software development capability.

What was disappointing but not wholly unexpected, was the considerable shift from an informal gathering of like-minded people interested in learning and sharing scrum experiences, to a commercially-oriented, brand aware business conference.

The flagrant use of corporate presentations, and the "selling" of agile products and services by consultants and trainers alike really disappointed me. Obviously, there's now some real money to be made with agile and scrum and the bandwagon is super-charged.

Ultimately, Jeff Sutherland's joint corporate presentation promoting off-shore agile teams clearly showed to me that the old Scrum is dead. If the purity of a methodology cannot be maintained at its source, and promoted as the ideal, then those compromises will filter down and out across the board.

The message at the source of a methodology, which are the scrum gatherings, should be about the "ideal" and "pursuing perfection". The open spaces then become discussions about how to overcome obstacles preventing that goal through sharing experiences.

I'm hoping that other attendees provided similar feedback that reflected the frustration with corporate presentations and the need to revert to a more intimate, open space approach for the entirety of the next gathering.

I am however resigned to the fact that commercial gain will further dilute the real value of scrum until it becomes a shadow of its former self.

Scrum is Dead, Long Live Scrum!

Fearless Change

2008-06-24T13:18:00.011Z

I've recently joined T-Mobile as Agile & Online Programme Manager, and although there is an appetite in localised areas for agile adoption, there are some more fundamental areas of change required before real progress can be quantified.

Corporate IT strategy, budget governance, resource models, enterprise architecture and software development all need to change and require long-term commitment. Shifting towards agile concepts, mindsets, methods and practices is a significant undertaking and clearly, Toyota's statement of 12 years to "lean" is not only true, but probably an understatement.

Over the last few years software developers have often proselyted the use of software patterns, and having read around Alexander's original architectural patterns, I've become a user of organisational patterns.

The core, unique benefit of pattern theory is that it is the codifying of experience. This isn't some individual's idea of how to do something; patterns are derived from actual experiences of a problem context, the solutions that were applied, and that have worked before... Many times.

I've previously blogged about Coplien's book on Organisational patterns of Agile software development, but I've been using change patterns from a book called Fearless Change.

These patterns codify key lessons learnt by people who have tried to introduce innovation within corporate entities. This is not just about introducing agile, but about any innovation, and the benefit to anyone new to change management is that there are tried and tested patterns available.

Key roles identified include the maven, salesman and connector. Patterns I've used and that are bearing fruit include Evangelist, Do Food, Just Do It, Test the Waters, Small Successes, Time for Reflection, Step By Step, Plant the Seeds, E-forum and Brown Bag.

The other benefit of using this book as a tool, is that it is supportive to people in the midst of the struggle to introduce change and innovation. Others have been where you are now, and this is how they succeeded!

If you are not aware of, or using, a facet of pattern theory, you're missing a trick!

Agile Leaders - The Next Hurdle

2008-03-19T23:45:00.006Z

So you know what Scrum, XP & Agile are all about, got the T-shirt etc.
You're fine tuning scrum practices in your company.
You're running multiple scrum teams, you've adopted most of the XP practices, (test driven development taking a while?).
Agile approaches are spreading across your company's project portfolio.
You've even achieved the holy grail and have board level support!

What's next?
Where do you focus your long-term thoughts?
How do you get the entire company behind you?
How do you create an Agile Business?
What does your next learning curve look like?
How do you achieve more?

Answer: Lean Thinking & Financial Understanding

Too boring?

Who'd have thought that there are a simple set of principles, that when correctly applied, rapidly improve any business in any sector of industry. And, when applied to other departments and functions within your business, will enhance and improve your own project team's output.

Have a good look at your previous impediments. Which took the longest to overcome? Were the long-standing ones due to outside influences?

Is your procurement process too slow?
Infrastructure teams inflexible?
Funds not available?
Training budgets restricted?

Lean Thinking is the best approach to achieving "Agile" levels of performance across the business. And the easy part is getting started.

Lean starts with Eliminating Waste, and from my experience the identification and elimination of the 7 types of waste leads to immediate cost savings directly visible on the bottom line.

This is something the board will understand immediately!

Every single business regardless of sector has waste, and with some thought and application you can "Learn to See"the waste in your business and start removing it.

I recently completed a value chain analysis which has identified savings of over £250,000 per annum. The project to implement the changes began this week.

This isn't rocket science, but it does need you to step out of the comfort zone. You do need to analyse and understand your budgets, performance, and processes. My time with Shaun Mundy at CPM showed me the value of this.

It's alright being bloody great at Agile, and knowing how to deliver software and create self-organising teams, but always remember that the engine for change, the real way to effect change, is control of the P&L.

Agile leaders need to understand and learn to speak the language of the P&L, balance sheet and cashflow if widespread corporate level change is to be accomplished.

Couple financial understanding with lean implementation and Agile leaders will be building not only successful agile project teams, but successful agile companies.

So, go on, nip down to your accounts department today and ask for last month's P&L.

I dare you!

Mary Poppendieck is "Yoda" on this subject - http://www.poppendieck.com/
http://www.lean.org/

Inversion Management - 21st Century Leadership

2007-03-12T17:41:00.002Z

Using the term "Management" in the title of this blog, reflects part of the problem with the dominant logic of mainstream business.

I've been with TV Network for just over a year now, and its been exciting, frustrating, inspiring, draining, hard work and fun!

Establishing an agile project, running an agile programme, creating an agile department, evolving an agile company... each level requires new skills, different perspectives, perseverance and openness to change.

Your perspectives change, you change...

I believe the most successful business leaders today are shifting through an Inversion of Leadership.

The inherited perception and mindset of management, is one of hierarchy, command & control, transactional leadership, management by exception, reward & recognition, sequential projects and long-term strategic planning.

Agile leaders believe in flat structures for real-time communication, encourage delegation and de-centralisation of control, exude transformational leadership, are naturally inclusive decision makers, care about Corporate Social Responsibility, adopt iterative processes, create vision, define objectives and are continuous change agents.

Agile leaders exist as a minority not only in software development, but in all industries.

The mainstream, pervading approach to "management" is based on reward and recognition, direction and control.
The emerging approach, for successful companies, will be leadership and vision, delegation and inspiration, training and mentoring, support and coaching.

From my experience it is much harder to be a leader, coach, delegate and mentor when there are deadlines, profit/loss and long hours to deal with... but at the same time you can achieve a hell of a lot more.

Do I think Inversion Management will replace mainstream practices?
Will agile leaders be wanted across business?

Not until the current mindset of shareholders, the stock market and banking institutions of looking at quarterly profit margins, and quick revenues, shifts to being concerned about sustainable business, sustainable wealth, and the ability of companies to change and innovate.

"Agile" or "agile"

2007-03-08T18:29:00.002Z

If, like me you seek insights into how to really create "Agile" businesses, I'm afraid there's a mountain of hype, miscommunication and misunderstanding to wade through.

"Agile" has over the last 2 years become the latest "fad" in business circles (certainly I.T. circles) and so of course, every Tom, Dick and Harry is jumping on the bandwagon trying to make a "buck!"

I attended a Scrum Gathering in the States about 2 years ago when the issue of how to rapidly implement Agile across large organisations was a key topic. The truth is, that as with anything in life, it takes time, alot of time, to get something worth having!

Toyota are quoted as saying it takes 12 years for a corporation to become lean, and I believe them.

"Agile" with a capital A, is not just about adopting a methodology or some SOA or web services architecture; Agile is about shifting executive, middle management and "coal-face" employee mindsets from heirarchical, document-heavy, linear thinking to creating an organisational culture that embodies the tenets of the agile manifesto:

To really value collaboration over contracts, the individual over processes and systems, and value responding to change, over long-term planning.

This is Agile with a capital A, and a true understanding of Agile can only be achieved by pioneering it within your own sphere of influence and experiencing it for yourself. If you want help getting started see Womack, Jones, Poppendieck and Schwaber for reference.

Any company, person, or software architecture can claim to be agile, but, to cut through the hype you need to find those people who know the difference...

"Agile" with the capital 'A', or "agile" with a small 'a'.

Product Backlog for One?

2007-02-08T16:55:00.002Z

Hi,
A couple of weeks ago a colleague of mine was having a terrible time at work, highly stressed, a mountain of work, and thinking she'd made a big mistake joining the company.
We went for a Starbucks (thank the lord for making Starbucks) and a chat...
The issues were a great big pile of work and many masters... Not uncommon I think.

I just told her a few "tricks of the trade" that had been passed onto me, and now things have "turned around 100%".

1. The biggest source of stress at work is people. We're either communicating poorly, not empathising, not understanding the complexity of tasks, got hangovers etc, etc, etc.... Once you understand this, you can filter the noise and get on with the work.

2. Have a daily action plan... I don't care who you are or what you do, but spending 10 minutes at the beginning of the day thinking about and writing down what you'll achieve by the end of the day is a MUST!
It helps maintain your motivation and focus, and maybe there'll be a sense of achievement at the end... (Although sometimes its more an indicator of what didn't get done!)

3. Every task has 2 factors! They are Urgency and Importance. Draw a 2x2 matrix, if its urgent and important, get it done! Important but you've got a couple of days, then schedule the time and keep to the schedule.

4. Communicate: With 3 or 4 senior managers screaming for results, understand 2 things:

1. It is not your responsibility to ensure that tasks are evenly distributed across a team, but IT IS YOUR responsibility to be as productive as you can, and work to the required quality levels.

2. The person who knows the most about the tasks you are doing, is you! The person at the coal-face is the expert. So... Tell people what is going on. Be as transparent as possible about your workload. [Geeks: Product Backlog for One!]

The action plan we agreed on, was to clearly articulate the current task list in priority order, to communicate it to all relevant managers, and to elicite feedback on whether any of the priorities were incorrect....

The result...

The managers are aware of a huge task list, can see the other relative priorities, argue between themselves what the relative priorities are, and see an employee working hard. [Geeks: A bit like Steering Group members arguing over a Product Backlog].

This is such a simple exercise and has been part of my daily routine since god knows when.
But I never went on a course for it. It was gleaned or given as advice from mentors or friends.

Its probably one of the most important things for anyone to learn at work!

All Change

2007-01-05T12:08:00.001Z

Hello,
What a difference a year makes!
I've moved from Head of Development with CPM, to Head of Technology & E-commerce at TV Network, the UKs biggest Direct Response Television Company.

There are lots of projects going on at the moment, but the most pertinent for this blog is Chrysalis 7. Chrysalis 7 is a Lean Thinking Programme to introduce lean practices, culture and organisational change http://www.leanuk.org/.

Having implemented lean initiatives within the software industry, I am now leading a programme to use lean thinking across the entire supply chain. i.e Manufacture, Logistics, Warehousing, Call Centre and Customer Service.

We kicked off late last year and are currently mapping the Value Chain in teams across 4 different companies which represents most of the value chain. We've adopted Scrum as the project management methodology for the programme (a first for DRTV I think!), and with distributed teams, complex processes, and in-built, multiple "company cultures", we are facing similar problems to those experienced when adopting scrum for software development.

In addition to adopting lean thinking, we are moving to Open Book Management. Open Book is a relatively old management theory from the early nineties best described in the book "The Great Game of Business" http://www.greatgame.com/products_books.php. It's very close to the "agile heart" being about full transparency and ownership of risks and rewards, and a clear understanding of the effect of one's actions through continuous feedback loops.

As I say, the programme is at an early stage, but any thoughts and insights will be posted here, along with any parallels with software development.

Steve

Lost in Translation

2005-12-05T20:41:00.002Z

Enterprise Scrum - Tactics for Implementing Agile Practices

If you are implementing agile practices, methodologies and organisational changes within the company without full executive support, you are probably facing an uphill struggle.

I was watching a TV documentary on the space race the other day, and one of the interviewees stated that in today's world nobody takes any real risk... This is fundamentally the problem you face, agile is perceived as high risk and difficult to manage.

From a traditional management perspective, it is!

Agile is about recognising there is a limit to control, that all things are not predictable, and that although we have clear objectives and a general direction, the detail of functionality and architecture is unknown at the beginning of a project. Managers need to learn an empirical approach to work and ensure that feedback loops and frequent communication are embedded within the fabric of the organisation.

So with so much risk... cost, direction, control, design, architecture, functionality... why would any career executive want to take on agile?

One approach is to lose the agile message in translation... Or rather, put the agile philosophy into accepted company lore / language.

If your company has adopted Kaplan & Norton's Balanced Scorecard approach (http://www.bscol.com/), as a vehicle for strategic change programmes then use it for your agile implementations.

If Jones & Womack's lean approach is the driving force within the corporation, then use Mary Poppendieck's Lean Software Development philosophies (http://www.poppendieck.com/) to build lean projects.

I'm Head of Development at an SME where we use the Balanced ScoreCard for strategic implementations and have a "lean" initiative. Although the ideal use of these models could be questioned, I am translating the needs of the development team, into the terms, language and presentation formats that fit the culture, dominant logic, and decision-making processes of the company.

When considering your own corporate environment, what are the key business drivers?

Cost cutting and risk reduction?
Value Creation and Customer focus?
Quality & Excellence?

As with everything else within agile, implementing enterprise-wide scrum (agile) is about understanding the context of the situation, applying your brain, and having the balls to go ahead and do it. Agile practices have a way of supporting each of the potential business drivers above, we need to ensure the message is palatable for the company culture and executive, without diluting the practices and methodologies beneath.

I believe that the true success stories for corporates adopting sustainable, effective agile software development teams will depend on our ability to "manage" or "lead" organisational change.

Understanding and managing the levers of organisational structure, business processes, stakeholder management, decision hierarchies and communication are the key competencies required by people implementing scrum and agile at the enterprise level.

Organisational Patterns

2005-11-01T21:12:00.002Z

One of the most enlightening and practical books I have read recently is Organisational Patterns of Agile Software Development by Coplien (http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/002-3524002-2666431?v=glance)

Alexander's original pattern theory applied to architecture of towns and buildings.
http://www.amazon.com/exec/obidos/tg/detail/-/0195019199/qid=1130880069/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books

Design Patterns for Reusable Object-Oriented Software introduced the IT industry to pattern theory. http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/qid=1130880169/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books

Coplien's book is the result of 10 years of research into successful software development companies. I'd argue that the use of the Agile word in the title is related to profit rather than a tre depiction of agile patterns. Coplien's book uses pattern theory to describe organisational architectures that can be used to solve particular problems within a specific context.

The value of pattern theory is that the patterns identified aren't theories created out of thin air, or a methodology created by a process engineer; patterns illustrate empirical evidence of successful implementations of a solution to a particular context.

Too verbose? OK, wouldn't it be great if when you came to a problem at work, you could know how hundreds of people have solved the same problem in the past?

Coplien has identified and describes how certain organisational problems in software development can be solved through the application of patterns within a specific context.

Some of these patterns are fundamental to both agile teams and agile organisations such as:

Community of Trust
Get on with it
Development Episode
Engage Customers
Unity of Purpose
Developing in Pairs
Conway's Law

There are many more, and as you read through the book it feels like a "book of common sense," although these days we should refer to the gift as "uncommon sense!"

One of the patterns I have relied on recently is the Architect also Implements pattern which I have discussed with Technical Architects within the team. This pattern suggests "A software project must broaden the scope of leadership without sacrificing depth and attention to pragmatics" and "Beyond advising and communicating with Developers, Architects should also participate in implementation."

For me the lesson is to always keep in mind is that Technical Architects should not be Isengard Tower wizards out of touch with teams, rather they should be Master craftsmen of their trade. Still creating elegant, efficient software but also designing with, coaching and mentoring others.

If you're looking into structuring teams and organisations for agile development, this book needs to be on your research list.

Implementing Agile - top-down or bottom-up

2005-10-26T14:42:00.002Z

If you are considering implementing agile approaches in a company or large department one of the first considerations is whether to adopt a top-down or bottom-up approach.

Agile practices are about self-organisation, self-learning and shared responsibility across a team. Using scrum and XP practices, teams are given the freedom to innovate within a highly disciplined development environment.

Freedom and discipline seem like opposing forces... they're not.

A top-down approach is incongruous to agile philosophy, it implies a directive authority setting the approach. This approach is in line with Transactional Leadership (http://businessagile.blogspot.com/2005/02/agile-transformational-leadership.html)

The advantages of this approach are that as a manager you can move through a change programme in a relatively structured, reportable manner.

However, it is my belief that to truly gain the benefits of agile practices then a bottom-up (transformational) approach is required. Bottom-up is about letting people find out for themselves how effective agile approaches are. This will take alot longer than implementing a change programme, but I believe the effect of the change will be much greater.

By allowing people to find out themselves, try approaches themselves, and providing an environment where innovation is given space to breathe, advocates of agile practices will have a much more profound effect.

I have been trying to move the department towards agile practices through encouragement, education, and providing opportunities and an environment that enables innovation. It is pain-staking, frustrating and very time-consuming. But each small success is that more rewarding.

However, I have reached the point where as a manager, I feel I have a responsibility to ensure the adoption of agile development practices as a minimum. Yes.. I've gone over to the dark side...

I have created a Career Development Framework of 17 competencies that will be implemented as part of the appraisal and promotion process. These 17 competencies reflect what I believe to be key competencies needed for agile development and include the basics such as design, coding, and testing, as well as the more softer and more difficult competencies of collaboration, communication, and self-organisation.

As I was creating the framework I pulled on my own experience of working with guys like Howard van Rooijen, James Simmonds and Ian Shimmings, as well as the book by Coplien and Harrison on Organisational Patterns of Agile Software Development.

I also spent time at the last Scrum Gathering talking to Esther Derby (http://www.estherderby.com/), who has some excellent insights into supporting agile teams.

The initial reaction to the framework has been positive, although some developers do not see collaboration, communication and testing as part of a developer's role. The framework has gone through discussion,workshop review and amendment and will be implemented over the coming weeks.

There a four key areas of capability within which the 17 competencies sit:
Leadership & Management

Organisation & Planning
Mentoring & Coaching
Motivational
Technical Strategy

Technical Skills & Knowledge

Shaping & Estimating
Design & Architecting
Coding
Testing
Documenting
Technology Breadth

Personal Skills & Attributes

Effort & Attitude
Communication
Collaboration
Influence

Commercial & Business Knowledge

Financial Understanding
Business Domain Knowledge
Industry Awareness

Starting Out

2005-10-19T06:48:00.002Z

I left Conchango and started in my new role at the beginning of March this year. I'd been working as Scrum Master (www.controlchaos.com) with the likes of Howard van Rooijen (http://blogs.conchango.com/howardvanrooijen/default.aspx) and Ian Shimmings (http://blogs.conchango.com/ianshimmings/default.aspx), and fundamentally wanted to take agile practices to an organisational level.

Moving a development team of 25 from traditional methods to agile practices is an exercise in change management. But even the word change management implies a clear direction, manipulation or cohersion and "management" of the process.

I knew straight away that in order to encourage adoption of agile practices I would need to capture hearts and minds rather than direct a change programme. My previous blogs discuss transformational leadership and emotional intelligence, and I recognised that this is how I want to lead development. Even writing (I want to lead development) seems to go against the team ethic of scrum, but even within a scrum environment leaders emerge... the difference here is that it's my job!

The first step therefore was to build the Change Programme Backlog i.e. a list of all the issues that exist within the organisation.
Over a three week period I conducted 25 two-hour one-to-one meetings with all team members.

I kept the meetings fairly open but gathered information, and tried to shape conversations around the following topics:
Personal Skills & Competencies
Personal Strengths & Weaknesses
Personal Issues
Personal Career Aspirations

Department Strengths & Weaknesses
Department Issues
Suggested Solutions
Department Strategy
Expectations

This gave us the opportunity to discuss the current problems within the team, share ideas about direction and strategy, and discuss personal ambitions and goals.

I ensured the meetings were structured the same and recorded the key points of each meeting, ensuring everyone recognised that all data would be de-sensitised before use.

This exercise proved extremely valuable, and extremely tiring. The intensity of one-to-one meetings, concentration levels, and the demoralising effect of seeing the mess the team was in (having just joined!) did take the wind out of my sails.

However, by the end of the meetings I had an extremely valuable "database" of issues, problems, ideas, and strategies for the team.

Next step... The team had been without a development manager for some time and had not had an off-site meeting in years (literally). I organised an off-site day with the objective of creating a change programme to address the issues.

I went through the "database" analysing all the comments and did a cluster analysis to identify the key issues.

An important part of any change programme is to ensure it is aligned to the overal aims, objectives and processes of the corporate. The company uses a Balanced Scorecard Approach to strategy and long-term planning.

I therefore made use of the BCS elements of Financial, People, Process and Client to organise the key issues into clusters. Each of these issues were then written on index cards and grouped into their themes.

The team day then became an exercise in discussing these issues openly in break-out groups, then returning as a team to complete the prioritisation and creation of the change programme.

This may sound like a simple task, it is, but it is also painful. I felt like we'd just opened Pandora's box.

The result of the exercise in both running the personal meetings then the team day was that everyone had a clear opportunity to contribute to the strategy and change programme.

We managed to gain a consensus on direction and started moving forward.

I also created a high level simple view of the change programme that enables everyone to understand quickly and clearly both our direction and progress.

Creating an Agile Organisation

2005-10-18T06:09:00.000Z

Hello,
Long time no blog! Since February this year I have been working as Head of Development for a medium-size Marketing Company c£90m turnover. The development group consists of about 25 people with various skill-sets supporting multiple technologies.

I've already started moving the development group towards becoming an agile organisation, and this blog will be where I post my lessons learned.

I need to do this as much for my sanity as anything... Hopefully over time I'll be able to see the change that has taken place.

As I move through these issues and problems I'd welcome anyone's idea or previous experience in solving some of the problems I am facing.

Bye for now.

Emotional Intelligence: A Key Element of Scrum

2005-02-07T10:44:00.002Z

Best Wishes to you all in 2005...

Maturity and growth... Have you ever considered how we develop and which of our attributes are the most difficult to cultivate. We all grow physically without effort (providing we eat well), we all mature economically because without economic maturity we remain dependent on others and cannot achieve our goals, our intelligence quotient develops as we mature through our experiences, skillsets and knowledge.

For the more pedantic readers I will cede the point that a certain percentage of these elements are based on our genetic make-up and environmental influences, but hopefully you will understand the point I'm making.

These growth attributes are either forced on us or are natural. The one growth attribute we do not necessarily need to develop is our Emotional Intelligence.

Higgs & Dulewicz (1999), define Emotional Intelligence as "Achieving one's goals through the ability to manage one's own feelings and emotions, to be sensitive to, and influence other key people, and to balance one's motives and drives with conscientious and ethical behaviour."

Goleman (1998), further described emotional intelligence as being about:
Knowing what you are feeling and being able to handle those feelings without having them swamp you;
Being able to motivate yourself to get jobs done, be creative and perform at your peak;
Sensing what others are feeling, and handling relationships effectively

Emotional Intelligence has been proven by researchers to provide significant benefits to organisations, and high levels of emotional intelligence within the individual is a key differentiator for professional advancement and success with organisations. Organisational benefits include:

Improved leadership
More effective handling & resolution of disputes
More effective development of team working
Improved negotiations
More cost-effective decision making
Better quality problem-solving & decision-making

The Scrum team is an organisation (albeit a small one) and all Scrum teams would improve their capacity if they could recognise the benefits above. Within traditional software development projects we do not necessarily feel that we need to fully interact and gel as a team. The strategists and business analysts initiate and pass onto developers and testers, then to support and maintenance (at the helicopter level).

All these roles do not necessarily need to interact on a day-to-day basis. Within traditional projects the roles are not necessarily integrated as a team working in the same room, so the emotional intelligence capabilities are not a NECESSITY, rather they are a 'nice to have'.

Scrum suggests the use of cross-functional teams, pulling people with different roles, skills, perceptions and cultures together in a room and getting production software built every 30 days.

This has a large impact on culture, team structures, and how we interact with people. The more effective we are at communication and interaction, the more effective we will be as team members.

Emotional Intelligence as defined by Higgs & Dulewicz (1999) consists of seven specific components:
Self Awareness
Awareness of one's own feelings and the ability to recognise and manage these feelings in a way which one feels that one can control. This factor includes a degree of self-belief in one's ability to manage one's emotions and to control their impact in a work environment.

Emotional Resilience
The ability to perform consistently in a range of situations under pressure and to adapt one's behaviour appropriately. The facility to balance the needs and concerns of the individuals involved. The ability to retain focus on a course of action or need for results in the face of personal challenge or criticism.

Motivation
The drive and energy to achieve clear results and make an impact: and to balance both short and long term goals with an ability to pursue demanding goals in the face of rejection or questioning.

Interpersonal Sensitivity
The facility to be aware of, and take account of, the needs and perceptions of others when arriving at decisions and proposing solutions to problems and challenges. The ability to build from this awareness and achieve 'buy-in' to decisions and ideas for action.

Influence
the ability to persuade others to change a viewpoint based on the understanding of the position and the recognition of the need to listen to this perspective and provide a rationale for change.

Intuitiveness
The ability to arrive at clear decisions and drive their implementation when presented with incomplete or ambiguous information using both rational and 'emotional' or insightful perceptions of key issues and implications.

Conscientiousness
The ability to display clear commitment to a course of action in the face of challenge and to match 'words and deeds'; in encouraging others to support the chosen direction. The personal commitment to pursuing an ethical solution to a difficult business issue or problem.

So... Hopefully you'll have recognised that these are key competencies that would be useful for all team members. How to develop these competencies is another question. There are a number of Emotional Intelligence Questionnaires available that help us to recognise both our strengths and weaknesses and from these assessments we can work on areas of improvements and focus on changing our behaviours.

As with most things agile, the reasoning is clear and simple... the implementation is the difficulty.

Agile & Transformational Leadership

2005-02-07T10:43:00.003Z

Being a Scrum practitioner and an “evangelist” of agile practices, I cannot help but notice the parallels between Agile approaches and recent leadership theory.

Key themes that exist within Scrum when you’re living it, are the self-organisation of the team, the role of Scrum master as a facilitator or service provider, and the product owner establishing and driving the vision of the solution.

These themes provide a fundamentally different environment for teams to exist in compared to more traditionally structured projects.

Transformational leadership as defined by Bass & Avolio is concerned with three distinct leadership traits:

Charismatic/Inspirational - inspiring and aligning others by providing a common purpose allied with optimism about the ‘mission’ and its attainability
Intellectual Stimulation – encouraging individuals to challenge the status quo, to consider problems from new or unique perspectives and to be innovative and creative
Individualised Consideration – a genuine concern for individuals’ feelings, aspirations and development. They pay special attention to each individual’s needs for achievement and growth, they coach and mentor. Followers are treated differently and equitably.

Conversely Bass & Avolio describe Transactional Leadership as being concerned with:

Contingent Reward – encouraging specific performance and behaviours by making rewards contingent on delivery
Management by Exception – only intervening actively when a delegated task or function is failing to conform to expectations

The transformational elements abounded within the last project I was engaged in, and I believe it is through following the rules of Scrum that both the social and physical environments can be created that foster these traits.

Many Agile guru’s have been expounding the benefits of agile approaches.

Through the studies of Bass & Avolio (1996) they made the following conclusion:
Transformational leadership has significantly greater impact than transactional leadership on the organisation, and produces the following advantages:

Higher commitment, effort, performance and job satisfaction of followers
Lower levels of stress and burn out
Greater employee innovation, harmony & good citizenship
Improved financial performance of organisations

Coincidentally, if I had to summarise the benefits of agile approaches it wouldn't be far away from these four points.

Transformational leadership is not something you can learn overnight, nor can it be taught. But… for those wanting to get the four key benefits I’ve detailed above, you could do a lot worse than following the Scrum methodology.

Scrum helps to create the environment within which a team (with supportive leadership) can grow and attain those benefits.

How Adopting Agile Approaches Increases Business Value

2005-02-07T10:42:00.001Z

I believe that adopting a scrum approach to project delivery provides the following benefits:

Higher levels of business buy-in
Higher levels business involvement
Clearer alignment of functionality to business value
Higher levels of adoption
Better ROI

Now... for clarity, I'd like to point out that I have created business cases before and hope I will continue to do so for agile projects. I've used ROI, with discounted cashflows, NPV and IRR and even the Benefits Management process designed by Cranfield Business School. But... often the traditional delivery approaches do not help the team to maintain a focus on the business case throughout the lifecycle of a project.

Often once the requirements have been stated, the business moves into the "pay and pray" stage, where they hope that in about 6 months time they'll get what they asked for. Agile approaches have in-built processes that ensure a constant focus on business value.

and now I'll tell you how...
Scrum is focussed on delivering increments of shippable software every 30 calendar days. In my experience, the impact on the business stakeholders and user group of seeing quality software delivered every 30 days (one 30-day iteration is called a sprint) is immense... http://www.controlchaos.com/about/

Picture the scene... It's the programme kick-off meeting, the steering group, user group and entire programme team are assembled and you are presenting the project business case, objectives, structure, ways of working and plan. Then you say, "and the first delivery will be in 19 working days."
I was not short of a few sceptical faces that morning...

However, 19 days later, I was in front of the same audience showing the working software. Now we'd only built about 8 pages, but they were of production quality. The functionality enabled the user to search for and view product information and provided on-line help. This functionality was built using .NET technology integrating to an IBM AS-400 mainframe.

The impact of delivering this one "sliver" of production code was astounding. Suddenly the user group could see that we were really building this stuff straight away, and from the end of sprint 1 until live date, we had significant levels of business buy-in and involvement. Far more than I have ever experienced using traditional, waterfall methodologies.

Now scrum also uses a Product Backlog. A product backlog is a list of high level business requirements prioritised purely on a business value basis. So what's so new about that? ... Nothing.

What is new, is that because we are delivering full production code at the end of every sprint, we can measure our expected business return directly against cost far more precisely. AND... at this point assess the outstanding functionality, and either change direction, de-scope because the outstanding functionality has low business value, or continue with the project as it is.

This gives us clearer alignment of functionality to business value. Because of the incremental approach, the closure of requirements every 30 days, and the ability to more granularly relate business value to requirements, the value of the project is transparent to all stakeholders.

At the end of each sprint the sliver of functionality is made available to the business users to review and feedback on. Feedback is classified as an enhancement or bug, but the real value is that the business users are iteratively reviewing and directing the design of the solution as the project progresses. By the time the solution moves into production, potentially 8 months later, adoption levels are far higher than those of traditional project approaches.

Finally, scrum approaches give you a better return on your investment. Firstly, the teams are more productive see http://blogs.conchango.com/stevegarnett/archive/2004/11/19/297.aspx. But from a business perspective, the incremental completion of the highest priority requirements by the project team, means you will always be maximising your investment, because the team will always be building the stuff the business has prioritised as the greatest value.

In my experience, using scrum has really benefitted the business stakeholders because change is embraced, only valuable functionality is built (and this is picked by the business), and superfluous requirements are not built which reduces waste (Lean software development)

http://www.poppendieck.com/overview.htm

Breaking the Iron Triangle: Project Manager v Scrum Master

2005-02-07T10:41:00.003Z

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.

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

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.

So the resources 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.

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 tested, continuous integration and refactoring. http://www.martinfowler.com/articles/continuousIntegration.html

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.

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.

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.

An Introduction

2005-02-07T10:26:00.000Z

Hello,

My work experience includes 9 years in the Royal Navy, 6 years in IT, and an MBA thrown in for good measure.

I’ve been a Tester, Business Analyst and Project Manager, and I’ve used Prince, Summit and Enablers as delivery methodologies. I spent four and a half years with Conchango as a Senior Project Manager focussed on delivering application development projects using agile processes, particularly Scrum.

I have recently moved to CPM in Thame where I am Head of Development.

The blogs I post will focus on the management and business perspectives of Agile and Scrum, with no technical postings at all.

I'm looking forward to some interesting debates.

Steve