How do you integrate Agile Scrum work within your project WBS

Question

Agile Scrum, for example, is a methodology applied to organize the work under uncertainty, where adaptation is required as the work progresses. There is always an objective behind the effort, be the development of a new software, the design of a new product or the development of a marketing campaign. These elements are always part of a larger project, the new software will be deployed, introduced to market, supported, documented. The new product will have to be manufactured etc...

In my view, the WBS will cover the entire scope of the project while the Agile methodology chosen will be applied only to one or some deliverables of the overall project. For example, the Agile SCRUM team must be build, contracts signed, people recruited or allocated. The same goes for the office space, dev environment, virtual team tools/environment.

How do you integrate an Agile work stream into your project WBS?

Answer 1

I cordially disagree with Bogdan's suggestion above that (in my words ...) "WBS is Waterfall." Not necessarily. In my experience it's an excellent way to avoid having your project de-evolve into a "voyage of discovery."

Computer software is effectively a machine with thousands of "parts," all potentially inter-related to one another. It is extremely delicate and can never be fully understood. Therefore, when you write it, you want to "write it right." This is where advance work on a WBS can be very valuable, even if the organization of the teams responsible for building the design will be Agile.

In my opinion, a well-designed project uses both approaches, in order to achieve both a "macro" view (WBS) and a "daily, micro" view (Agile). Don't mix the process of "discovering what the software needs to do, and what will interact with it" with the process of "building and testing the source code." You very badly need to get it right the first time, and you can't get to where your team needs to go if everyone's just looking at "the next 'sprint.'" There has to be a navigator on board that ship, and (s)he needs to be holding a chart, even if portions of that chart now say, "here be dragons."

A rarely-used metric in software, which is quite common in manufacturing, is the scrap rate: the amount of stuff that is built that cannot be used as originally built. In a software project with poor advance planning, this scrap rate can be extremely large, and 100% of it – perhaps more than 100% of it – is "sunk cost."

Answer 2

How do you integrate an Agile work stream into your project WBS?

This is a very broad question to answer, and from what you said in your post, it might be made even broader by a lack of familiarity with Agile practices.

A WBS is not something that you would normally find in Agile practices, like Scrum, for example, because a WBS is synonym with a big design upfront. With a Work Breakdown Structure you decompose your project into smaller pieces. Those will basically be your deliverables. Sometimes, people also include actions within the WBS, as an indication of how to make those deliverables happen.

Agile practices argue that this is most likely a waste. You are trying to plan your project at the beginning of the project, when you know the least about the project. Things will inevitably change once you start the project and some things on the WBS might not be needed, others might suffer modifications, while some new ones might show up. Agile says you should probably not do that, but instead wait until you have more information and more feedback on what the product should do. That will allow you to plan better and to figure out what deliverables are actually needed.

It seems to me from your question, that you want to build the WBS then use Scrum to build everything. Scrum doesn't work with a WBS, it works with a Product Backlog. You might say that a product backlog is just another form of organizing a work breakdown structure (for example, you might also say epics in a backlog might be equivalent to work packages in WBS), but a backlog is usually not defined as detailed as a WBS. The WBS should include all the scope of the project, while a backlog usually includes a higher perspective. In other words, compared to the WBS, the backlog might contain just the higher levels of the WBS and not go deeper into other levels. You go deeper as you need to. After each iteration or release, and after each dose of feedback you receive, you decide on what to go deeper next.

With a WBS you decide "this is all we are going to build". With an Agile approach, you build the thing incrementally, in iterations. A WBS works better when you know exactly what you want, an Agile approach works better - as you said yourself - "under uncertainty where adaptation is required as the work progresses".

So because of the things I mentioned above, you might integrate Scrum with your WBS, but most likely you won't end up with Scrum or an Agile implementation, but just with Waterfall performed in sprints. A more Agile practice of decomposing work than using a somewhat rigid WBS (that contains the total scope of work to be carried out), might be User Story Mapping, so maybe have a look at that for reference.