Tag Archives: scrum

When Should a Chicken Dive in with the Pigs?

Posted on by

I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.

The first of these is the product owner and the team.

As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.

On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.

Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.

I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.

If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:

  • dispel misinformation
  • surface contradictions
  • flag intractable disagreements

Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.

Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.

Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.

All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].

The Manager and Scrum

Posted on by

Jeff Sutherland posted notes from an open space hosted by Jens Ostergaard on Nov 2006. The subject was the role of manager in a Scrum.

  1. provide strategic vision, business strategy, and resources,
  2. remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
  3. ensure growth and career path of employees, and
  4. challenge teams to move beyond mediocrity

For me, introducing agile practices has been evolutionary not revolutionary – five years work, three title changes and counting. My role is to make sure the team’s accomplishments build towards something progressively more and more valuable for the company and the individual team members.

In my experience, this involves facilitating a conversation between the business and the team on at least three levels:

  • Product owner and product team,
  • Organization and employees, and
  • Leadership’s grand vision and the team’s accomplishments.
The Oxygen team and management

[the oxygen team and management]

I’ll go into this in more detail in later posts.

Product Owner Change – Stop the Line!

Posted on by

What do you do when the fundamental assumptions behind a software project change mid-stream?

My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course.

I’ve been on projects that failed simply because no one had an honest conversation about who had authority to drive changes. How many of us have built something only to have the launch postponed because a senior executive got their first look and over-ruled their under-powered product manager? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.

I’ve found Scrum does a great job of surfacing these issues and forcing the team to deal with them. Product owner is being over-ruled? Sprint integrity not being honored because interruptions and changes? Believe me, a performing scrum team will raise the alarm as quickly as this occurs and force a conversation about who is the product owner and what are the criteria for success.

One possible result? “Stop the line” interrupting the current sprint. Meet with the relevant managers and make the person setting feature priorities accountable for the backlog and the business outcome of the project. Plan a new sprint and re-commence work. The cost of mid-sprint changes is made explicit and responsibility is aligned with authority.

This can benefit everyone. First, the hidden product owner now has the regular feedback and control that reduces the urge for mid-sprint intervention. Second, the team knows who to rally around and why. Third, difficult conversations about what is driving changes and what defines success for the project happen earlier rather than later.

I’m not saying that these changes ensure success. Honestly, a project with mushy business ownership and vision is troubled. What I am saying is that with frequent inspections and a culture of honesty these seeds of failure become very clear to everyone much earlier.

I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software. They fight like hell rather than get caught in a familiar pattern of failure.