Scrum in a formal environment
Last week I assisted the agile cafe at Equalminds. The audience was hybrid in it’s own way: developers, scrum masters, product owners, PM’s, agile coaches, business and functional analysts. An ideal audience to discuss the following topics:
- How do you conduct Agile projects in companies where a more formal project management is being used and Waterfall is applied for most of the projects?
- How can we provide enough formal information about our Scrum project to these decision makers?
- How do we bring together upfront planning and vision with flexibility to change?
- How do we reconcile strong reporting with increased time to market?
- What are the tasks of the PM, SM, PO?
- Are agile and long-term planning mutually exclusive?
Most of the companies want to become more agile, since they fear they will otherwise get extinct. Agile has however sometimes a bad reputation with managers and executives: (“The DEV team does what they want, there is only short-term planning, they do not behave professionally, I cannot control them as I would like…). This article will hopefully help you to understand that both worlds have equal value for your company.
A classical Software Development Life cycle consists of roughly 4 phases:
- Initiation (Planning)
- Definition (Analysis & Design)
- Implementation (Development & Testing)
- Close (Support & Maintenance)
Only the implementation phase is performed in an Agile way. The other 3 phases are tackled in the classical approach.
Beside the Agile team for development, we have the Project Board, Project Management, Program Management and Portfolio Management.
The roles we need during these 4 phases are:
- Portfolio Manager (Product Manager)
- Program Manager
- Project Manager (PM)
- Product Owner (PO)
- Scrum Master (SM)
- DEV team
Roles during SDLC
These roles are not needed during each phase of the project. The SM for instance will only be needed from the end of the definition phase until the beginning of the Closing phase. The DEV team will start a bit later in the project and probably a part of it will assist in the Closing phase as well. The PM will play a minor role during the implementation phase, where the PO plays a major role.
Roles in your organisation
These roles will be part of the different units or teams in your organisation:
SM, PO and PM role for 1 person?
Since a SM, PO and PM will have overlapping tasks, you might assume to assign all these tasks to one physical person. It is much cheaper and there is no knowledge transfer when only 1 person is eprforming all these roles.The PM is responsible for Micro Management (Planning, Risks, Task assignment …) but during the Implementation phase the DEV team chooses what they will implement during the sprint (from a list prioritized by the PO, also called product backlog). A PO is product oriented, typically a more introvert profile, focused on deleievring the best product for your company, whereas a PM will not survive if (s)he is being not extrovert. A SM is a facilitator whereas a PM is more authoritarian. To combine all these skills into one profile is hard. To find somebody who is at the same time introvert and extrovert, a coach, facilitator and leader seems unlikely. You cannot tell people what and how you want them to do certain tasks and at the same time nurture their self-esteem and self organisation. The different roles should be clear to everybody. So we (strongly) recommend using 3 physical persons, since each role needs a different skill and mind set. We prefer clearness and opennnes over vagueness.
Interaction Agile and Project Management
Now where are the interactions between the Agile implementation phase and classical Project Management?
Business Case and Project Initiation Document, Risk register, Issue log, Change Log and Release planning are typical classical waterfall artifacts. But the input for some of these will also come from the Agile Implementation phase.
- The Business Case and PID are created before the Agile Implementation phase even has started, so no interaction possible between both worlds.
- The Risk register and Issue Log can be partially fed by the impediments and issues the DEV team addresses in the Daily Scrum
- The product backlog is the only source about the scope and priorities in your project and is the basis for Scope reporting. In the Agile world it is used to make user stories ready to be taken up in one of the next sprints by the DEV team.
- During the Sprint Review and Retrospective possible scope changes can pop-up that will be registered in the Change Log.
- Release planning is part of the Project Management, but one of the inputs for this are the velocity, derived and updated from each sprint burn-down chart.
- Sprint backlog is an agile artifact only to be used during each sprint in the Agile Implementation phase.
On a daily basis the DEV team, PO ans SM will use the sprint backlog to pick the correct user stories and how to implement them. The burn-down chart will be used to measure the progress of work done.
During the sprint, the same artifacts are being used to follow-up the work done during the sprint and to focus on what the DEV team has committed to. At the end of the sprint the Sprint Review and Retrospective are being held to demo and review the delivered result, and discuss what went wrong and where improvements are needed.
On a regularly basis (each 2 sprints?) a presentation is made for the Steering Committee on the status of your project. The input for this presentation comes from all the Agile and PM artifacts discussed earlier, so you don’t need additional atsks to perform as a PM:
- The Product Backlog will give you information on the scope
- Time and Budget can be derived from the burn-up chart
- Issues and Changes derive from the Sprint Review and Retrospective
Decisions will need to be taken by the Steering Committee about the issues and changes and possibly how budget, scope and time should be adapted where necessary.
Release planning using burn-up charts
To counter the preconception of classical PM’s that Agile and long-term planning are contradictory, we will discuss the burn-up chart. In contrast with the burn-down chart which compares the planned remaining work with the actual remaining work during one sprint, the burn-up chart addresses the long-term planning of your project and releases. The names stands for themselves: a burn-down chart goes down and a burn-up chart goes up.
A burn-up chart shows us in a visual way how much estimated work we need to deliver sprint by sprint in order to reach our target release date or production date. We use the velocity (amount of work delivered by the DEV team during a sprint) which is derived from the sprint burn-down chart.. The velocity is the amount of work delivered during a sprint.
We can derive from our Product Backlog the amount of story points the DEV team will need to deliver to reach a certain release date. The user stories in the Product Backlog have been roughly estimated and prioritized. By adding all the story points of these user stories that need to be ready on the release date, we know the velocity that is needed to deliver the release on time. This is the average velocity. Based on the burn-down chart for each sprint, we know the lowest and highest velocity. This allows us to visualize the best and worse case scenario: we can now predict within a range of uncertainty when the release will be ready.
On the above example we want to measure when a certain release that contains 48 story points might be ready. Average velocity is 5, lowest is 4 and highest is 6. From this chart we can tell that the goal of 48 story points will be reached somewhere between the end of sprint 8 (best case) and sprint 12 (worse case).
You can use a burn-up chart to predict in time when a certain amount of work (release, project completion, specific user story ready or any goal to achieve) will be delivered in the worse or best case scenario. The data you need are:
- A prioritized product backlog
- Each user story that is part of the goal you want to predict should be estimated
- The average, lowest and highest velocity (derived from realistic burn-down sprint charts
You can even visualize on your burn-up chart when additional scope was added to your project during which sprint, which will result in the black line going up at a certain point in time. Otherwise your management will nor understand why the planned release date was postponed.
Be aware that the 3 first sprints, your velocity will be unpredictable since the DEV team has to settle with the infrastructure and the requirements, and is not yet working on normal speed. If you have historical velocity data from the same team on previous projects, you can use these data form the first sprint onwards. So unless you have these historical data, there is no way to predict upfront when a certain amount of work will be ready. You can then settle for a fixed price approach, but we all know that either the customer or the supplier will pay the bill for the added buffers in the planning and the slack in your project. And we all know that doubling the persons in your DEV team will not halve the project duration.
Of course priority changes, new user stories are being added to the product backlog and estimates are being refined. Agile claims to embrace change, so we should at least be capable of coping with this. Planning is an ongoing task and your burn-up chart will reflect more and more the current reality as more sprint and burn-down charts and velocity data become available.
I hope to see you on the next Equalminds Agile Cafe.