I’m currently the Scrum Master / developer on a large software project (8 developers + 1 product owner / project manager). It’s a fixed price, fixed scope, fixed resources project - in other words, not the best settings for Scrum. But yet, following the Scrum practices have been vital even for this project. I give you a short list of this experience and what it feels like.

  1. Keeping ScrumWorks updated: or rather, ensuring that team members keeps Scrumworks updated. I follow through tasks and their estimates to check that no tasks are left unnoticed or not estimated.
  2. Hosting daily scrum meetings: all members participate, but there’s a thin line between the team hardly participating to having the team discuss every thing in detail. The middle ground is making sure everyone get their share, make them name their most important issues and get a clear commitment on the future work
  3. Ensure that the product owner keeps the backlog prioritized
  4. Check that tasks and backlog items are described well enough for others to understand their purpose
  5. Follow up on impediments: All developers are forced to log their impediments. These impediments can usually be forwarded to someone to fix them. Keeping this communication flowing is part of the game.
  6. Report progress to all stakeholders, as well as to the team to remind them about deadlines and committed work.

The job of a Scrum master, especially in this project, is about keeping things visible. I’m not the one making the calls around the project, that’s left for the project manager or stakeholders to do. I just make sure everybody know what’s going on, backlog items are approachable and the team keep their focus. In other words, it’s feels like keeping the table clean enough to let everyone involved in the project make the best decisions possible. It surely lives up to the saying “the art of the possible”.

One note about teamwork and documentation: Many people believe agile speaks of less or no documentation. “Code is documentation enough” is the common saying. However, this is misinterpreted. Documentation is simply communication. Limiting documentation is about reducing the written documentation down to a minimum, but still being able to communicate what’s necessary for others to understand the works. One mistake many developers do in such a large project is telling themselves “I know what I’m supposed to do, I don’t need to write it down up front!”. This is unfortunate. On a team, everybody must be able to understand the works of anyone. Every developer needs to describe what to do and how they’re doing it in order for others to pick up on it. Hence, documentation is important but only for the right reason: communication. The Scrum master must make sure that everybody understands this and takes action.