Project Closures in Scrum

Question

In a typical software development environment, project closures mark the end of a project.

1. Project records are completed and archived,
2. resources released,
3. issues and lessons are documented, and
4. a formal dinner/party held for celebration.

Last step is optional, though is very motivating for participants. :-)

Contrast this with Scrum. I know that scrum runs on stories from backlogs. So, technically, every iteration closes certain stories. So, there are two questions here.

1. For a group that works on multiple simultaneous projects, how do project closures fit in?
2. For a project that involves multiple groups, how does this concept apply?

Or, does project closure term not apply to T&M projects at all?

Answer 1

For a group that works on multiple simultaneous projects, how do project closures fit in?

First, "multiple simultaneous projects" is considered a really bad idea. The point of scrum is to sprint and be done. Switching projects to start another sprint is disruptive. Doing two projects at one time isn't a sprint. It's a mess.

However, Scrum is no different from a non-agile (waterfall) method. When the backlog is reduced to approximately zero, you're still done. Just as done as if you had a waterfall approach instead of an agile approach.

Sometimes the backlog is non-zero, but the customer is delighted and doesn't want any more. So you're just as done. Usually done earlier and cheaper than a waterfall (which has to build everything, even the ideas that turned out to be useless.)

For a project that involves multiple groups, how does this concept apply?

Same as a non-scrum project with multiple groups. Nothing changes about the people. They still like a good party.

Or, does project closure term not apply to T&M projects at all?

Why would the billing change anything about the nature of the work or the ceremony at the end?

Answer 2

I usually see agile methods like scrum practices within a more structured project management framework. This isn't a contradiction at all. Agile works for delivery, its goal is to deliver the right software faster. It helps with the interactions between the developers and stake holders. It can be used as part of a fixed period program or for open ended enhancements.

So with that in mind, there is no reason why the rest of the project management can't be managed in a traditional way, with a PM managing the timeline, costs and other dependencies. At completion you have your closure events as usual.

I work in finance, sometimes new regulations happen, or a new exchange appears and we have a go live date for that which is set in stone. We still use an Agile method for delivery but within a more tradtional project managent framework so we get it delivered on time.

The estimation of work units and selecting a solution which is achievable in the time frame available is what makes us good developers (One of the things I should say).

Answer 3

In Scrum, as in all the Agile techniques, projects are minor things that come and go, while the team stays together. So there is no "project-clojure" ritual as such. Rather on project wanes while another waxes. The flow of backlog items gradually shifts from one to the other. The team barely knows the difference.

Indeed, the team may be working on two or three different projects at the same time. Again, they barely know the difference. The backlog items come into the team at the start of each sprint, and the team implements them. They may all belong to one project, or they may be evenly split between several. The team doesn't care. The team just implements the backlog items they are given.

If the business needs to change the priority of projects, they simply change the flow of backlog items into the teams.

Answer 4

Some of the things you're discussing here would be subsumed by most agile processes, with such things as documentation and releases frequently occurring as a matter of course, rather than waiting for some external trigger. That's not always going to be the case, of course, depending on what types of customers you have and what sort of business you're in. For example, if you are creating a single part of a larger system owned by an external entity, there usually is some date driving the process, and that date would be an appropriate time to perform additional housekeeping and, of course, party. Other times, even when the customer is an internal one, the business may still recognize the completion of a business milestone/major deliverable/other that again calls for your end of project bookkeeping/partying. If your company engages in release planning, that's going to give you natural breakpoints, but even if you don't, it's perfectly appropriate to have business driven measures of success. That is, projects might no longer be a feature of your engineering process, but they certainly can be part of your business and celebrating/dealing with them can and should still be a part of your company's culture.