Disciplined Agile

In this blog posting we overview the decision point, Choose an SCM Branching Strategy, of the Accelerate Value Delivery process goal.

Figure 1. The goal diagram for Accelerate Value Delivery (click to enlarge).

As you know, the Disciplined Agile (DA) tool kit helps you to make better decisions by describing the trade-offs associated with a practice/strategy.  The following is an excerpt from the Choose Your WoW! book:

Accelerate Value Delivery==>Choose an SCM Branching Strategy

We need to identify our team’s branching strategy for our source code repository.  A branch is a copy or clone of all, or at least a portion of, the source code within the repository. We branch our code to support concurrent development, capture of solution configurations, multiple versions of a solution, and multiple production releases of a solution. so that it may be worked on in parallel.  As you can see in the following table there are many branching strategies available to us, strategies which may be applied in combination.

We are excited to announce that the inaugural DA Day virtual conference is taking place May 15th.  Call for presentations is open until April 2nd.  We are looking for short 15 minute presentations on a variety of topics. If you would like to speak on a different topic please feel free to submit it anyway as we may adjust the topics based upon the submissions received.  Share your experiences with the community regarding how DA has benefited your organization.  Get your submission in today!

Attending is an excellent way to attain all of your annual professional development credits in one day.   We will also be providing a sneak peak into a new Disciplined Agile tool to make DA easier to use and learn which will be available to members in good standing.  We are very excited about this application and we think that you are going to love it.

So join us! It promises to be a fun and informative day.

More information here…

Mark & Scott

By now many of you will have heard about the tragic loss of Mike Beedle, one of the signatories of the Agile Manifesto and the thought leader behind Enterprise Scrum.  Mike passed away on March 24th and leaves behind a family that includes six children.

For those of us who were lucky enough to know Mike we’ll remember him as a generous and intelligent gentleman.  He made significant and ongoing contributions to the agile community and we’ll all miss him.

The Disciplined Agile Consortium is proud to have donated to the Memorial Fund for Mike Beedle’s Family and we hope that you consider doing the same.

Rest in peace Mike.

A common question that we get is what is the difference between Product Owners (POs) and Product Managers? From a Disciplined Agile (DA) perspective, it’s a matter of strategy vs. tactics:

• • Product Owners are more tactical in practice.  POs work closely with delivery teams to ensure they build the right functionality in a timely manner. POs will transform the high-level vision of the Product Manager into detailed requirements. To do this they work closely with a range of stakeholders for the product, including non-customer stakeholders such as finance, security, operations, support, audit, and others.  Tactical activities such as attending team coordination meetings, organizing demos, doing sufficient analysis to ensure that requirements are ready to be worked on, and being involved with ongoing testing efforts easily add up to a full-time job.
  • Product Managers are more strategic in practice. They should be focused on the long-term vision for the product, on observing trends in the marketplace, on identifying new potential outcomes or themes to be supported by the product, on supporting the sales/adoption of the product, and on ensuring the product meets the needs of the value stream(s) the product is involved with. Effective Product Managers tend to be very customer focused, although recognize that this needs to be tempered by the constraints and capabilities of your organization. The activities that Product Managers are responsible for – product marketing, supporting product sales/adoption, budgeting, long-term envisioning, customer care, and of course supporting the solution delivery team(s) – can easily add up to a full time job.

We Need to Collaborate

As you can see in the following diagram, the role of Product Manager is different, yet overlapping, with that of a Product Owner (PO).  The PO will spend the majority of their time on tactical activities, including working with the team to communicate stakeholder needs to them and working with stakeholders to elicit and prioritize their needs. The Product Manager, on the other hand, spends most of their time on more strategic issues, collaborating closely with customers (and potential customers) to identify their potential needs.

Figure 1. Example of rolling wave planning for product functionality (click on image for larger version).

There is clearly overlap between strategic, long-term thinking and tactical, short-term implementation.  Product Owners are responsible for the Product Backlog in Scrum, what Disciplined Agile DAD (DAD) teams might refer to as a Work Item List or in the case of teams who have adopted one of the lean lifecycles a Work Item Pool, and some of the items in the backlog/list/pool might be several months away from being implemented (if ever).  In Figure 1, these are items that fall into the yellow or red timing areas, or even the grey area.  Product Managers, being responsible for strategic thinking, will be focused on high-level outcomes or themes for the product.  They may even be focused on more concrete, yet still high level, epics or features.  So we see overlap in the Product Manager’s high-level strategic focus and the Product Owner’s tactical focus, indicating the need for collaboration between the two roles so that the tactical decisions reflect the overall strategy, and the overall strategy is informed by the realities faced on the ground by the delivery team.

