January 2012 Archives

Take the problem to team

Self-organizing team is an essential element in Scrum. ScrumMaster has the responsibility to help team become self-organizing. Agile coaches often give the suggestion that you should take the problem to team. While this is a good suggestion, it is too much simplified thus not used effectively in practice. I'd like to elaborate the key aspects and ScrumMaster's role in this approach.

  • Define the problem
It is too often for us to quickly jump into solutions, while it is much more effective to sell the problem than to sell the solution. Slow down to first define the problem. At which boundary should the problem be defined? That is the same boundary you want to enable team's self-organizing. Why does the problem matter to the team? Make the problem clearly seen by the team.

  • Who is "the team"?
When taking the Scrum context, it is the team who is self-organizing. That's the target we bring the problem to. However, it's beyond that if we think of self-organizing as a different thinking paradigm than command and control. What if the problem relates to two teams? Then "the team" is two teams combined. Therefore, it's really the group of people who should self organize to solve the problem.

The problem and the team are coupled. Let me give you one example from my recent coaching experience. The organization was fighting for getting the release out. The overall situation was challenging. The number of bugs found in system testing, which is still not part of their Scrum team's definition of Done, was high, and system testing was still in progress. Different Scrum teams were working separately to fix bugs, and system testing team was executing test cases according to the plan. I observed that those teams, Scrum teams and system testing team, did not sufficiently work together. Only few people had the idea about where the release was heading. The problem in this situation was the challenge to get release out, while all teams were the people who should work together to face this challenge. 

  • Take the problem to team
After you define the problem and find the team to work on it, the next step is to enable them to work together. It could be as easy as sending out an invitation. Or you have to first get their buy-in for the problem and the need to collaborate with others in solving the problem. It is worth the time to gradually build the shared understanding and agreement about the problem among the people, before taking it to them for solutions.

  • Facilitate collaboration
Once the whole team is ready to work on solutions, your job is to facilitate the collaboration. Try simple collaboration process as described in the book "Stand Back and Deliver", and study books such as "Collaboration Explained" and "Facilitator's Guide to Participatory Decision-Making" for skill development in this area.

  • Coaching for depth and breadth
During the whole process, ScrumMaster plays a coaching role. In the beginning, you may see the problem, define it and bring it to the team. Gradually, you coach more people in seeing and defining the problems by themselves. When they start to collaborate, the greatness of the solutions still depends on their capability in problem solving. You coach them in analyzing root causes and designing experiments to verify. There are two main focuses in the coaching - understand the problem within the broader system, and analyze the deeper causes. PDCA, systems thinking, root cause analysis techniques, even scientific method are the great sources of learning.

Self-organizing is not only a team element, but also at the organizational level. Therefore, the approach is actually not only for ScrumMasters, but also for managers in Agile organization. Yes, managers as coaches!

We don't have emergent requirements

| 1 Comment

I worked with an organization that adopted Scrum for months. Their traditional release milestone for "content frozen" still kept, and I found that they had assigned all features to teams in sprints on that milestone. I asked, "wouldn't it be change on requirements while you are doing the release?" They answered, "we don't have emergent requirements."

One important characteristic for good product backlog is being emergent. While different markets have different rate of changes, I doubt that some market is so static that there is no emergent requirement at all.

Scrum provides a framework to inspect and adapt. Even though that doing inspection and adaptation inside R&D already helps, lack of emergent requirements prevents us from reaping its full benefit. I'd like to explore this problem and possible leverages from two areas.

1. Disconnection between business and R&D

This disconnection is still one major source for the problem.

  • Product Owner from R&D

Product Owner should be business oriented, while we see that R&D oriented Product Owners are still prevalent. Their connection with real customers and markets is weak, accordingly, they lacked the insights and abilities to come up with emergent requirements to increase customer value. The synergy by having business people and R&D people work together is missing.

Product Owner role responds to the need to bring business and R&D together, since that's essential to develop great products. If Product Owner has more R&D background than business background, it may not be a show stopper, but it certainly means that this Product Owner needs to spend significant efforts towards business and customer side.

  • Contract game continues

In some organizations, they are able to get Product Owner from business side, e.g. the product managers. While they are made as Product Owner, the mindset of predictive planning and the practice of contract game continues. The most obvious sign is the very existence of milestone for "content frozen" and release commitment. Traditionally, we treat changes as evil, thus, do strict change control. Same mindset continues even though we have adopted Scrum, which provides the mechanism for us to inspect and adapt on sprint basis. Release commitment enforced from business to R&D is a sure sign of low trust and lack of collaboration. All of those hinder the business and R&D to work together and capture emergent requirements.

It is best to stop doing those milestones any more, though you may first work on the possibility of committing later and committing in parts at different time.

  • Sprint review

Most of sprint review I see is focused too much on the acceptance by the Product Owner, rather than focusing on how to get valuable feedback from customers and stakeholders so that requirements emerge.

We shall first consider whom to invite to attend the sprint review, besides Scrum team (Product Owner, Scrum Master and team). General principle is to invite the people who would be able to give valuable feedback and help make effective inspection and adaptation. It is great if we can invite real customers into sprint review, if not, consider those who are working closely with customers thus have more insights about what to build. It is unlikely that those people are in R&D, unless we are developing products for R&D people. Think of product managers, marketing and sales people, technical support, etc.

Having the right people helps new requirements emerge, and so does the collaboration process. Having the demo from R&D perspective only makes customers and business people bored. Without good facilitation on the conversation, the valuable comments may just be overlooked.

2. R&D's ability to change

I see interesting dynamic between ability to change and the need for change. They are interdependent.

need and ability to change.jpg

When you have good technical ability to change with low cost, you are more open to the need for change. That openness creates more need for change, in turn, you have more motivation to improve your technical ability. That's a virtuous cycle.

On the other hand, when you don't have good technical ability, you explicitly or implicitly discourage the need for change. Then, without strong need, you lack the motivation to improve your technical capability to change with low cost. That's a vicious cycle.

It's not rare to hear comments such as "but, our customers don't need release that often, why do we need the ability to have short releases?" Sounds similar to "but, we don't have emergent requirements, why do we need to inspect and adapt?"?

If you are able to find other motivations (e.g. quality, predictability) to improve your technical ability to change, after your ability improves, you will likely see more emergent requirements.

End note

Fred Brooks said, "The hardest part of software development is figuring out what to build." It's suspicious that we don't have emergent requirements. Try to look at the above areas, your emergent requirements may emerge:-)

About this Archive

This page is an archive of entries from January 2012 listed from newest to oldest.

November 2011 is the previous archive.

May 2012 is the next archive.

Find recent content on the main index or look in the archives to find all content.