Tag: Agile

Who is Your Product Owner? Product Development vs. Systems Integration Environments

Understanding the difference between product development and system integration projects helps better define the Product Owner role and the Product Management structure necessary for project success.

Agile-Scrum clearly defines the Product Owner (PO) as a key member of a Scrum team. The PO represents the Voice of the Customer. The PO is responsible for fusing the various needs, wants, and perspectives of project stakeholders into one complete, coherent, and cohesive vision. The development team depends on the direction and guidance provided by the PO to understand what business capabilities to develop and how those capabilities must work to provide value to the customer. Thus, PO plays the most important role in the creation of User Stories and their prioritization within the Product Backlog.

However, more often than not, when I ask Agile-Scrum development teams, “Who is your PO?”, they do not know for certain. This is especially true in systems integration projects. Ask different developers within the project who the PO is and you will likely get different answers. Some will say the Enterprise Architect is the PO. Others will name the lead Systems Engineer, or the Chief Engineer, or the Project/Program Manager, or the owner of the company, etc. Often the answer is, “We don’t have one.”

Agile-Scrum was originally conceived within a commercial product development paradigm. The terminology of Agile-Scrum is indicative of this product development bias with terms like Product Owner and Product Backlog.

In a product development project, the company has significantly more control over the Product Vision and how that vision is actualized than in a systems integration effort. The company decides what capabilities and features to develop, how they will be integrated into the product, when the product will be released, and how much will be spent developing the product. In well-run product companies, all of these decisions are informed by market and user data. However, these decisions are ultimately made by the company.

System integration efforts, by contrast, tend to be customer-driven. Customers decide which capabilities they will pay for, how much they will spend, and when the implementation of those capabilities is due. Thus, system integration efforts are, by nature, service engagements, not product development efforts. Also, software solutions integrated into enterprise environments are typically much more technically and organizationally constrained than than green-field product development efforts.

The control product companies have over their products makes it significantly easier to identify and empower POs than in system integration engagements. Product company POs have fewer stakeholders to answer to and, typically, fewer external dependencies to manage. They also have the advantage of starting with a company-defined Product Vision.  In systems integration, Agile-Scrum teams work with a customer PO to define a Product Vision for a solution the PO does not own and that must address many disparate, and often conflicting, needs and wants of internal and external organizational stakeholders.

It quickly becomes clear that the role of PO in a large-scale system integration effort cannot be filled by one person alone. Due to the many stakeholders that need to be included, the Voice of the Customer can easily become a cacophony of voices without some structured way of harmonizing them into a chorus. Adding to this complexity is the fact that large-scale system integration efforts typically involve multiple teams from different companies. Each of these teams requires a PO, assuming they are all executing as Agile-Scrum teams.

Large system integration projects demand a level of planning and coordination that pure “team-level“ Agile cannot handle. I am not proposing engaging in Waterfall-style, Big Planning Upfront. Even in complex system integration engagements, the Product Vision can be defined over time in an iterative approach, as prescribed by Agile.

Large-scale systems integration requires a product management approach that informs and coordinates team-level PO decisions and prioritizations across program and portfolio levels. Each team works with a PO who manages the stakeholder community that depends on the team’s feature set. Each PO also coordinates with other POs through a product management structure. This product management structure is a core feature of the Scaled Agile Framework (SAFe).

Since scope in Agile “floats”, having an empowered and engaged PO is vital to ensuring teams deliver real value within agreed upon budget and time constraints.  The definition and realization of the solution’s TO-BE state depends on POs.  For Federal software system development projects in particular, the PO role should be played by a government employee who is empowered to make decisions, capable of leading a stakeholder community, and tasked as a full time PO to the teams he/she supports.  Anything less introduces risk to Agile projects and breaks the alignment between development teams and the sponsoring organization.



Five Things You Must Understand about Agile Team Velocity

Agile team velocity is an often misunderstood concept that is prone to misapplication. This article sets the record straight.

Agile software development is the way we build software now. The general consensus on management of software development projects is that predictive planning approaches (e.g., Waterfall) are ill suited for the job. However, almost two decades after the release of the Agile Manifesto and the rise of Scrum as the most popular Agile framework, team velocity is still a point of confusion.

Some organizations are under the mistaken idea that they can “buy” Agile-Scrum software development services à la carte based on team velocities. Under this contracting model, service vendors offer prepackaged teams rated at some velocity. Based on that velocity, the organization could then pay for a certain amount of that team’s time to complete predefined tasks. This arrangement treats Scrum teams as plug-and-play units of development capability. This mentality is evidence of a fundamental misunderstanding of Agile and Scrum, of what teams require to be effective, and of the concept of team velocity itself.

