Focus on the product not the project.
We use the term “project” a lot in software development circles. One person might be building a small desktop application or a massive group of teams might be implementing an enterprise solution. They are both projects. Neither the development approach nor the technology suite matters. Ultimately, anything can be labeled a project.
Oddly, there isn’t a clear-cut definition of the term — project — in online dictionaries. Here are two examples of definitions that leave me unsatisfied and wanting more:
- “a planned piece of work that has a particular aim” (Macmillan)
- “a planned undertaking” (Merriam-Webster)
That pretty much covers any situation I can think of. In my view, a software development project consists of the work required to satisfy a specific business need. It may take a few days. It may take more than a year. How that work is structured and delivered is up to the organization — that’s where it gets complicated.
Looks Can Deceive
Software development teams following a command-and-control approach like waterfall have clearly defined project parameters. Goals, requirements, timelines, deliverables and costs have to be specified at the outset. For software teams following the principles of Scrum, the parameters aren’t quite so clear. We break up our development cycles into sprints. The temptation to treat those sprints like a series of projects is hard to resist — it’s a natural tendency for teams transitioning from waterfall to Scrum.
Sprints have a set of goals contained within stories. Collectively, the stories to be implemented during a sprint represent the sprint backlog — a set of business requirements for the sprint. The team implements the stories, tests them, and deploys the resulting software. Sounds like a project, right?
This leads to the strong tendency for managers to require reviews, approvals, phases, gates, etc. within each sprint — all the stuff that waterfall projects demand. Of course, Scrum was never intended to be a series of mini-waterfall projects. Applying that mentality results in additional overhead and unnecessary delays.
Sprints are not projects. In fact, if you think projects must be commanded and controlled, maybe you shouldn’t use the term project at all when referring to software development. Think of the sprints as deployments. Think of a set of deployments as a release. Focus on the product not the project.
photo credit: Steve A Johnson via photopin cc
To add a different slant to the above. In my experience, most companies who think “waterfall” tend to also follow Prince2 principals. On this basis, Prince2 describes a project as a “temporary group of people brought together to deliver one or more business products subject to the business case” (or words to that effect).
With Agile practices, a sprint often consists of a sub-component of a product (e.g. login screen of a new website) so aboslutely agree than a sprint is not a project in it’s own right.
However, a number of sprint deployments (and releases) could and probably should be considered a project and be subject to relevant controls
Excellent points, David. Applying project controls across multiple sprints makes sense. Applying the same controls to each and every sprint does not.