Though Agile says “it’s up to the scrum team to decide how they want to operate”, there are a few guidelines which need to be followed to reap maximum benefits out of Agile methodology. One such important guideline is the daily stand-up meeting. Our scrum teams, while transitioning from Waterfall tradition, started seeing those stand-up meetings as an additional overhead compared to the waterfall methodology. So they started complaining that there are too many meetings in Agile compared to Waterfall (a typical complaint you may hear during every transformation).
Stand-up meetings in the initial days of transformation
Similar to many other teams in our company, we booked a meeting room for our daily stand-up meeting where the team shared updates on what happened yesterday, plan for today and any impediments blocking their progress. Meeting time was 30 minutes (sometimes we spent even more than that). We used a projector to go through the list of open tasks in Rally and the team shared their updates by looking at open tasks in Rally dashboard. Some could argue that we should do daily stand-ups in the workplace itself instead of booking a separate meeting room and the meeting duration should be 15 minutes instead of 30 minutes. I completely agree with these guidelines, but this was just a theory for us during the initial days of transformation and hence we started with what was convenient for the team at that point of time. We do things only if the team agrees, always. Within few weeks, our scrum teams started feeling that a meeting in a separate room at a specific time every day is too much to ask and hence their participation and interest in the stand-up meeting started declining. That’s when we decided to conduct stand-ups in the workplace itself. Yes we were learning fast.
Daily stand-up in the workplace was very convenient except that we were missing the Rally dashboard which gives the broader view of a sprint like story status, open tasks, issues, blockers and so on. Team members talked about the progress and plan for the present day, but the big picture was always missing. This big picture helps team members to assess the risk, ask right questions and adjust the plan accordingly. Of course we could have used our laptops to check the overall progress during stand-ups, but laptops in the meeting (for that matter any meeting) is always a distraction and it defeats the purpose of moving away from meeting rooms. So teams had no simple means to check the progress during the meeting and hence stand-ups were not much fruitful. No complaints against anyone, we were just lacking a solution that could add more value in our daily stand-up meetings.
Scrum master comes to the rescue
Our scrum master came up with an innovative technique to tackle this problem. He started writing all stories/tasks/issues that are assigned in the current sprint in a sticky note manually (using marker pen) and pasted it on a white board. He created space for user stories and tasks (Defined/In-Progress/Completed) in the white board. The sticky note had basic information like title of the Story/Task and owner name for identification purposes. This task board worked as a physical replacement for Rally’s digital dashboard. Daily stand-up meeting happened around the physical dashboard and the team shared their updates by looking at the dashboard. They moved tasks around (sticky notes around) based on how they progress in the sprint, from Planned to In-Progress to Complete. Task board gave the overall picture which was desperately required for us.
This primarily helped to achieve two things,
- Increased team’s engagement in stand-up meetings.
- Given this overall picture (in a simplified dashboard), teams started discussing about the progress in the current sprint, asked the right questions among themselves or started re-planning according to the situation.
But preparing this physical task board and keeping it up to date manually during the sprint is a tedious process. Here are some downsides with this manual approach.
- Our scrum master manages 2 scrum teams. On an average, there will be ~16 user stories and defect stories in a sprint and he had to write ~120 tasks on the first day of sprint. Too much manual work, prone to mistakes and very hectic.
- New stories/tasks added to the sprint after the planning had to be monitored daily and need to be written on regular basis.
- Handwritten sticky note was not looking neat in the task board. Proof in the above picture.
These downsides are trivial compared to the benefit we have seen with this approach. This approach not just helped one team; both teams adopted it in the same way. We followed this approach for two sprints and noted significant improvements in both teams. We decided to continue the approach even though it was a painful work for our scrum master. He was ready to do anything for the team.
Birth of StickyPrint – Technology joins the party
We, technology lovers, took the challenge of moving away from this manual process to an automated and reliable technique that will print stories and tasks on ‘sticky notes’ at the click of a button. We wanted our scrum master to do more useful things by freeing up his time spent in writing the sticky notes.
There are several pieces involved here. I will explain the complete idea and involved technologies in detail in part-2 of this blog. In short, we wrote ~2000 line java code in 2 days to pull the data from Rally via its APIs (we love its APIs and it is very useful) and transform it to a format that we can print as shown in the below picture. Even the newly added tasks can be identified and printed incrementally each day in a ‘single click’. There are handful of other configurations introduced to handle multiple situations (more details in part-2).
- Task board with printed sticky cards (story cards, CQ/Dev task cards and so on) shows the overall progress of an iteration visually and very clearly. This board sits along with the team 24/7.
- Color coded ‘task cards’ makes the task board look beautiful and clean. In case you doubt it, compare Pic1 with Pic2.
- With lot of information accessible via Rally APIs, we can print any useful information in the sticky notes very easily (like story points, task hours and so on).
- We provided a capability to assign color code to each and every member of the team. Team members can choose the color they like. This color code makes it easy to identify all tasks assigned to a single person and it helps a lot when they share their updates.
- Printing stories and tasks in sticky notes is not common and looks tech savvy. We saw an excitement from team members and new joinees to play with printed tasks during scrum updates.
- Buzz on the floor and interest from other scrum teams to adopt this solution. Whoever adopted it started seeing significant improvements in two or three sprints and are happily using it.
This is something we tried within our team and followed by few other teams who are interested in it. This is not a standard or widely used practice within our organization. We are following it because we believe it is adding value to our teams. Others may have different opinion and it is understandable. I am not representing my company here and I am just posting this story for the benefit of everyone. I will follow-up with the technology details behind this implementation in part-2.
What do you think about this solution? Do you have any other success story? Please share your feedback in comments.