Visibility in Scrum

Last week couple of carpenters were working at my house. I was keenly observing their actions. There were five carpenters. The work was uninterrupted and everyone worked together to build wonderful interiors for the house. The head carpenter was mostly involved in understanding the requirements of the customer and help the team to plan. He along with the other carpenter did the measurement and got into action quickly. It was often iterative. Adapted to changes. They were truly agile. Rework was almost nil. It almost looked like a software project for me.

Everyone knew everything. Their flow goes something like this. One fellow cuts the plywood, two of them put it on a table and apply the gum and stick the laminates. The guy who was cutting the plywood joins these folks as soon as he was done. What I was observing was the sequence, the involvement of everyone and distribution of tasks. Carpenters jumping from one task to other without anyone asking them, help each other when there was a need. It was flawless.

As I work as a scrum master at work, I was thinking this is the perfect scrum team. The work should go as smooth as possible. And trying to learn some lessons from these folks. What we can learn from carpentry and carpenters to adapt in software development was my question in my mind. How could their work be so smooth but why do we (software engineers) struggle to complete a project? I know it is naive to compare software development to carpentry however carpentry is also a creation. It also starts with ideation and ends with implementation. I am trying to summarize some of the key observations from last week in this blog.

What needs to be done should be visible: Requirements come through backlog items to scrum teams. Quite often they would not be clear, this is the common situation in software development. Of course, we have design phase however if scrum members can imagine or can visualise what they need to do from a BLI would be of great input. This drives them and also makes it easier. We need to make our backlogs more descriptive, more informative and more intuitive.

What is next?: Carpenters used to switch the tasks so easily. Once they were done with one compartment they used to go to the next one. They switched between the tasks quickly. What I learned from this is they knew what is next. In software development, a few times we are clueless about future. It is important for the scrum team to know the next BLI or the task. This will certainly help the team to perform better.

Blockers should be highly visible: When someone is stuck other carpenter helped him in no time. So they progressed quickly. Though we have scrum meetings every day some of the blockers go unnoticed. Mostly because we don’t make them visible to everyone. It is highly important to make these blockers visible to the entire team. Make more noise about it. It helps.

Need help? ask for it. Soon the better: One evening a carpenter was struggling to fit the basket, he tried for a couple of times. He failed. He quickly called the other carpenter who was fitting the hinges and together fitted the basket in no time. Quite often we keep trying for something and spends a lot of time on it. It is always a good practice when it does not work for some tries it is better to seek help from peers. Quicker the better.

The customer availability matters: Whenever I was at home. They said it was quick for them to move ahead. When they had questions I quickly clarified them. Cleared their doubts. Asked them for suggestions. And made decision fastly. It is always important we have customers or product owners available all the time to answer team members questions or clear the confusion. How quick this is done will improve the progress of the project.

Leave a Comment