FOSS Tools for Scrum Project Delivery

I thought I’d share a few tools our team uses for managing (control, visibility, reporting) our software development projects.

Following lean principles, we opted for the simplest possible tool set that will get the job done. These are just:

  • for stories, backlogs, sprints and bug/issue management
  • for online collaboration between team members
  • Zoom.US for face-to-face comms with the team (as my teams are often in other countries)

The role each product plays

One of the best team collaboration tools with instant messaging (team and private), the notion of ‘channels’, file sharing, search and notifications. Use this to bring all the team online ‘conversations’ and asset sharing under one searchable roof… Use it on your desktop, laptop, mobile devices or all of them! Ditch email communications for this tool right now!

Its Slack’s integration capabilities that raise it above other similar tools. Slack can integrate with a load of useful 3rd party software including Trello, Google Drive, GitHub, Zapier, Mailchimp, Zendesk, Stripe, Twitter, Zoom and many more. You can also build your own integrations or embrace their web hooks to ‘couple’ and trigger events on other systems. Slack also offers a “free to use forever” pricing tier that may be all you need. There’s some great paid services to improve Slack’s implementation of SCRUM (Scrumbot and Scrum Mate) but we’ll not go into these. They are worth checking out though.

Trello is a free (paid version available), easy to customise, online collaboration tool that organizes projects into boards. With Trello, it is easy to see what’s being worked on, who’s working on it, and at what stage something is ‘at’. Trello is therefore a great choice for Agile project management – especially SCRUM.

As with anything, start with the minimum you need and no more… It is far better to add lists to a board than create a ton up-front and then feel obliged to fill them.

For me, Trello works best when you can operate within a single board and if you don’t have too many lists… I don’t mind a little horizontal scrolling within reason… I personally like to keep the content within Trello extremely minimal and focused on specific issues or outcomes. I therefore prefer to engage in all conversations through Slack. For instance, a discussion around a bug would happen in Slack, a specific action to resolve a bug would appear in Trello (after the conversation has helped to determine what that is).

The impact of a card is shown by a simple RAG label.

Everyone has their own way of configuring Trello. Here’s mine:

I’ve have Boards for each project (e.g. Customer Smartphone Booking App). Each board is arranged to facilitate a simple implementation of the SCRUM framework. I then arrange my lists according to the priority of how I want to see them. I place the boards I should frequently review to the left, ‘productivity’ boards are placed centrally and ‘assets’ or ‘future’ aspirations (e.g. Product Backlog) are placed to the right.

Scrum Trello Board
Scrum Trello Board

I’ve named my lists and ordered them as below:

  1. Live Bugs (affecting the product that is currently in live use)
    I want to know these ASAP and for them to be the first item I see when I log in.
  2. Issues (affecting either the product in live use OR the developing product / version)
    Although potentially not as immediate as a bug in the live environment, they most likely do (or will) have an impact on operations and need attention sooner than later.
  3. Impediments / Blockers
    Any external factors or blockers impeding the progression of the Sprint are listed here.
  4. Sprint Backlog (date)
    Here we list the tasks for the current Sprint. At this point the tasks should have estimated story points assigned to them and their quality goals (both functional and non-functional) should be defined. During the Sprint the team each select tasks and drag them into the ‘In Progress’ list.
  5. In Progress
    The tasks remain in this list whilst the teams work on them. Progress is also reported here.
  6. QA
    When the developers are content that the task ‘feature’ or ‘fix’ is completed and operating as per the functional specification they move it to the QA list for a different member of the team to test it meets all quality goals.
  7. Done
    Only when the task is ‘signed off’ through QA (i.e. the feature or fix is considered operationally ready) will a task be moved to the ‘Done’ list.
  8. Sprint Retrospective
    The good the bad and the ugly goes here.
  9. Product Backlog
    Here we list the User Stories (in priority order) that we have created to capture a description of a software feature from an end-user perspective. This is continually modified and re-prioritised according to changing requirements.
  10. Assets

A place to keep essential assets (e.g. documents, images, videos etc.) relating to the project. They are kept here for easy access by the team.

I’ve found, that by using the above approach, the scope of the project and the current situation is easy to ascertain without having to reference multiple tools. Add a decent reporting tool like the excellent ‘Plus for Trello’ which has a bunch of productivity and reporting capabilities.

Framework Vs. Methodology

It’s a common question that came up again today. I thought I’d articulate it as succinctly as possible…

A methodology is a set of principles, tools and practices which can be used to guide processes to achieve a particular goal.

A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required.

See why Ken Schwaber refers to Scrum as a Framework. He explains:

The word “framework” means that much is not specified and must be devised by those using the framework. I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess. Maybe your chess game isn’t so good, but you can study great games, strategies, and tactics, and practice to get better and better. However, you are playing the game of chess, so you don’t have the option of changing the rule book. If you change the rules, it’s not chess any longer. Just learn how to play the game with excellence, which is enough of a challenge.

On the other hand Extreme Programming (XP) could be considered a methodology as it is more prescriptive in its approach and its environment. It promotes a set of rules that should be followed.