How to use agile in your project
Agile environments promote a value-driven, collaborative approach to software design and development. They lower the cost of change by letting scope evolve with relatively low investment.
Agile approaches excel when you have skilled, adaptable developers who can think independently. It provides flexibility, which is essential when you aren’t clear what the final product should look like, when you need a product capable of adapting to changing industry circumstances, or when you know the scope of a project may change.
But agile approaches don’t suit every situation. Projects that must be completed by a particular deadline, or where feedback cycles are impossible, are unlikely to obtain major benefit from an iterative agile approach.
Securing business buy-in
To introduce an agile environment within any business, changes are needed. Possibly the most confronting is the need to commit to a variable cost. Because discovery occurs incrementally, there’s no way to accurately estimate the cost of a solution upfront. The upside to this is that the end solution will be better evolved to reflect customer needs.
It pays to take a holistic view of waste and ownership, as there may be short-term waste while lessons are learnt. On the flipside, this issue is offset by the lower long-term cost of ownership that comes with an evolved solution that customers love.
The way in which projects executed in an agile environment are reported can also be challenging. Although the collaborative nature of agile developments ensures increased transparency, reporting is typically imprecise, with delivery dates estimated based on the feature backlog and current development velocity. Milestones often move. In fact, this is indicative of one of agile’s primary strengths: projects adapt as requirements and priorities change.
Understanding and accepting these changes is necessary for any organisation considering an agile approach, particularly as the support of the business is vital to implementation. Changes must be mandated across the organisation and collaboration is required at all levels.
Agile projects or development?
Once you’ve decided to run an agile environment, you need to choose between adopting either the more limited set of agile development practices or full agile projects.
While agile development is often the focus, it’s only part of running an agile project. It’s a partial form of adoption, common in organisations that don’t fully understand or aren’t ready to buy into the benefits that running agile will bring.
The agile delivery team is run by a project manager, scrum master or product owner. Beneath this is a development team or teams. The developers use agile methods, that is, they have their daily stand-ups, they work in sprints, and review the process in retrospectives. Only the development team or teams ‘run agile’. The main drawback with this type of structure is that developers rely on the project manager, scrum master, or product owner to define the project’s scope and direction.
By comparison, agile projects involve a product owner who represents the business plus the delivery team. Everyone works together and is involved in every stage of the project, including setting its scope. This facilitates self-governance and collaboration, allows change to be incorporated efficiently, and ensures constant validation of business value.
The right people
Getting the right mix of people and skills is imperative to the success of implementing an agile approach.
Ideally, the product owner fills two roles: representing business requirements (such as compliance and legal) and representing technical requirements. If you don’t have a suitable single product owner, share these responsibilities among co-owners.
Try to select problem-solvers and contributors as delivery team members. You want people who can offer potential solutions to issues that arise along the way, people who can learn incrementally and ultimately reduce wastage.
It’s best for the business analyst to be technically capable. For continuity, it’s useful to retain the same design resource that you use during initial discovery stages throughout the project.
The team must be able to effectively communicate and filter out issues that should be addressed in their own stream. This calls for a balance between transparency and dealing with issues that no-one else needs to worry about.
If the team is distributed across locations, consider ways to facilitate collaboration such as in-person meetings during project kick-off or initial sprints, and video or teleconferencing after that.
Getting started
Beginning with a small two or three sprint project gives your new agile team a chance to practice. Ideally, the project should be an internal solution of value to the business. Start with the development team running agile to get them used to the concept of sprints and delivering small pieces of work at a time. Once they’re comfortable, extend to projects with self-governing teams.
Remember to keep the business informed and use each project to educate stakeholders about expectations. It’s important to ensure everyone understands that not all requirements will be known at the beginning of the project and, therefore, there will be changes. Also, there is always more to do than time and money will allow.
At the end of your project, remember the retrospective. Gather team members and ask them to note down what they thought worked, what didn’t, and what they found confusing throughout the project. Above all, learn what you can improve and set actions for things that need addressing before you embark on your next project.
