Today, many companies are transferring their development processes to Agile frameworks. In this article, I discuss how the concept of a Project and the position of classic Project Manager are transformed in accordance with the Agile paradigm.
What happens with the paradigm of Project?
If we consider the pure Scrum, then instead of Project we only have a paradigm of Sprint – development iteration having duration 1 – 6 weeks. In Scrum, it is considered that a Sprint includes the whole development lifecycle:
Dev lifecycle: | In Scrum: |
1. Initiation | Performed in advance, not within Sprint. Owned by Product Owner |
2. Definition | |
3. Design | Sprint Planning |
4. Construction | Development, the Sprint itself |
5. Validation | Validation is expected to be integrated into execution of the Sprint – into development process (e.g., applying some of Test-Driven Development (TDD) approaches) |
Demo (light analogue of Acceptance Testing) | |
6. Implementation | Production Delivery (it is supposed that it is used a CD (Continuous Delivery), therefore everything is deployed dynamically during the Sprint. |
Sprints replace Projects in case you are able to fit your Development Lifecycle into the duration of a Sprint, as suggested by the Scrum paradigm.
IF
your Company is not friendly with TDD and CI/CD,
OR it seems not possible to divide all the development activities into separated chunks, executed by separate Scrum teams (teams, each of them less than 10 persons),
OR the teams have significant interdependencies,
THEN you do not fit with your development lifecycle into the Sprint and you need something extra that takes the activities, executed previously via Project paradigm. Here are the SCRUM enhancements, such as LESS or SAFe, that give you the required bricks. E.g. in SAFe there is a paradigm of Program Increment (PI): Program Increment contains of 5 iterations (+1 “innovation-tech“) that lasts about a quarter (8-12 weeks), and has its special PI Planning event.
Areas of Development Management remain the same in Agile – how they are distributed
All that means that the Project concept in Agile does not disappear, but is transformed, and in any case, the development process is divided mainly into the same pieces, as in classical development lifecycle. Just to remind you what they are, let’s take them from PMBoK guide (PMP), where the following areas are outlined:
10 Knowledge areas from PMBoK:
(1. Integration)2. Scope and Changes,
3. Schedule,
4. Cost,
5. Quality,
6. Resources,
7. Communications,
8. Risks,
9. Procurement,
Vendors,10. Stakeholders.
Let’s try to distribute PM activities taken from PMBoK, among the new roles in Scrum / SAFe. In Scrum we have only two management roles: Scrum Master and Product Owner. In SAFe these roles are a bit extended:
Roles in Scrum: | Extra roles in SAFe: | |
Scrum Master | Program manager / Release Train Engineer (RTE, member of Agile Program Management Office (APMO) – head of Scrum Masters in correspondent Program, responsible for the organization of Program Increment process | |
Product Owner | Business Owner (key stakeholder – business&marketing), | |
Product Manager (Feature-level Product Owner) | ||
Development team. Its hierarchy is flat, any heads \ team-leads are forbidden. | System architect | |
But these SAFe extensions do not bring us any new dimensions beyond the Scrum basis: Scrum Team, Scrum Master and Product Owner. Therefore, to understand how development management activities are distributed in Agile compared to the classic development life cycle, it is enough to distribute the PM responsibilities assigned in PMBoK between Scrum Master and Product Owner.
Let’s describe the responsibilities of Scrum Master and Product Owner. We have a Scrum guide for it, plus I also have something from my personal experience. And to verify/fulfill the picture, I have made some express analysis through several dozens of vacancies for these roles published in LinkedIn, analyzing their section “you will be responsible for”.
Here are the results:
Scrum Master
Responsibilities:
a master of SCRUM procedures (moderate daily standups, sprint planning (story points) goals, demos (reviews), retrospectives, user stories, acceptance criteria / definition of done)
facilitate setup of Product goal, Sprint goal
(SAFe) facilitate PI-planning
owner of Retrospectives, run a special board for monitoring improvement
Scrum coach for Team & Product Owner: responsible for Team Agile trainings, games with the team
Organize high-performance team,
Team work, team development, lifelong learning, team dynamics, knowledge sharing, continues experiments.
facilitate communications between devs, product owners, stakeholders
(SAFe) Organize high performance Agile Release Train (ART)
=> SM partly covers Project Management areas: Communications, Stakeholders
Facilitator for the team, product owner and organization
A servant leader: Fight against a directive approach to management
Detect & remove impediments (process related)
Optimization of inter-team collaborations
Assist in process-related conflicts resolutions inside and outside the Scrum team, problem solving
=> SM partly covers Project Management areas: Resources, Conflicts
Gather Agile Metrics: Sprint Burndown, Epic/Release Burndown, Velocity, Focus Factor, Bugfix etc.
Sometimes: control deadlines, manage risks
=> SM partly covers Project Management areas: Time Management, Risk Management
some dev-ops activities: JIRA, Git; setup bild-processes, testing, continuous integration
Concluding the gathered responsibilities, the Scrum Master is similar to the coordinator from PMO office: he\she sets up processes, his\her responsibilities are organization of development SCRUM team, maintenance of Scrum methodology and coaching the Agile thinking. He\she is not a manager, but rather a consultant, a coach. Even though he\she is responsible for team performance, he\she is not project-responsible, he\she is not responsible for the production-result. Scrum Master does not provide ready-made solutions, but only directs the team. He\she should not personally take any project decisions – he\she educates the team to be self-organized. All the “what” decisions should come from Product Owner, and all “how” decisions – from development Team. Scrum Master can only recommend something, and only concerning Scrum Processes, not aspects of Business or IT.
The Scrum Master is so much a coach that many consider Scrum Master as a temporary position, just for the first time, until the team is Scrum-adjusted. But, of course, according to the theory of team management, any team goes through a cyclical path of ups and downs, and it is good to have a permanent person (Scrum Master) who constantly facilitates the team.
Product Owner
Responsibilities:
(SME) Subject-matter expert for sales & marketing
gather Product metrics about generated value, market trends and customer behavior
Regular market analysis and user research. Competitive analysis
Identify pain points /needs and industry trends
Expertise in UI/UX
organize A/B testing; Analyze bugs & their fixes, perform root cause analysis
Scope management: owner of Vision, Strategy, Roadmap, Requirements (functional: epics, features, stories, dev tasks; non-functional).
Perform Business process modelling, develop & manage requirements; write user stories.
Product backlog management, prioritization, e.g. Quality vs. Time2Market
Functional specifications, architecture diagrams, API documents, user manuals
Planning: Responsible for Longer / Mid-term / Sprint-level planning
responsible for decomposition of features in backlog up to dev level tasks.
responsible to pick out and manage dependencies related to outlined development tasks.
Define Acceptance criteria, Definition of Done.
Schedule Management: Responsible for Release scheduling. Responsible for Change Management
Perform Status reporting
Cost management
Resources management
3-rd party suppliers (Vendor management)
Communications
do Conflict resolution, problem-solving
Perform Risk management: assess risks and suggest mitigations
Stakeholder management (internal and external), Customer satisfaction.
Communications with Stakeholders on behalf of dev team
Support management
From the prepared list of typical Product Owner responsibilities, it follows that Product Owner combines all the responsibilities of Project Manager, System Analyst and performs some responsibilities of Product Manager.
And the areas of Development management described earlier are distributed between Scrum Master and Product Owner as follows:
Product Owner alone: | Product Owner with assistance of Scrum Master: | Scrum Master: |
2. Scope and Changes, | 3. Schedule, | 1. Integration: |
4. Cost, | 6. Resources, | * Moderating, Facilitating, |
5. Quality, | 7. Communications, Conflicts, | * PMO activities |
6. Resources > Vendors, | 8. Risks, | 6. Resources > Couching, |
9. Procurement, | 10. Stakeholders |
Conclusions
the Project concept does not disappear in Agile, it transfers into Sprint or Program Increment (PI)
All the ideas from PMBoK are very well applicable to Agile. Of course, they require some adaptation, but their high value remains.
Scrum Master is closer to coordinator from PMO office, he\she is more of a facilitator and coach than a Project Manager. Product / Project are quite far from him\her.
Product Owner performs all activities of ex-Project Manager plus he\she extends them with responsibilities of System Analyst and Product Manager.
Thank you for your attention. I would be grateful for your feedback and your questions.