Please note that the timing of “short term” and “long term” will vary by product.  In the case of Figure 1 the long-term planning horizon is around the three month point (where the diagram shifts from yellow to red).  That’s just an example, from one team.  We’ve worked with some teams where the long-term planning horizon was anything more than a month.  We’ve also worked with other teams where the long-term planning horizon was closer to a year (they’ve since shortened that considerably).

Shouldn’t Product Owners Also Address Strategic Issues?

Here are a few thoughts to help answer this question:

1. Everyone should consider strategic issues.  Some people, particularly those focused on Scrum, will tell you that Product Owners should also be focused on strategic issues.  It’s certainly good for POs to understand the long-term strategy for the product that they are focused on. In short, POs, like everyone else, should be Enterprise Aware.
2. Each role requires a different, and comprehensive, skillset.  Each of these roles are challenging enough by itself. You’ll have a much better chance of finding someone with the skills to work tactically, and someone with the skills to work strategically, than finding a single person with both skillsets (or the time and inclination to pick up both).
3. There is often too much work for one person.  As we argued earlier, the day-to-day tactical work tends to be a full-time job (and often more) as does the strategic Product Management work.  As a result, you are often motivated to tease these two roles out into separate positions.
4. These are roles, not positions. In straightforward, non-scaled situations, it is common to see a single person taking on both of these roles.  This is common in start-up organizations where the company simply can’t afford to have two people to do this work.  It’s also common with new products in general because it isn’t yet obvious whether the product will be sufficiently successful in the marketplace to warrant much investment in long-term strategic thinking around it.

So, as usual, the answer is “it depends.”  As we like to say in DA, context counts which is why choice is good.

Related Reading

• The Product Management process blade
• Where Do Product Owners (POs) Come From?
• Rolling Wave Planning for Product Roadmaps

I’m happy to announce that Introduction to Disciplined Agile Delivery 2nd Edition: A Small Agile Team’s Journey from Scrum to Disciplined DevOps is now available.  The 111 page book sells for $9.99 US for the paperback edition and $3.99 US for the Kindle edition.  The book is currently available on Amazon.com in the US and will soon be available on Amazon in other countries as per Amazon’s usual deployment strategy.

This book provides a quick overview of how agile software development works from beginning-to-end.  It describes Disciplined Agile Delivery (DAD), the first of four levels of the Disciplined Agile (DA) process decision framework, and works through a case study describing a typical agile team’s experiences adopting a DA approach.  The book describes how the team develops the first release of a mission-critical application while working in a legacy enterprise environment.  It describes their experiences from beginning-to-end, starting with their initial team initiation efforts through construction and finally to deploying the solution into production.  It also describes how the team stays together for future releases, overviewing their process improvement efforts from their Scrum-based beginnings through to a lean continuous delivery approach that fits in with their organization’s evolving DevOps strategy.

What’s Different in This Edition

In the 2.5 years since the first edition was released DAD, and to a greater extent the DA toolkit in general, has evolved. Here are the major changes:

• Chapter 3 was completely rewritten to reflect the changes to DAD, in particular to addition of the Continuous Delivery: Agile lifecycle as well as the evolution of several process goals.
• Chapter 12 was rewritten to describe how the team, and more importantly the organization they work within, evolve into a Disciplined DevOps strategy. In the first edition we just took the team to the Continuous Delivery: Lean point, but in this edition we take them right into DevOps.
• Appendix A was rewritten to reflect the latest release of the DA toolkit. When the first edition was released the 2.1 version of the toolkit was overviewed in the Appendix. Since then the toolkit has been expanded to address four levels – DAD, Disciplined DevOps, Disciplined Agile IT, and now Disciplined Agile Enterprise (DAE) – instead of the original three. With the addition of DAE the DA toolkit provides true insight for how to begin supporting business agility within your organization.
• General updates were made throughout the book, including the update of several diagrams to reflect the evolution of DAD, expanding on a few ideas that readers said they wanted to hear more about, and fixing a few outstanding grammar errors.
• The book is using a slightly larger format, 6 inches by 9 inches, to match An Executive’s Guide to Disciplined Agile format. Similarly we also updated the cover to be consistent with that book.