Archive for January 2015

Scrum Teams Can Be Inspired by Mother

You can also find this Article Published at Scrum Alliance website:

https://www.scrumalliance.org/community/articles/2015/january/scrum-teams-should-be-inspired-by-mother

Ever since I started working in Agile, I have been observing my wife’s way of working and how she manages our kids’ dynamic expectations. I keep seeing ways to correlate her methods to Agile. I thought of mapping my observations to some of the Agile principles — as a metaphor. I know that in other households, the various roles may be handled differently and by different people. Based on my observations, however, I’ll put it this way: Why can’t Scrum teams be inspired by a mother? Here are my thoughts.

 

Mother works steadily

In order to prepare the kids for school, she completes activities such as cooking food for them, helping them get their clothes ready, etc. She does these activities almost every day and she has limited time. If on any day she gets delayed in any of these activities, that day kids might be delayed in getting to school.

This highlights Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The Scrum teams should be inspired by mothers to deliver working software at the end of every sprint by continuously managing their work effectively and with the expected quality. For this, they need to work collaboratively, with good planning, having a proper Definition of Done in place. Their objective should be to achieve the sprint goal always by managing unpredictability through collaboration and teamwork.

Mother handles changes well and is proactive

Very often I observe my kids go to the kitchen in the morning while my wife is busy cooking, and they ask for some changes in the menu. Most of the time she will not get upset but will negotiate with them about which changes can fit within the available time frame.

This highlights Agile Principle #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Similarly, Scrum teams also have to change their mind-set and understand that the product owner has flexibility in managing the scope as per the product vision and ROI of the product. This will increase product success. Of course, they need to remember what the Scrum framework recommends about the changes, and accordingly they need to respond. So the changes have to be discussed with an intention of how they can be adapted without deviating too much from the sprint goal. This is possible through face-to-face conversation with the product owner.

Based on what needs to be prepared for the day’s lunch and snacks for the kids, most of the time I observe my wife preparing things ahead — cutting the vegetables, checking what the kids like/need for lunch, making snacks, purchasing items the day before they are needed. This will make her job easier the next day and the work can be done more smoothly.

So this highlights Agile Principle #4: Business people and developers must work together daily throughout the project.
and
Principle #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Scrum teams should care and give importance to product backlog grooming so that their sprints will not have turbulence. They also need to work closely with their product owner and give importance to face-to-face conversation instead of emails.

Mother plans and executes effectively

If you observe the way Mother plans and executes her work, it’s amazing. She knows the priorities well, she knows which task takes more time and which tasks take less time, and she allots time to them accordingly. She also identifies the tools that help her complete work with her expected quality and within the given time. Even though she does similar work every day, she does not take it lightly and aims for continuous improvement.

She cares about the work that is required to meet the timeboxed duration by pushing the “unwanted” work back. This can be done by proper prioritization and assessing the need of the work.

This highlights Agile Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
and
Principle #10: Simplicity — the art of maximizing the amount of work not done — is essential.

Scrum teams also should know which is the highest-value story and which is of lowest value, and accordingly they need to deliver them to make sure working software is delivered at the end of the sprint. They also have to give equal importance to engineering practices such as continuous integration and test-driven development, collective code ownership, refactoring, etc. They always have to strive to deliver rapid value in terms of working software with technical excellence.

Scrum teams also have to understand what is required and what is not, and accordingly they need to push back the things that are not required. They need to know the requirements that deliver the majority of the revenue from the product (80-20 rule, or Pareto principle). This needs constant communication and collaboration among the product owner, team, and the stakeholders.

Mother is innovative

Many times, I observe that my wife creates new recipes by following sources such as YouTube, Google, etc. This makes the kids (stakeholders) happy. Also, she is a continuous learner, even though she has already gathered great experience and expertise in her area of work.

Agile principle #9: Continuous attention to technical excellence and good design enhances agility.
and
Agile principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Scrum teams should spare some bandwidth to enhance their cross-functional skills and sharpen their technical caliber on an ongoing basis. It is good to come up with a team-level learning plan by identifying current primary skills and secondary skills the team wants to achieve and planning to mentor each other. The key thing is to make it timeboxed and set a target date, with periodic tracking of progress.

