Agile projects can be a liberating way of working. It wont stop you from using existing skills and knowledge, but it will require your team, users and stakeholders to start working together in new ways.
Understand your users
Prioritise features for users over everyone else, including your big, scary stakeholders and ask for their feedback early and often. Really listen to your users. Even when they tell you things you don’t want to hear or disagree with.
If possible, use data from real people that are using your product and let it influence the direction of your project. Constantly put users first.
What do you want next Friday?”
In agile projects iterate often. Build something that strives to achieve the most valuable user need and show it to the users, listen to their feedback and improve it. Keep doing this until you have something so useful that they wouldn’t live without.
It might sound like over-simplifying the complexity of software development and project management, but agile development is all about what do you want by next Friday? Break your work down into small pieces that you can deliver often and provide early value to your customers, and then get feedback from this delivery to apply to your next delivery.
The process of producing incremental, production-ready software allows your team to:
- give value to their users and stakeholders regularly
- shorten feedback loops
- focus the team on the next most important thing to deliver
- direct their efforts on creating usable software
How are we doing in our agile project?
Run a retrospective at the end of each delivery cycle to review what worked or what could be improved.
A retrospective is a meeting at the end of an iteration or project, where your team get a chance to talk about what went well and badly in that iteration, and take some actions to improve matters.
A retrospective does three things, it gathers data, gets general insights and decides what to do and how to improve. This is a chance for everyone in your team to contribute to improving process/productivity. It will allow your team to continue to learn through delivery cycles and improve throughout the project.
Small, agile project teams
Small teams of between 5 to 10 people are often more productive and predictable than larger teams. Think about your team as a unit that have to all work together to deliver a result. While in a scrum in rugby they all have to work together and to go forward without twisting the scrum. In the same way the project team must all work together as close as possible to achieve a good result.
A good team includes members with all of the skills necessary to successfully produce software. A fully functioning team has 3 main roles:
- product manager – responsible for delivering return on investment, usually by creating products that users love
- delivery manager – the agile expert responsible for removing blockers (things slowing a team down), they also act as a facilitator at team meetings
- team members – self-organising and multi-disciplinary, they produce user stories, carry out the product managers vision and are responsible for estimating their output and speed
We can provide the role of the delivery manager and some crucial team members to facilitate the creation of a well functioning team.
Regularly releasing little pieces of code will:
- improve quality
- improve visibility
- reduce cost to market
Agile techniques don’t guarantee success, you can still fail. The benefit is that you fail early.
These techniques do allow you to spot problems earlier on and resolve them. You can resolve issues, and stop issues from happening, by:
- releasing working software to your users regularly, this allows you to get feedback quickly and hear or see what they think; if the product is wrong you can easily change direction and iterate
- demonstrating value to your sponsor with regular releases – if your software is rarely released you run the risk of creating a too-big-to-fail service that shouldn’t be released, but must be released anyway
- using test-driven development (writing tests before you develop the features to be tested) to highlight issues with quality early on, establish the issues, baseline metrics, and monitor throughout the project
Don’t be afraid to fail or experiment. Learn to fail, and create a culture that learns from failure.
It’s a myth that you don’t plan on agile projects. The freedom of agile projects does not come free: you have to plan. You just plan differently and continuously.
Base your agile planning on solid, historical data, not theories or opinions. Your plan must continuously demonstrate its accuracy: nobody on your agile project should take it for granted that the plan is workable.
Your teams should plan together, on at least 2 levels:
- release level – identify and prioritise the features you must have, and would like to have by the deadline
- iteration level – plan for the next features to implement, in priority order (if features are too large to be estimated or delivered within a single iteration, break them down further)
Review these plans after every sprint and adjust them based on:
- the progress of the previous sprint
- any new facts and requirements
Common situations to look out for in agile projects
If your team is new to agile, be wary of familiar situations and reactions from having to do things differently. These situations have a bad smell about them and will undermine your project and its chances of success:
- your core team isn’t full-time or is working on multiple projects – your team is the unit of delivery and you need 100%, so push back on managers and stakeholders if this is happening
- you don’t have a dedicated team area – sit your team together, preferably in their own room, with space on the walls to draw ideas and stick up cards and post-its
- there’s no continuous integration/development environment
- you have a separate quality assurance (QA) department
If you would like us to help you in setting up your agile teams or even run a team for you please contact us.