Scrum and classic project management

Andreas,

For planning purposes, velocity is most useful when expressed as a range, such as: "Our Scrum team is able to complete between 40 and 50 points each sprint." With a velocity range we can more accurately provide an answer to the question like you mentioned and at the same time communicate our uncertainty. We can't guarantee that all backlog items will be finished within the time frame but we can forecast what will be done and what might be done.
Let's imagine that we:
- groomed the product backlog to a sufficient depth by creating, estimating the size of, and prioritizing product backlog items;
- estimated the team's velocity as a range;
- calculated the number of sprints (NoS) in the range.
Having this data available, we can answer to the question:
- "What will be done?" by multiplying the slower velocity by NoS.
- "What might be done?" by multiplying the faster velocity by NoS.

If the answer to the question "What will be done?" is not acceptable for Product Owner, you, as a SM, should recommend actions to be taken in order to increase the productivity of the Scrum Team, decrease the number of PBIs, etc.

Good luck!

Andreas, and don't forget that you can use burndown / burnup charts to visualize the progress of the development during a Sprint as well as the progress of the whole project. If any substantial deviations from the planned project path are noticed, you, as a SM, should analyse it and make appropriate recommendations.

If the answer to the question "What will be done?" is not acceptable for Product Owner, you, as a SM, should recommend actions to be taken in order to increase the productivity of the Scrum Team, decrease the number of PBIs, etc.

One thing that Scrum does very well is make visible that which is typically hidden. Andreas cited this in the opening post when highlighting the benefits of early detection in a sprint. In my experience with traditional project management, everything is usually on target until the last third of the time line, when everything then turns red, and people look to cut corners wherever possible to keep to a faulty schedule that was developed when we actually knew very little about the project or the effort needed.

With traditional Sr. Project Managers, it is all about education, and showing them how inefficient their comfortable practices are in providing actual value to the company. A solid Scrum practice improves technical debt, improves predictability, facilitates greater communication and collaboration, fosters learning, addresses vulnerabilities in the organization, just to name a few benefits.

Become knowledgeable about the benefits of Scrum, along with having an Agile mindset. Also understand the inherent benefits of Lean thinking. Then become experienced and skilled in communicating these attributes and practices to those new to Agile/Scrum.

I do want to point out one item mentioned in the original post:

I can fully understand the desire to get an early warning in case the Scrum team is not able to get everything done in time so e.g. additional developers can be assigned to the team.

It is simply not Scrum if we do not promote the benefits of stable teams. Velocity as a reflective and forecasting metric is rendered meaningless if the roster of the team is allowed to change based upon sprint progress. In fact, there are many studies which prove that adding resources late to a struggling "project" actually slows progress, and also deprives the team from learning and growing on their own.

Is the team allowed to "accept" the stories that are offered each sprint, based upon their expertise and capacity? This must be allowed. The team needs to control 100% the amount of work that is forecasted for completion each sprint. Any other variation of this is again not Scrum. It is critical for those doing the work to estimate the work and determine what can be done each iteration - no one else!

An identified Sprint Goal may help matters, as this could allow some accepted stories to remain incomplete or not started if the team is still able to meet the Sprint Goal. Read up on this in the Scrum Guide.

It is not a bad thing for the team to fail completing all of their forecasted items each sprint. As a Scrum Master, allow the team the freedom to find their way and learn what they are capable of doing.

The "Project Management" in your company may object to this approach. If so, understand that they are likely misleading themselves about what the team and the organization are truly capable of. Again, Scrum makes visible that which prefers to stay hidden (i.e. - capacity).

Good luck.

Dear Oleksii,

The idea of a team velocity range is a good one. I will keep this in mind! Thanks!

Dear Timothy,

Thank you very much for your elaborated answer! Maybe I should stress and explain what I mean with a cross-domain team. The projects we are dealing with have a fixed timeframe with a fixed scope of supply (contract of work and services). Several levels of our automation systems must be adapted or even newly implemented according to the contract. All levels are tested together on the final hardware before shipping everything to the customer. The different levels are realised in completely different ways of e.g. programming. This is what I referred to as cross-domain.
The traditional approach is/was that all levels try to be ready for the final test at a given date. Actually, this is never the case. That means besides checking interfaces, integrating everything and testing the functions our automation solution has to provide, everybody tries his very best to get his piece of work done.
I already finished two of such projects applying (as much as posssible) the Scrum framework. Only the lead engineers of each level were part of the development team. Otherwise, the maximum recommended team size would be exeeded significantly. Nevertheless, it already helped us quite a lot to gain a functional perspective over all levels.
Adding additional ressources to a 'sub team' is therefore not directly influencing the Scrum team, just the respective lead engineer has more ressource to get his part of backlog items done.

Andreas,

All levels are tested together on the final hardware before shipping everything to the customer.

