Agile projects – what does an agile project look like

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

agile 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?”

agile delivery

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.

agile delivery

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

scrum

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.

Fail fast

 

agile delivery faultRegularly 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.

Continuous planning

agile planning meeting

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:

agile warning

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

We offer an agile project kickstart and an agile project management service.