Agility
is not a new phenomenon. It has evolved with time, the sincere efforts of the
Agile community, and its great proponents. Scrum, an Agile framework, achieved
popularity with its high number of success results. Development teams started
transforming as Scrum teams and a new servant-leader "ScrumMaster"
emerged. For the past few years, Scrum has attained wide recognition, and even
those organizations that initially overlooked its benefits are now transforming
to adopt it. Due to the high success rate of Scrum-led projects and the
increased requirements for ScrumMasters and Scrum product owners, many
professionals have embraced these roles cheerfully. However, in the enthusiasm
a few (wrongly) modified processes are being practiced in many organizations,
which sometimes results in failure and stepping into non-Agile methods and
myths. I appreciate the efforts people are making to adopt agility while
molding some practices to better suit their organizations, but one should take
a few preventive measures and inspect such modifications before implementation.
This is important not only for new teams but also for matured teams that
experiment with such practices and sometimes face adverse results. By saying
this, I do not intend to say that we should not experiment! Scrum itself
provides room for some calculated modifications. However, before applying such
modifications, pros and cons must be considered. I have coached many teams and
faced challenges of this type. I have had to implement good practices in some existing
teams. The most common behaviors I observed that needed to be changed were as
follows: Modifying the names of the ceremonies Not timeboxing ceremonies
Treating programmers and testers differently Implementing Scrum without
inspecting and understanding the current state of the existing project
Modifying the names of ceremonies I found strange names given to a few
ceremonies and observed ill effects. For example:
Daily Scrum -- Daily stand-up, daily Scrum meeting, daily status meeting (the worst name)
Sprint review -- Sprint demo meeting
There are two main disadvantages of such renaming. First, not having a common name across the globe leads to misunderstandings.
"What's in a name? That which we call a rose by any other name would smell as sweet." Great lines by William Shakespeare (Romeo and Juliet)! But in software development, such renaming causes confusion. For example, we cannot call the sprint review a sprint demo or some other name. Even if renaming works within the organization, the rest of the world will be baffled. The second disadvantage is that most names have some significance; using other names ruins that. Calling the Daily Scrum a daily status meeting is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance. In our teams, we made a rule to follow the proper name of the ceremonies to keep everyone synchronized. The same way the sprint review was named a sprint demo; the sole purpose of this ceremony was to demonstrate completed stories/tasks. The teammate who had coded the particular piece of function was responsible for demonstrating it to stakeholders, and other developers were not highly attentive during that demo. It was important to realize that the demo was not only for stakeholders; it was for the whole team. We guided the team to understand the significance of the sprint review and provide the transparent current status to stakeholders. It took time, but providing various examples rejuvenated the team. There are a few other names that need a common tag. For example, "acceptance criteria" and "condition of satisfaction" are the same. Scrum experts are making efforts at this. For example, "product backlog grooming" is now often called "product backlog refinement." Many more are yet to come. Not timeboxing ceremonies This can be challenging -- and linked to modified names. In working with one team, I found that the Daily Scrum was being called a status meeting, and it was not occurring daily. Due to different time zones among the distributed teams, it was held on alternate days and for longer durations. The team was providing the status of the past two days' activities. All teammates sat and provided their status, one by one. The activity descriptions were monotonous and the energy was very low. Further, I observed that the development team found this meeting time-consuming and of no use. We first timeboxed it and limited the questions/answers. (Two additional questions had crept in: "What did we do the day before yesterday?" and "What will we do the day after tomorrow?") We succeeded in convincing everyone that the Daily Scrum should indeed be held daily and that the three original questions would be discussed. The another problem, of answering these three questions while facing and essentially speaking only to the ScrumMaster in a status report, was solved by guiding the team toward the essence of this meeting and positioning the ScrumMaster behind the team, which stood in a half circle. To revitalize the team's energy and sense of cohesion, we introduced new Scrum games. One such game that I introduced is one that calls on everyone's imagination. Please refer my post 'A game of Imagination'.
Treating programmers and testers differently Treating programmers and testers differently is a very dangerous practice and definitely leads to failure. In such situations, programmers and testers do not focus on the target and instead try to find each others' mistakes. In our development team, we called everyone a developer and focused on achieving the goal on time. This helped us avoid unwanted slippage on tasks. For team bonding, I experimented with many varieties of the above-mentioned game and succeeded in achieving excellent team bonding. Implementing Scrum without inspecting and understanding the current state of the existing project This problem, which I observed strongly in a particular team, is certainly common among many new Scrum proponents. Scrum can be used with all projects but is not highly useful in certain situations. For one of the teams that had recently delivered a product with many critical defects, implementing Scrum was not a good idea. The requirement was to immediately provide needed solutions and keep to the task in hand (limit the Work In Progress). We finally got that situation under control by providing the immediate defect resolutions, and then we started following Kanban for support activities.
Daily Scrum -- Daily stand-up, daily Scrum meeting, daily status meeting (the worst name)
Sprint review -- Sprint demo meeting
There are two main disadvantages of such renaming. First, not having a common name across the globe leads to misunderstandings.
"What's in a name? That which we call a rose by any other name would smell as sweet." Great lines by William Shakespeare (Romeo and Juliet)! But in software development, such renaming causes confusion. For example, we cannot call the sprint review a sprint demo or some other name. Even if renaming works within the organization, the rest of the world will be baffled. The second disadvantage is that most names have some significance; using other names ruins that. Calling the Daily Scrum a daily status meeting is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance. In our teams, we made a rule to follow the proper name of the ceremonies to keep everyone synchronized. The same way the sprint review was named a sprint demo; the sole purpose of this ceremony was to demonstrate completed stories/tasks. The teammate who had coded the particular piece of function was responsible for demonstrating it to stakeholders, and other developers were not highly attentive during that demo. It was important to realize that the demo was not only for stakeholders; it was for the whole team. We guided the team to understand the significance of the sprint review and provide the transparent current status to stakeholders. It took time, but providing various examples rejuvenated the team. There are a few other names that need a common tag. For example, "acceptance criteria" and "condition of satisfaction" are the same. Scrum experts are making efforts at this. For example, "product backlog grooming" is now often called "product backlog refinement." Many more are yet to come. Not timeboxing ceremonies This can be challenging -- and linked to modified names. In working with one team, I found that the Daily Scrum was being called a status meeting, and it was not occurring daily. Due to different time zones among the distributed teams, it was held on alternate days and for longer durations. The team was providing the status of the past two days' activities. All teammates sat and provided their status, one by one. The activity descriptions were monotonous and the energy was very low. Further, I observed that the development team found this meeting time-consuming and of no use. We first timeboxed it and limited the questions/answers. (Two additional questions had crept in: "What did we do the day before yesterday?" and "What will we do the day after tomorrow?") We succeeded in convincing everyone that the Daily Scrum should indeed be held daily and that the three original questions would be discussed. The another problem, of answering these three questions while facing and essentially speaking only to the ScrumMaster in a status report, was solved by guiding the team toward the essence of this meeting and positioning the ScrumMaster behind the team, which stood in a half circle. To revitalize the team's energy and sense of cohesion, we introduced new Scrum games. One such game that I introduced is one that calls on everyone's imagination. Please refer my post 'A game of Imagination'.
Treating programmers and testers differently Treating programmers and testers differently is a very dangerous practice and definitely leads to failure. In such situations, programmers and testers do not focus on the target and instead try to find each others' mistakes. In our development team, we called everyone a developer and focused on achieving the goal on time. This helped us avoid unwanted slippage on tasks. For team bonding, I experimented with many varieties of the above-mentioned game and succeeded in achieving excellent team bonding. Implementing Scrum without inspecting and understanding the current state of the existing project This problem, which I observed strongly in a particular team, is certainly common among many new Scrum proponents. Scrum can be used with all projects but is not highly useful in certain situations. For one of the teams that had recently delivered a product with many critical defects, implementing Scrum was not a good idea. The requirement was to immediately provide needed solutions and keep to the task in hand (limit the Work In Progress). We finally got that situation under control by providing the immediate defect resolutions, and then we started following Kanban for support activities.
Finally .
. .
Now each
of our teams follows the Boy Scout rule (always leave the campground cleaner
than you found it). Whenever we find a process derailing, we gather and discuss
it and get it back in place. If you too have faced any such derailed processes,
please share your experience, along with the resolution you and your team took.
No comments:
Post a Comment