What is Team Velocity?

The concept of team velocity is not officially part of the Scrum framework. It is a best practice for estimating Development Team throughput. More specifically, it is the rate at which the Development Team, in collaboration with the other members of the Scrum Team (i.e., the Product Owner and ScrumMaster), delivers discrete items of functionality that are finished, tested, and accepted during an iteration/Sprint. The Scrum Team documents requirements for those items as User Stories and tracks and orders User Stories in the Product Backlog.

Rather than simply counting the number of completed stories at the end of a Sprint, the Scrum Team determines its velocity by adding together story points from every story completed during the Sprint. Story points form the basis for determining team velocity. Calculating team velocity allows Development Teams to estimate the amount of capability (value) they can deliver at a sustainable pace during a Sprint.

Σ Story Points of Completed User Stories During a Sprint = Velocity

It is important to view team velocity results as data points along a trend, rather than as definitive stand-alone measures.  In other words, to understand how much value a Development Team is capable of delivering, we need to look at velocity results from the previous two or three Sprints to get a sense of whether the latest result is part of a trend or an anomaly.  Such anomalies often indicate issues requiring attention.

Like the concept of team velocity, story points are not part of the Scrum framework. The Development Team assigns story points to Product Backlog items (i.e., Epics and User Stories). Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:

  • User Story complexity, risk, and uncertainty
  • Level of effort required to complete the User Story

This combination is often referred to as the “bigness” or “size” of a User Story. The Development Team estimates User Story points by “sizing” User Stories relative to each other. More complex User Stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Story point estimation is not restricted to specific timeframes or meetings. It is part of a continual refinement of Product Backlog items by the Scrum Team that includes:

  • Adding, updating, or deleting items
  • Decomposing items into smaller items
  • Adding details and estimating story points
  • Ordering/prioritizing items

Five Key Team Velocity Concepts:

1.  Only the Development Team estimates story points with input from the Product Owner and other relevant stakeholders. They are not determined by a chief engineer or some other senior authority as an estimation exercise prior to the establishment of Development Teams and the appointment of Product Owners.

2.  Team velocity is specific to the team.  Velocity cannot be used as a point of comparison between teams.  Team X is not necessarily faster or able to attain a higher throughput than Team Y because they earned a higher number of story points during a Sprint.  The story points upon which team velocity is based are specific to the relative sizing performed by the team on their particular backlog of User Stories.

3.  A team’s velocity is the end result of many factors, including:
  • Individual team member productivity across the team
  • Team cohesion, collaboration, and effectiveness
  • Team skill set and experience mix
  • Level of programmatic support (i.e., the factors that fall under the purview of program management)
  • Empowerment and level of engagement of Product Owners
  • The team’s familiarity with the business domain, technology mix, and enterprise architecture
  • The amount of automation leveraged in building, testing, and deploying code

Thus, the makeup of the Scrum Teams and the environment or ecosystem within which they operate determine velocity.  Team velocity is ultimately a proxy for the overall health of the software development program and organization.  When team velocity stagnates or drops, the search for potential causes must be systemic as opposed to a hunt for individual culpability.

4.  It is normal for team velocity to fluctuate.  What should concern us are large fluctuations or downward trends in velocity.  Changes in personnel, technology, organizational structure, etc. will affect development teams in different ways and to varying degrees.

5. Improving team velocity is not the goal!  Improving team capabilities, practices, tools, and program support improves team velocity.  Focusing on improving velocity results in attempts to game the system rather than systemic improvement.

Conclusion

Scrum Development Teams are composed of people. People are not machines calibrated to deliver a predetermined rate of output. Teams need time and stability to gel into highly effective teams. Helicoptering Scrum Teams, even experienced ones, in and out of tasks significantly degrades velocity except perhaps for the most mundane and menial tasks (In which case, why employ Agile/Scrum at all?). Decades of reducing people to resources allocated across Gantt charts has led many to also think of Scrum Teams as abstract productivity units. Scrum requires much more of us.



Scaling Agile within the Federal Government Presentation at the Washington DC PMI Chapter

I want to thank the Washington DC PMI chapter for the opportunity to present the topic, “Scaling Agile within the Federal Government” last Wednesday, 27 September 2017.  A diverse group of program management professionals attended and shared valuable insights about their own experiences with Agile adoption within the Federal government.  You may download the presentation below.  You can read the chapter’s announcement of my presentation here.  The chapter hosts many interesting speaking events throughout the year, a number of which I will be attending.  I highly recommend participating as an attendee or speaker whether you hold a PMI certification or not.

Loader Loading...
EAD Logo Taking too long?

Reload Reload document
| Open Open in new tab

Download