We have used a host of tools in an effort to continually improve the process of delivering value to our clients. One of the most valuable tools has been Trello.
We use [[http://trello.com|Trello]] to simulate a Kanban board. We do not strictly follow a Kanban process as we do not employ WIP limits and we are not strict about other disciplines like removing blockers as top priority.
However, what seems to be working very well for us and our clients is a process enabled by Trello to provide an extreme amount of transparency and client control. This fosters an engaging process that is iterative and collaborative that feels very natural.
For a new project or engagement, we start by creating a new Trello board with the following lists (from left to right):
- Backlog
- Next
- In Progress
- Ready for Demo
- Deployed to Demo
- Accepted This Week
- Accepted Last Week
{{ 17 }}
We will work with the client to queue up the most important items or stories in Backlog during our initial calls/emails. In this process, we are looking for the most important things rather than trying to generate a comprehensive list. The client can add to this list at any time and in parallel to development once we get started.
When the client is ready to start, they'll pull their top 5–7 cards over into Next to indicate what items they want worked on before anything else.
When a developer begins work, they pull a card into In Progress and assign themselves to the card. This communicates who is working on what. The developer may ask the client questions to help refine the card or clear up any confusion. By keeping all dialogue on the card it is available for anyone on the team to see and keep up with. One key benefit to this is it alleviates the need for a lot of meetings.
{{ 18 }}
When the developer is done with the work and is ready to have it deployed to a demo instance, they'll pull it into Ready for Demo, and go back to pull another card from Next until they are done working on the project for the day.
The team lead for the project will deploy the cards that are in Ready for Demo and once it's live on the Demo instance, they'll move all the cards in that list to the list entitled Deployed to Demo.
As cards are added to Deployed to Demo they are ready for the client to go to the demo instance (we have previously set this up on [[https://gondor.io/|Gondor]]) and test out the new feature or bug fix.
At this point they have two choices to make, they can accept the work and pull the card into Accepted This Week, or they can block the card by adding a red label to the card and leaving a comment as to why the card is unacceptable and how it could be resolved.
If it gets blocked, the card stays where it is and someone on the development team will address the issue and, once the fix has been deployed, they will unblock the card and leave a note on the card for the client about how they resolved it.
{{ 19 }}
At the beginning of each new week, the team lead will archive all cards in Accepted Last Week, and then move all cards in Accepted This Week to Accepted Last Week.
{{ 20 }}
With this process, we have found we are delivering continuously rather than at the end of a weekly or bi-weekly sprint. A downside we found not having a 1-2 week iteration in a traditional Scrum sense was that it didn't give the client a good sense of what was accomplished week to week as it quickly all blurred together. Therefore, as a convenience to the client as well as providing some motivation to the development team (nothing makes you feel as productive as seeing a long list of a cards that you did queue up in that Accepted list), we use these two Accepted lists to collect cards that are finished.
This has reduced communication overhead on our projects by a tremendous amount. No longer do we have to have weekly calls with clients to read through lists of what was done. They already know the real time status of every component of the project. Now calls with clients are discussion about features, design, product development and other productive topics.
In addition to reducing communication overhead, the quality of communication has been tremendous. There is little to no chance of confusion about working on the wrong thing since the client controls what's queued up to work on Next. Also, the feature or bug fix is not done until the client says so.