Vanilla Scrum and Multi-Team Value Streams
Join the DZone community and get the full member experience.Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
If external dependencies are the norm... if they can't be easily managed or tracked... if they tempt you to want to build Gantt charts or dependency spreadsheets... and they seem to impact your team's ability to establish a stable velocity or deliver value... this is where you need some serious transformation work. You really need to redesign your entire organization in such a way that the external dependencies become the exception to the rule.
I think this is where most Scrum evangelists find themselves. When they talk about cross-functional feature teams that deliver value to their customers every sprint... they are really saying that we want an environment where the entire value stream is owned by the team. Product owner has unilateral decision making authority on what... the teams owns the how... and the delighted customer gets working software every sprint.
Like Glen Alleman says over on Herding Cats... that is great work if you can get it.
Most organizations aren't there... and unless you have the ability to retool the entire organization in a way where the teams can own the entire value stream... I think unmodified Scrum is going to fail. Even if the team is successful, they become that sub-obtimatization I talked about in my last post. The good news is, we have options at our disposal that go beyond just doing Vanilla Scrum and fail trying.
I find myself, more often than not, advocating for Scrum or Kanban at the team level... and almost always Kanban at the product or enterprise value stream level. Now we can start talking about managing the organization end-to-end using a flow of value metaphor... we can identify our constraints... we can choose not to start work we can't finish... and we can apply our limited resources where they are most likely to help get value out the door faster.
Like I said... I think there is a time and a place for Vanilla Scrum. I just want us to think through the problem and really look at why so many aren't getting the value they expect from Scrum. If we need to augment what we know works in Scrum with what we are learning works in Kanban... and maybe even a little about what we already know from AUP and DSDM... why not? Maybe if we can find reliable transition patterns, maybe someday we can get to our single Scrum team utopia.
For now... I think we need to be somewhat pragmatic... meet teams and organizations where they are... and help them get to where they need to be. Most of our teams need tools beyond what Vanilla Scrum is prepared to offer.
Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.