The team can get support from the ScrumMaster to receive external training in case no team member has the required skill to train the others.

Mother takes regular feedback

Even though she does similar kinds of work every day, Mother asks the kids about the food and whether they liked it or not. This helps her improve wherever required. This highlights the Agile principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So it is essential for Scrum teams to have regular retrospective meetings to check where they are good and what needs to be improved so that they can become high-performance teams over a period of time. It should not be just like any other meeting; they have to gather the sprint data, generate insights from the data, and then come up with action items and prioritize those actions for implementation in upcoming sprints.

One thing the ScrumMaster has to follow here is the trends of the retrospective outcomes. Things that are working fine should continue to work fine, and things that are not working well should change so they can start working fine. This will help the Scrum teams become high-performing teams. Maintaining the details of the retrospectives, watching the trend analysis, coming up with suitable solutions, and mentoring the teams in those areas will be the responsibility of the ScrumMaster.

Mother does not get paid

Whatever great work Mother does, she does not get directly paid for it. However, she takes care of the family regardless.

I know this is hard to digest, but I feel that Scrum teams have to focus on their delivery without worrying much about salary hikes, promotions, etc., so that their work will show what they are capable of as a team. Becoming high-performance teams will bring them success in their work lives. 

Hold the ball longer…stronger… together

This is an activity to describe How to manage your code effectively as a TEAM

Timing: This game may take from 20 to 30 minutes

Materials: A multicolor light weight ball, 6 strong sticks or plastic pipes with 21 inches each stick/pipe length, space to walk around while playing

Instructions:

  1. Game brief:

Invite at least 6 volunteers to play this game. We are going to experience various scenarios in this game to demonstrate the need and importance of “collective code ownership” concept.

The volunteers have to come close and hand over them the sticks/pipes. Tell them the ball is their code base. In each scenario they have to make sure to play the scenario without dropping the ball. If balls drops then 1 penalty point. If they complete each scenario without dropping the ball then they get a bonus point. At the end of the game their total score will confirm how they could manage their code.

We need to keep a fixed time period to complete all scenarios mentioned below). This is to make the activity timeboxed.

Team can move to next scenario only after the previous scenario is done successfully without dropping the ball.

Note: If you are playing this game with more than one team then keep a separate scoring board to track the time and final score of each team.

  1. Scenario – 1: Your code increases over a period of time

2.1.         All the participants need to sit on their knees and hold the sticks/pipes with their one hand (left or right does not matter) and try to keep the ball balanced on those sticks. They should not use their other hand at all.

2.2.         Participants have to stand on their feet without dropping the ball.

  1. Scenario – 2: Your code is not static, it changes all the time

3.1.         Ask the participants to walk from their current place to a distance of 5 feet

3.2.         Ask them to make a rotation of their places

Image for 3.2 section

  1. Scenario – 3: One team member develops more stories (more code)

4.1.         One person pushes the ball hard

4.2.         Rest of the members to balance this scenario

  1. Scenario – 4: Change the roles

5.1.         Ask the members to switch their positions (not immediate left or right)

5.2.         They need to keep the ball balanced on the sticks/pipes while they rotate their positions

Image for 5.2 section

  1. Scenario – 5: A very important story came up!

6.1.         Tell the team that the Product Owner has come up with a very important story

6.2.         The story is to rotate the ball in such a way that the color that is on the bottom side should come to the top

6.3.         They should not use the free hands and they need to just rotate the ball using their sticks/pipes

 Image for 6.3 section

  1. Scenario – 6: Couple of members on vacation

7.1.         Ask two team members to drop their sticks and leave the game abruptly

7.2.         Remaining members should be able to manage the ball with remaining sticks/pipes

Learning Points:

The team understands the importance of following concepts:

  • Code should be developed with proper supporting tests
  • Code should be stable even the team is adding new code
  • All the team should have a fair idea on the code base and it should be a collective responsibility and not any more individual owning. Even there is a specialist developers writes some critical parts, there must be a knowledge transfer planned to get everyone up to speed
  • collective code ownership, making the code stable always, quality of the code should be as per expectations
  • Team should be cross functional so that they can manage the code effectively
  • Manage the technical debt time to time and do not go for work-around solutions or short term fixes