Program Management – Are some of the ALM Rangers Symbiotic PM’s?
After a great discussion with two phenomenal Program Managers @ Microsoft (Gregg Boer and Aaron Bjork) I developed another brain implosion, followed by a few background threads that were pondering over how to become more effective as an ALM Ranger and how to become more effective as Program Manager.
What are we covering today?
|
Related posts … |
Revisiting Program Manager Responsibilities
In Program Management – Thinking about PM != PM and the PM role in Microsoft we discussed seven core responsibilities, which include:
| Bridge between the customers/community/partners and the product group |
| Building a bridge between the customers/community/partners and the product group, ensuring that the development teams understand the customer requirements (the“ask”) and in turn that the customers understand the features and constraints of the resulting solution. |
| Leadership |
| Motivational, mentoring and guiding leadership. |
| Ship It! |
| Responsibility and passion for “shipping” solutions that create raving users. |
| Orchestration |
| Orchestration of skills, personalities and (hidden) agendas, ensuring there is value for everyone. |
| Leverage Resources |
| Leveraging,not managing resources, and taking care of any impediments for the team. |
| B-X-T perspective |
| Enabling the B-X-T perspective (Business Value, Good EXperience and that the solution is Technically OK). |
| Integrated Solutions |
| Enabling Integrated Solutions. |
Comparing Product Group and Rangers PMs
Product Group PMs
Fulfilling the seven core responsibilities (and often more) in the Product Group, which is part of Developer Division, is probably the most schizophrenic, yet exciting career. If you need order, exact project plans, an ability to predict your immediate future and/or dislike switching roles (leader, developer, tester, mentor, …) rapidly and fear occasional chaos, then the life of a Program Manager is definitely not yours. The Program Manager facilitates, motivates, develops, tests, designs and takes ownership of removing impediments with one strong objective … “to ship a solution for raving fans”.
The program manager within the product group is typically bound by the agreed backlog, the standards and the milestone plan, which typically focuses on a major, a number of service packs, hot fixes and power tool releases in between.
Lastly the Program Manager collaborates with the users of the technology and with the most valued professionals, the MVPs, to get a good understanding of business requirements, expectations, challenges, problems and adoption blockers. On the other side the Program Manager collaborates with the technical teams to understand the technology, the constraints and options of converting the ever growing wave of requirements to product features.
ALM Ranger PMs
The ALM Rangers are part of the Developer Division as well, loosely coupled with Product Groups. The focus was primarily on VSTS five years ago and switched to Visual Studio ALM last year. One of the big differences between a Product Group PM and the ALM Ranger PM, is that the latter is typically able to communicate with most of the team face-face, whereas the ALM Ranger teams are literally scattered all-over the world, in a distributed, virtual and part-time ecosystem.
 |
See Ranger Index (Who is Who?) to get an idea of where some of the 230 Rangers are located and read Visual Studio ALM Rangers - Reflections on Virtual Teams to get a view of managing virtual teams as an ALM Ranger |
Similar to his peers, the ALM Ranger Program Manager collaborates with the users of the technology. However, the users consist of the typical user of technology, the ALM MVPs and part-time ALM Rangers working as consultants, developers, testers, architects and many other different roles. This introduces the second difference, namely the type of information gathered, which is less about customer “ask” and more about “adoption blockers”.
The ALM Rangers are therefore less concerned what the features are and how they work, focusing primarily on “how to” use the solution practically and to remove any adoption blockers for the community.
The difference in terms of the input results in different solutions, which we refer to as out-of-band solutions, which encompass missing features and/or missing guidance of mainstream solutions such as Visual Studio and Team Foundation Server.
In my opinion the top three benefits that the ALM Rangers bring to the Developer Division include:
- Extended reach and influence into the field and technology trenches, achieved through the distributed family of Rangers. The Rangers are not only gathering adoption blockers, do not only contribute real-world and practical experience which is shared in the out-of-band solutions, but literally contribute their passion, knowledge, experience and personal time to the solutions.
- Early recognition of adoption blockers.
Think of a fire observation station that detects fires early and avoids a raging forest fire through early recognition and intervention. - Rapid response to adoption blockers.
Think of the fire fighters that drop into the forest to deal with isolated fires in support of firefighters dealing with the bigger forest fire.
The reason why ALM Rangers are so passionate and willing to go the extra mile is still a huge mystery. The ability to deal with adoption blockers, collaborate with the product group and deliver out-of-band to a smaller user base … which eventually joins the bigger group of raving fans once unblocked … is probably one of the ingredients for the Rangers recipe.
Recipe for huge symbiosis?
The questions that are currently driving me away from sleep are:
- Is there a possible symbiotic relationship between PG and Ranger Program Managers?
- If yes, how can we build the bridge to nurture and grow the relationship?
So, is there a possible symbiotic relationship between PG and Ranger Program Managers?
This is one of the two questions that we should all answer with a “raving” yes.
As shown in the next figure the program managers on the left always have a backlog, parts of which is in-scope and parts of which is out-of-scope for their current release. The ALM Rangers, as shown on the right, have a backlog of out-of band projects, parts of which is actively worked on and parts of which are out-of-scope primarily because of their limited bandwidth.
When one of the ALM Ranger backlog items (shown on the right), matches a solution backlog item (on the left) below the feature cut-off line, we have an instance of a Ranger project that not only addresses an adoption blocker or missing feature identified by the ALM Rangers, but also a backlog item that the Product Group Program Manager cannot focus on at the time.
The result is an opportunity for intensified collaboration and an out-of-band solution with commitment by both the Product Group PM and the ALM Rangers PM … a win-win scenario which typically results in a block-buster out-of-band solution.
How can we build the bridge to get into a position to nurture and grow the relationship?
We can now focus on the “eye of the problem”, namely how to build a bridge between the product group and the ALM Rangers, which allows the Product Group PM an understanding and insight into what is on the Ranger backlog, for the ALM Ranger PM to get an understanding and insight into the product group backlogs, in particular in terms of items below the feature cut-off bar, and an ecosystem in which to collaborate, identify and commit to the common pain points,
I do not have the answer to this question, but I will continue to investigate, looking for answers to:
- How can the ALM Rangers get an ongoing insight into the relevant backlogs, understanding where the feature cut-off line is or could be moved to?
- How can the ALM Rangers share their backlog with the Product Group PMs and identify potential block-buster opportunities?
- How can we get the Product Group PMs to understand the value of the ALM Rangers and actively collaborate?
Not sure about you, but I am getting excited!