October 2014 Archives

The future of Project managers

As to this topic, I am only talking about project managers in software industry. Same thoughts may not apply in other industries.


Traditional project managers


There is traditionally contract game between business (or product or customer) and R&D (or IT or technology or vendor). In the beginning of the project, business and R&D negotiate a contract, then it is handed over to R&D, and R&D is held accountable for the delivery.

 

Project manager is usually located in R&D side, and he/she is responsible for the successful delivery of the contract. The success is usually defined as on time, scope and budget. The focus is on the output - the delivered features, rather than the outcome - the delivered value. Even today if you look at chaos report, it keeps the same assumption. Project is still considered successful as long as it is well delivered with those measures, even when nobody uses it after it is delivered. Therefore, traditional project managers are delivery focused.


Change from Agile

In Agile, business and R&D work together to optimize value. There is (or should be) no such thing called delivery success, but business success. Agile, Scrum in particular, holds business side accountable for the project success, which is measured by delivered value and ROI. Self-organizing team is focused on delivery and business collaborates with them to maximize value on sprint basis. With this setting, it makes no sense and is actually harmful to keep delivery-focused project managers.


The future of Project managers

While discussing with a few thoughtful PMO heads about the future of their team, two possibilities emerged.


  • Business

Some project managers developed strong domain knowledge and network with business side after working in the industry for 10-20 years. If they can abandon traditional project management thinking (e.g. fixed scope, push team on short-term delivery, manage tasks for team) and adopt Agile thinking (e.g. value driven, support team to build high performance, enable team self-organization), they become good candidates for PO. From what i have experienced, the lack of good POs is one big constraint to adopt Scrum effectively. It is certainly valuable if some project managers could transform to good POs.


  • Coaching

Traditional project manager has little overlapping responsibility as ScrumMaster, and their qualification is also quite different. It is actually misleading to call ScrumMaster as Agile project manager. However, some project managers are indeed very good at working with group. If they are open to practice Agile and gain experience, they become good candidates for ScrumMaster and even Agile coach. Remember that great ScrumMasters work beyond team coaching, they coach Product Owners and organizations too. Project managers often developed broad view, which helps them on coaching beyond teams.


I foresee that traditional delivery-focused project managers will become less and less relevant in the Agile world. On the other hand, i believe that great people can adapt well and sustain their value in a different way.

Empirical process control in Scrum

Scrum framework is based on empirical process control, i.e. you inspect and adapt to achieve the goal. In my CSM course, we do an exercise to relate empirical process control with events defined in Scrum framework. The below table is one typical outcome.

Event

Goal

Who

Information for Inspection

Example about Adaptation

Daily Scrum

Sprint goal

  • Why have this sprint?
  • Timebox
  • Stories

Team

- Story/task status

- Impediments

- Sprint burndown

- Risks

- Add/remove/update tasks

- Change daily plan to work on different tasks or solve impediments

- Renegotiate on stories

- Sprint abnormal termination

Sprint Review

Product goal (1)

  • Release goal
  • Product vision and roadmap

Product Owner

- Product increment

- Product backlog

- Release burndown

- Risks

- Add/remove/update story in backlog

- Change priority

- Next sprint goal

- Update release plan

- Cancel the project

Sprint Retrospective

Process goal (2)

  • Improvement vision

Scrum team

- What happened in the last sprint?

- Any data (sprint backlog, sprint burrndown, bugs, etc.)?

- What worked well?

- What can be improved?

- Improvement actions

- Update working agreement

- Expand DoD

- Try pair programming

- Setup CI server

 

Notes:


  1. Product goal. If your release after multiple sprints, for each sprint, release goal guides your inspection and adaptation in each sprint. However, in some domains where you release in every sprint, or even daily, product vision and roadmap guides your sprint-by-sprint inspection and adaptation.
  2. Process goal. You may define your improvement vision for the next period (multiple sprints) by team envisioning workshop, assessment such as health check.

Explore PO team

PO (Product Owner) is defined as single person in Scrum. However, for various reasons, in practice a team may be formed to fulfill the role of PO. I am using the term of team rather freely, strictly speaking, some of them are only working groups. I'd like to explore different types of PO teams, and hopefully generate insights for you to use while designing your PO team.


Types of PO teams


Here's the main types of PO teams I have encountered.


  • PO with supporters

This is probably not considered as a team, since it is normal that PO as a single person needs to collaborate with others such as domain experts, business stakeholders, and the development team. There is certainly team work here, however, to large extent, it is close to the surgical team described in "The Mythical Man-Month" book by Fred Brooks. I am now talking about the PO work - define the right product, not the whole product development.


  • PO with APOs

In large-scale Scrum context, PO together with APOs (see details from LeSS introduction) form a PO team. This is similar to most management team. Each APO is accountable for its own area, meanwhile serving as team member in PO team. The PO is the leader of PO team.


  • Product discovery team

In dual-track Scrum, product discovery is done by a team collaboratively - "the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items." It somewhat implies that product manager (or PO in Scrum) still leads the team, but the members work more interdependently as peers.


  • Value team

Value team, introduced by Ahmed Sidky in his Agile 2014 session, in many ways is similar to product discovery team. The composition of the team has a bit different focus. Value team seems accommodating more traditional roles, while i prefer the product focus in product discovery team. However, I view the emphasis of facilitator role in value team as an important addition. It highlights 3 important aspects regarding value team roles - ownership of vision, facilitation of team, accountability for results. I see that two of them (ownership of vision  and accountability for results) belong to PO, while SM should facilitate value team (Ahmed has a different view on this). In this understanding, PO seems still taking somewhat leader role in value team.


New type of PO team


If we view discovery and delivery as two sides of product development, and now look at product discovery team and product delivery team, we may wonder why we define a leader for product discovery team, while we don't for product delivery team. If it is possible to have no leader in self-organizing delivery team (aka development team in Scrum), why don't we abandon the idea of defining one leader (i.e. PO) in discovery team? Instead, we create a self-organizing PO team without one defined leader. SM has the responsibility to coach PO in Scrum, while in this setup, SM facilitates and coaches the PO team (aka product discovery team, or value team), in addition to the development team.


Would the new type of PO team work well? This could certainly be controversial. I am listing a few points to trigger the debate.


  • having one PO helps more efficient decision making, but efficient decision making is possible with self-organizing development team.
  • product discovery is more divergent than product delivery, but there could be much divergence in finding architecture solutions too.
  • there is often one leader behind successful products, but successful products where a group of people stand behind exist too.
  • the cases of having group behind successful products are rarer and more accidental, but is it because there has been lack of facilitation and coaching in making the group work effectively?
  • we need one person to interface with team, but why is it possible for PO to interface with development team (without leader), while not for development team to work with PO team (without PO as leader)?


If you experiment this type of PO team, I appreciate that you share back the experience.


About this Archive

This page is an archive of entries from October 2014 listed from newest to oldest.

July 2014 is the previous archive.

December 2014 is the next archive.

Find recent content on the main index or look in the archives to find all content.