Chris Sterling’s Blog

In a recent Certified ScrumMaster course that I taught in Seattle we conducted an exercise where a group drew a series of pictagrams describing what a ScrumMaster should not do. One of the groups drew the following picture:

While debriefing the exercise with the entire class a comment caught my attention:

“What is that supposed to be? A ScrumMaster should not go fly fishing for cattle?”

The entire room broke into laughter. The group that drew the picture informed us that this was describing how the ScrumMaster should not use a whip to get things done. I immediately wrote down the comment and it became a theme throughout the rest of the course.

That night I actually spent about 30 minutes trying to figure out how this comment was relevant to the ScrumMaster role. Here is a short list that I have come up with so far:

• Instead of “A dead ScrumMaster is a useless ScrumMaster”, this phrase could be used to describe how trying to tackle issues fully before those involved are ready can be dangerous, may get results you are not looking for, and will not help the team improve.
• It could also be an example of fixing impediments without understanding what the actual root cause is.
• Or pushing practices onto the team without considering the highest priority impediments or when the team is not ready for the changes involved.

Some of these may be a stretch but I have found the exercise to be beneficial overall. It has allowed me to think deeper about Scrum and the role of the ScrumMaster. On top of that it was fun!

If anybody is reading this blog entry out there, I would like to hear your ideas about what the phrase “ScrumMasters should not go fly fishing for cattle” could be relevant to Scrum. Please add comments to this blog entry and I will look at and accept comments soon after they come in.

5 Comments »

One of the aspects of Agile software development methods that I believe is not well understood is the discipline it takes to implement and continue the use of good practices. Writing the test first, managing your build scripts effectively, and communicating impediments in the Daily Standup are all examples of areas which can slide as difficulty arises. This slow decay of our development processes I would like to coin as “Emergent Misbehavior”.

In the Principles behind the Agile Manifesto the last principle declared is:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As a reader of this principle I may be initially believe this to mean look at your problems and find ways to fix them. In this interpretation “problems” could be processes which are not working well. One issue with this interpretation is that it does not take into consideration what the team is doing well and could make improvements to. As teams continue to reflect only on their problem areas rather than how their entire process of software development can be improved they may slip backwards on their current capabilities and discipline. Below are some real world examples of “Emergent Misbehavior” that I have witnessed.

Daily Standup Now Every Two Days

A few teams I have worked with were having trouble understanding the value of a Daily Standup. As an Agile Coach I found it my duty to find out what in their processes and environment was causing the Daily Standup to be of little value to the team. Here are a few of the issues which emerged during reflections with the teams:

• a project manager who was questioning each team member about how they used their time yesterday
• Product Backlog contained disconnected items which were divided up to team members with specific capabilities and therefore team members were not interested in what others on the team were doing
• focus on updating the Sprint Backlog in a tool and questioning estimates of the team members
• managers attending Daily Standup and then “managing” team member based on impediments or discussion points they raised

In many instances a “smell” which was observed around Daily Standup value was team members feeling like they are being micro-managed. The teams interpreted their issues as their providing status every day was more of a distraction than valuable use of their time. Most of these teams initially dealt with these issues by conducting the Daily Standup every two days or twice a week in some instances.

Mini-Waterfalls Inside an Iteration

The incremental nature of Agile development methods are extremely difficult to master for teams used to Waterfall. As a team progresses from Sprint to Sprint and begin to “commit and deliver” on a regular basis they may be finding new processes for their software development. Some new processes that they may enact are:

• Finish each Product Backlog item including design, code, and test before moving onto the next item brought into an iteration plan
• Cross-functional team members working together on the initial functional test scripts before implementing the code and regression test suite
• Build and Integrate all system components on at least a daily basis
• Write failing unit tests before writing the code that fixing the failing test (Test-Driven Development)

As the codebase becomes more complex and potentially incorporates more integration with other platforms a team may slowly digress to what they knew before implementing an Agile development methodology. Some teams find that ambiguity in platform design means they must document the full design of all Sprint functionality before implementing any code. This reaction may be due to found rework, a failed design, or platform change issues such as database modifications or versioning. Rather than better understand where the ambiguity and problems in changeability are manifesting themselves the team is moving to a method which causes other potentially damaging effects.

Other teams may be having trouble getting a potentially shippable product increment completed each iteration. The team finds that time for QA is inadequate and therefore they institute a code complete date a few days before the end of the iteration. Problems created by this small process change may not show themselves for many iterations when the team is again having issues delivering on the iteration commitments. They may ask why QA team members are taking so long to do their testing or the team may decide to move back the code complete date an extra 1/2 or full day. This has now impacted the amount of business value the team is able to deliver each iteration since they have fewer days to code functionality.

Pressing a Team for Productivity

“Better, faster, cheaper” is a reasonable montra for many businesses. Emphasis on “faster” and “cheaper” without the “better” tends to cause decay in team productivity and product delivery. Product Owners may start out excited about their newly found control of directing product delivery but they can evolve as Mike Cohn points out in this article. This evolution may involve the question “How can we make the team more productive?”. The emergent misbehavior in this case may be falling back on traditional methods to get “productivity” in software environments. These include:

• Pressing the team to take on more work each iteration
• Incentives for working harder/longer
• Questioning team estimates on Product Backlog
• Introducing “stretch goals”

Any one of these may “work” at first and therefore act as confirmation to the Product Owner and/or managers involved in implementing the tool for gaining “productivity”. More iterations go by and quality issues start to arise which are now affecting the team’s ability to deliver even equal to iterations just before instituting the “productivity” gaining tool. The team have been meeting the expectations and incentives by giving more features but with less quality therefore accruing technical debt. Using these traditional methods for increasing a team’s productivity has backfired and now we must pay up the debt which is more costly than it would have been dealt with over each iteration.

Team Leaders Taking Over Team Responsibilites

Agile development methods tend to profess incorporating the thoughts of all team members in decisions based on informed consent. For anybody who has worked with people discussing a divisive issue and looking for common ground it is well understood how difficult consensus can be to achieve. Many issues do not cause the divisions on a team which could break down consensus building.

When an issue does arrive that is not so easily discussed and worked through then a team could jump back to traditional methods of decision making such as seniority or team leader wins. This decision making may not initially or ever cause negative effects if it happens on an infrequent basis. But if this type of decision making continues on a more regular basis it could cause some of the following issues:

• team members who will not speak up about their ideas
• task mastering by team lead or development lead
• lack of responsibility from team members for software delivery
• team members waiting for team lead or development lead to approve all work

These team problems could decrease or cap team productivity, demoralize team members, and make delivery on team commitments less predictable.

Tackling Emergent Misbehavior

In my experience, most of these and other emergent misbehaviors are the result of not fully understanding the causes of process challenges and taking the most easily available fix. The root cause of a challenge is not always easily apparent and may involve asking questions such as:

• When did this process challenge start?
• What variables could have been involved besides those that are obvious?
• Could our environment be changed to support a better result?

The answers to these questions may drive better insights into the actual root cause thus giving the team better information upon which to derive solutions from. Look out for Emergent Misbehaviors in your Agile software development process and use the retrospective not only to look for problems but also slippage in current process discipline.

1 Comment »