Only the lead engineers of each level were part of the development team. Otherwise, the maximum recommended team size would be exeeded significantly.

Adding additional ressources to a 'sub team' is therefore not directly influencing the Scrum team, just the respective lead engineer has more ressource to get his part of backlog items done.

It appears from your statements that you (or your organization) are simply not following Scrum. Scrum seems simple at first, but it is far more than just iterative development and a handful of standardized meetings.

Scrum is based on the concept of stable teams. That doesn't mean a Development Team is assembled from a cross-section of subject matter experts, like past project teams were created. You need to flip your "creation" order. Instead of creating "work" (i.e. - projects) and moving teams through the work (traditional approach), Scrum/Agile wants you to create stable cross-functional teams, and then move "work" through them!

At the end of each sprint, you should have something that is deliverable to the customer. The concept of assembling multiple pieces of work at a future point, and undergoing a large integration effort (i.e. - "hardening" sprint) is again not Scrum. Work to reduce or eliminate the dependencies between teams. Lessons on story-splitting and the benefits of flow may help your understanding of the benefits of this approach and the folly of your current practice.

And finally, with a true Scrum Team, there is no role defined on the Development Team besides Team Member. There is no Lead Engineer, or Team Lead, or any variation. Any work accepted by a Scrum Team for a Sprint is the responsibility of the entire Scrum Team to complete according to the Definition of Done. Nothing is ever the responsibility of a single Team Member to complete, although individual Team Members can certainly work on any Sprint item.

Is the team allowed to "accept" the stories that are offered each sprint, based upon their expertise and capacity?

Yes. So basically the only two options available in our 'implementation' is to reprioritize the BIs and take into account that we do not get everything done or to add additional ressources to the sub teams lead by each developer.

I forgot to mention that all developers (also those of the 'sub-teams') are involved in Sprint Retrospective and the Daily Scrums we do.

The concept of assembling multiple pieces of work at a future point, and undergoing a large integration effort (i.e. - "hardening" sprint) is again not Scrum.

This was the old way without any Scrum approach. I tried to explain that we are now working over all levels together continuously with the integration test always running in parallel and follow the goal to always create a potential shipable increment during a sprint. That we actually prove during the spint.

I am really aware that some items are not according to the Scrum guide and not as I consider them best or OK, but I am working on the transformation of a company towards one embracing agile values. Actually, that is my role as a Scrum master and I prefer a 'divide and conquer' approach about being stuck with the old ways forever. And that is also my motivation to get some input how to speed up this transformation without risking it because of some 'nice, but not fitting our business' ideas.

'nice, but not fitting our business' ideas

I meant that this is most likely the perception of a project manager not being taken seriously with his concerns and the management level for which the old ways worked out just fine for that many years.

Adding a new team member usually decreases the velocity at least initially for a few sprints, as I had seen practically.

> I prefer a 'divide and conquer' approach about being stuck with the
> old ways forever. And that is also my motivation to get some input
> how to speed up this transformation without risking it because of
> some 'nice, but not fitting our business' ideas.

Divide and conquer what? Organizational inertia? Where is the sponsorship for organizational change coming from?

The problem you describe is certainly very common, but without clear executive sponsorship you can only expect local optimizations. That is often worthwhile in itself, since it represents improvement, but isn't agile transformation. You need clear sponsorship for that, and most of all, the sense of urgency for change that goes with it.

In fact, there is not that much sponsorship from top level management. From the other posts one could get the idea that you establish a Scrum team and rearrange the remaining company around it. This will hardly work out without any evidence of a benefit. Therefore, my approach was to start with some projects and collect some evidence that this new approach will also have advantages in our business.
I really consider this the thoughest responsibility of the first Scrum Master in a company, to advocate Scrum throughout the whole organization.

> From the other posts one could get the idea that you
establish a Scrum team and rearrange the remaining
> company around it. This will hardly work out without any
> evidence of a benefit.

If you do not start with one Scrum Team, through which the value stream for a product can be inspected, adapted, and made transparent, what evidence of benefit is likely to be obtained?

In my experience you are most likely to achieve local optimizations which do not empirically and clearly evidence improved product value. It can be worth doing in itself, on the basis that it still amounts to a progress of sorts, but it is non-transformational in nature, and of course it won't be Scrum.

Yet transformation does not actually begin with one Scrum Team. It begins earlier, with an organizational understanding of how value ought to be defined and empirically evidenced. On that understanding you can implement a Scrum Team to gather such evidence; without that understanding there is little case for having a Scrum Team at all.

When it comes down to it, neither the agile Scrum method nor the Waterfall method is inherently better than the other. That being said, each method does have its merits. Waterfall tends to be best for projects where it is not likely that many changes will be made throughout the development process or projects that cannot afford mistakes. Scrum tends to be a better option for smaller projects where changes are either rapid or likely to be made during the design process or with projects that can be modularized.