This is another post in my series on transitioning from waterfall to agile and devops processes. This post covers the program manager role, a rather unassuming role in some organisations, an important role in others, but nevertheless a role where the right person can potentially make a big impact. There are a few different types of program managers, so let me be clear on the type I will discuss here. Microsoft uses the title for product managers with a horizontal responsibility, i.e. functionality that should go into multiple products. Other organisations use the title for a role that is similar to a product manager tole. Typically, a program manager of this type has an independent responsibility for business results within a certain area. A very different program manager role is a project manager for a deliverable that crosses multiple independent products or teams. Often, a program manager of this type will work with multiple project managers, one for each product involved in the deliverable, but does not have an independent ownership of business results and thus becomes more like an advanced project manager. In Cisco, program managers are often of this last type (and clearly lacks the first type), and alas, some larger products may have their own program manager working alongside the project manager to manage and coordinate outside the product team.
I may cover the consequences for organisations not having the “program manager with business ownership” role in a later post, but here I will cover the “program manager as an advanced project manager” role.
Of the many roles in a development organisation, the program manager role may be the role that involves the most painful change in mindset and daily tasks when a large organisation moves to agile and devops. The traditional tools of a program manager is no longer of much use: defining deliverables, setting and tracking milestones, managing dependencies, measuring progress against the plan, reporting status and escalating issues to stakeholders… But why is that? The reason is that the traditional program management model and associated tools assume a planning horizon (e.g. ship within 6 months), a clear view of what is “inside” and “outside” of the boundaries of what is managed (e.g. we need to ship a and b and rely on c and d to deliver x and y for us to be successful), a desire and need for a pre-deterministic plan for what is “inside” (e.g. we are going to ship a,b,c, and d), and that any deviation from the plan, including “outside” changes, are bad and should trigger a corrective action or some kind of mitigation.
ALL of this is wrong for agile and devops! For one, changing plans is desired, that is called learning. Also, the boundaries of what is “inside” and “outside” may be shifting as the teams learns and gets feedback, and reacting to change is something that each member of the team should do immediately. Planning should be done iteratively based on learnings and changing requirements, and what is actually shipped is not fixed as teams commit to a prioritised set of tasks (backlog), not a fixed set of deliverables.
Alright, so the program manager role is dead, is that what you say?! Yes, the OLD program manager role is dead, really dead. However, the reasons for why the program manager was needed are still there: ensure that multiple teams and projects with independent execution paths coordinate priorities and execute efficiently so that real cross-product value can be delivered to the customers with the right quality!
Can program managers re-invent themselves? I really don’t know, some of them may be stuck in old ways of doing things. There are of course many flavours of agile that companies may choose to adopt, like SAFe, where you get clear definitions (http://www.scaledagileframework.com/rte/) of what a program manager is supposed to do. The problem I have with such frameworks and role definitions is that activities, tasks, and goals are often defined in terms of artefacts and ownership of activities defined by the framework. Thus, the role quickly becomes statically defined, which is contrary to the whole point of agile: constant improvements reacting to learnings. By the way, as a rant on the side: that is probably also the biggest problem with frameworks like SAFe in general. They capture some important learnings and concepts, but become stale and not a framework for change.
I really like to get to the core of what we are doing and what we are trying to achieve. E.g. “Manage risks and dependencies” is an abstract statement, and it involves too many implicit definitions of what a risk is, how you manage it etc. But looking at the problems I have seen in agile and devops, a typical program manager personality can contribute buckets to some of them (but constantly change HOW to contribute to them as the organisation evolves):
1. What do we want to deliver and when? In large programs, multiple product managers need to agree to a set of ordered business priorities. Without clear and shared priorities across the products that are to be delivered together, we get absolutely nowhere. This is the role of the product managers (or rather ironically the role of the other type of program manager in organisations that have those). As covered in the post on the backlog, I believe in a true and single owner of a backlog (delivering on the priorities), and the backlog being defined as the task list a development team uses in their iterations. When a team of product managers come together to define shared business priorities, the team of product owners need to come together to tie their backlogs together (as described in my backlog post). A group of peers with priorities outside the group has always problems with closing decisions because conflicting product-specific priorities will interfere. A program-level product manager (aka solution product manager aka that other type of program manager.. puh!) can be used to drive the program/solution priorities and resolve the conflicts between the program-level and product-level priorities. Likewise, a program-level product owner can work with the product-level product owners to tie the backlog items together so that co-development can be done (where co-development means actual coding done in the same iteration with developers talking to each other). This program product owner role can be filled by a program manager (assuming some technical knowledge).
Solution Product Manager ——— Solution Product Owner ——— Solution Program Manager
|| || ||
Product Managers Product Owners Project Managers
The flow is thus: define and prioritise shared business priorities —> define interlinked product-level backlog items to deliver on business priorities —> plan co-development where needed. I tend to talk about “backlog items that are flagged for co-development”, which basically means that there will be another (named) developer in another team (or more) who should be involved when writing and testing the code for that backlog item.
<Whining rant> When writing this, I really feel the urge to go back to a startup environment and the simplicity of making decisions and pushing things out the door… The less people who don’t code, the higher feature velocity you get. But then again, you typically have just one or a few products and limited coordinations needs… </Whining rant>
Another important thing in devops is metrics and A/B testing. This input should be continuously brought into the business priority process. Often there is a breakdown in communication between engineering (doing metrics and A/B testing) and product management (setting the priorities). I have yet to see program managers really making a difference here, strong architects and engineering leads tend to basically take ownership of parts of product/service improvement, but I believe this is an area of real value creation where a good program manager can make a difference.
Another important aspect of program-level work is to set the right targets and make sure engineers can focus on getting things done. It is important to go to the right level of detail on the program-level of what a specific program backlog item really means. Getting to the right level of detail on wireframes, prototypes, and requirements through demos, transfer of knowledge sessions, and white-boarding is important to make sure that the engineers from all of the teams involved in co-development have a shared understanding of what needs to be done. If there is one person responsible for driving this on behalf of the product owners, things seem to move faster.
Of course, another important part of this phase is to get the architecture right, engaging the senior engineers in each of the teams and preferably with a senior architect with program-level knowledge and ownership to lead the process. In Cisco, there is a separate technical leadership career path where director-level technical leaders (principal engineers) are expected to define and supervise architecture in larger programs and also across programs and business units (I’m btw one of those).
2. How do we tie together iterations to do co-development? Once the priorities have been agreed to on the program level, the engineering managers and product owners need to coordinate and identify when and how to do any needed co-development. This will include backlog grooming, developers planning an iteration together, sharing builds, and coding together possibly on a day to day basis. Two and two teams can manage this nicely on their own, but if three or more product owners and engineering groups need to coordinate, there is often the need for a facilitator. Again, this is more of a solution-level product owner type of role, not a program manager, but a technical program manager would fit nicely in this role.
3. How do we bring together the products, validate that iterations delivered planned outcomes, and qualify the process towards release/deployment? Once an iteration has been done, there is a need to bring builds of each of the products (or services) together to do testing and validation of the deliverable on a solution-level. In a true devops environment with continuous deployment, you will get this validation quickly, but if you deliver products and not devops services, you will need some solution-level live test environment. Solution-level testing needs to be done (again, preferably done as part of the iteration…), and if everything is ok, the builds can be deployed to a wider audience, either internally or to early trial customers. This is a critical stage as solution-level bugs will show up. There is a need for a strong person managing the maturity of features delivered and determining whether to allow the features to go beyond the initial solution test bed. In a devops approach, you will have developed features with #debug flags and feature-toggles, and features can be turned off if they are deemed not mature enough for deployment to a wider audience. The program manager can be an excellent watchdog in making sure that the right quality is achieved before releasing features to a wider audience.
4. Once a development cycle reaches an end and we want to ship, how to get things out the door? We want engineering to have a rhythm, a two-week pace that will give us some small, new improvements and features for every iteration. Ideally, engineering will not miss a beat when the products are released. However, more likely there will be a need for one or two hardening iterations at the end of a development cycle to clean up bugs, improve stability, and fix remaining issues. Once this has been done, all the code repositories should get a release branch, and the bulk of the team should pick up new feature development for the next release, while some time should be allocated to fixing bugs on the release branches and merging back to trunk. Dependent on the products/services, this final step before releasing products to customers can be long or short, but preferably it should be as short as possible. Typically, tasks will be final stress testing, solution-level manual testing, documentation finalisation, knowledge transfers to customer service people and sales engineers, release notes, bug scrubbing, as well as other steps to ship the software. This whole process play more to the traditional strengths of a program manager who is an obvious candidate to own this step of the process.
As you can see, with references to artefacts like backlog and list of business outcomes and to various roles, I get dangerously close to defining a framework of my own 🙂 The difference is that I here describe a(n ideal?!) system of people and deliverables that MAY work, but that must be adapted to people’s experiences, preferences, and beliefs through an agile process where people bounce off each other and change together. If not, the deficiencies inherently found in any human activity will settle and some important things will continue to be dropped, people will have overlapping responsibilities, and teams will work in slightly conflicting directions without the continuous improvement that agile promises.
But in sum, this post is an argument against the opinion that agile and devops mean that you don’t have to do any planning, documentation, or process management. On the contrary, some of your planning and process management need to be even more diligent than in traditional waterfall. So, don’t sack your program managers before you see how they can adapt…!
RSS - Posts