Scrum


Scrum of Scrums are about the conversation!

The purpose and composition of a Scrum of Scrums (SoS) have been discussed in detail in earlier blog entries.As a means to scale, SoS has been leveraged as a structure for teams to coordinate and plan activities between each other.  The SoS is a platform for conversations such as negotiating access to a capacity from a team with specific skills or reminding everyone that you are refreshing the test environment in a few hours. The pattern of getting people together to coordinate with a structured approach in a time box is a powerful tool. That is why the base pattern has been tweaked and leveraged for many other purposes, some of which stray away from a few basics prerequisites:

  1. You have to have more than one team. It is difficult to coordinate if no one else is involved.   Just because you are doing Agile or Scrum does not mean that you need to leverage a Scrum of Scrums. Don’t think this has not happened.
  2. Participant teams need to interact with application or capability level.  Holding a Scrum of Scrums that have no functional or capability connection will devolve into a status meeting or worse.
  3. Participants need to have a valid reason to plan and coordinate together.  Even if participants share an application, project, technology or capability, they still need a reason to plan, coordinate and negotiate together or the SoS will be a status meeting.
  4. Participants must trust each other.  Without trust no real communication is possible.

A Scrum of Scrums is not a status meeting — the world does not need more status meetings. (more…)

Advertisements

Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

Logistics Are Part of All Meetings

Planning meetings are not terribly glamorous.  They are, however, an important first step in effectively delivering value for any sprint or increment.  I have developed a simple checklist for preparing for a planning meeting (we will explore a simple process in the near future).  Agile planning events couple the discipline of saying what will be done and then delivering on that promise with the need to embrace the dynamic nature of development and maintenance. (more…)

Map of the Fredrick Half-Marathon

A product roadmap is a powerful tool.  Roadmaps help link products and services to the strategy, objectives and key results.  Roadmaps are directional, answer the question of where we are going and why.  Roadmaps are powerful – unless they are messed up!  There are four common mistakes that will reduce the value of a roadmap. (more…)

A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.   (more…)

Control!

The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are: (more…)

Ill-defined Roles Block The Elevator!

As I considered the intricacies and difficulties of the Product Owner role, I was concerned that my perceptions might not be as inclusive as possible. In order to expand my understanding of the role and to test my experiences, I asked over fifty product owners why they thought the role was hard.  The majority responded and I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  Part of the difficulty is a reflection of information asymmetries, other difficulties arise because of how we use words or who is assigned to be product owners.  The next two of most common reasons the product owner role is difficult are: (more…)

Next Page »