I have worked with many organisations across the whole spectrum of agile-ness… From those who are just taking baby-steps into the agile world to those where agile is at the heart of their culture.
agile (adjective)
relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
Source: Google
Agile is more than just a way of managing projects. It’s a way of thinking about work that often requires a wholesale culture change in every part of the organisation.
If your organisation is wanting to move from the traditional “waterfall” approach (where you define all the requirements up front, organise your people to build the product, then test and deliver it), then the following ten tips, gleaned from my work with many such organisations will hopefully help you avoid some of the major pitfalls.
1. Know why
Although you mainly come across the term “agile” in software development, it’s very closely linked to “lean thinking”, and its principles can be applied to most contexts where a product (of any sort) is being delivered.
Knowing why you want to move towards an agile approach is critical to the success of that transition.
| Good reasons | Bad reasons |
| I want to improve the quality of what I produce. I want to recognise change as an integral part of how I work and not deal with it separately. I want to improve my ability to meet my customers’ needs |
I want to put “agile” into my marketing collateral. I want to use the XYZ agile project tool to manage my work. I want to move with the times |
2. Understand the consequences
Making the change to an agile way of doing things will probably result in changes right across your organisation - from end-to-end:
| Sales | Your sales team will need to be able to explain up-front how working in an agile way will impact on the customer. |
| Contracting | Your contracts will need to be created to take into account the fact that the end-product cannot be defined at the beginning. |
| Delivery | Everyone involved in delivering the product (on both client and supplier-side) will need to be signed up to working in an agile manner. |
| Invoicing | Invoices will be generated based on work done, not on products delivered. |
3. Start with the right client
A client that is asking for fixed deliverables in a fixed timeframe at a fixed cost is not one that is ready for an agile approach.
But a client that recognises their need to iterate towards a solution - that they don’t yet have all the answers - is one that is ripe to work with you on your agile journey.
4. Start with the right project
The right project is one that is just the right size to fully occupy a small project team from the outset, and one that can easily be broken into smaller phases, which can gradually increase in size and complexity.
I tend to base my projects on the service design phases developed by the UK Government Digital Service:
| Discovery | A short phase, in which you start researching the needs of your service’s users, find out what you should be measuring, and explore technological or policy/culture-related constraints. |
| Alpha | A short phase in which you prototype solutions for your users’ needs. You’ll be testing with a small group of users or stakeholders, and getting early feedback about the design of the service. |
| Beta | You’re developing against the demands of a live environment, understanding how to build and scale while meeting user needs. You’ll also be releasing a version to test with a wider audience. |
| Live | The work doesn’t stop once your service is live. You’ll be iteratively improving your service, reacting to new needs and demands, and meeting targets set during its development. |
Source: GDS service manual - service design phases
5. Incubate your team
The difference between waterfall and agile can be so great that it’s often better to completely separate them out.
Create a small, dedicated, multi-disciplinary team, which can manage the whole end-to-end process in an agile way, from sales through to delivery and invoicing. They can learn the hard lessons without the distraction of business-as-usual, and be used as a test-bed for the new methodologies.
The lessons learned can be demonstrated back into the parent organisation which may then choose to adopt agile, or maybe the new team will grow to replace the old one.
6. Who owns the product?
Agile projects fail or succeed on the strength of their product ownership.
An effective product owner has three key characteristics:
| Availability | Product owners need to provide input throughout the project. Initially this will be intensive and time-consuming. As time goes on, they need to be available at the end of each iteration period to test the deliverables and provide direction for the next period. |
| Capability | Product owners need to be fully aware of why the product is being developed, and have vision for what the product will look like, based on a clear understanding of its users and purchasers. |
| Devolved decision making | Product owners need to be able to make decisions independently and quickly, but with accountability to senior management for those decisions. |
7. Focus on quality
It’s quite easy to operate in what seems to be an agile way, with sprints, backlogs etc, without it making much difference. And, in many cases, just focussing on the outward appearance can actually make things worse.
The primary difference between the short term iterative agile approach and the longer term, waterfall approach is that detailed quality standards are built into to every single small component. These quality standards are what help to achieve the goal of building what is required, bug free, first time around.
Successful agile projects maintain very clear quality definitions which are accepted by the whole team (and themselves iterated based on lessons learned)
| Definition of Ready | The Definition of Ready makes explicit the criteria that each user story (that describes something to be built) must meet before it is accepted for development in the next iteration period. More information from the Agile Alliance |
| Definition of Done | The Definition of Done makes explicit the criteria by which the team will accept a user story as having been completed. More information from the Agile Alliance |
8. Build trust gradually
With an agile project there are many unknowns at the beginning: What is the end result going to look like? How quickly will the team be able to define and create each iteration?
It’s important to build trust across the supplier/client divide - not least so that the client knows they are not being ripped off, and the supplier knows that the client is able to work effectively with them.
Build trust by starting small, and contracting (or releasing funding) for each phase separately. The GDS phases described above are a useful basis to work from - with governance decision points to release further funding between each phase.
9. Tools alone are not the solution
There are heaps of software tools (eg. Trello, Jira, Leankit) and management techniques (eg. Kanban boards, daily standups, retrospectives) that can be a great addition to your agile culture change.
But, introducing a tool on its own will not effect that culture change. That comes by continuously exploring, with your team, what agile means in your context. (See number 10 - below)
10. Iterate towards perfection
The concept of iterating towards perfection is taken from “lean thinking”. It’s a method of continuous improvement that focusses on what perfection looks like and striving to reach that state. It means that constant change is inevitable, but, by including everyone in the process, change is something that people do to themselves rather than having it done to them.
In the agile world, perfection is described by the “12 agile principles”.
These should be your focus right from the start of your transition to agile.
Posted: 30 October 2016
Tags: System implementation Project management