Is The Need For Projects Dead?
by Kelly Waters
On BAU (Business As Usual) development, an agile approach makes a lot of sense.Moving through iterations, working on features from the Product Backlog, collaborating with stakeholders about the requirements for each feature, delivering working software incrementally.
But what about Projects? (that's Projects with a capital P). In an agile environment, do we still need Projects?
Or is everything literally broken down into small incremental pieces. And Projects, as we knew them, cease to exist?
Imagine life without Projects... Bliss! Or would teams just slip into a treadmill of ongoing Sprints and lack any real purpose.
Debate.
One thing Projects definitely do provide, usually in abundance, is focus. And a real sense of pressure to deliver. With that pressure, often comes intellectual challenge, motivation, team spirit, and a bunch of other positive things too.
Unfortunately, with that pressure Projects also often come with a lot of hassle, over-spending, late delivery, features that don't meet expectations, and a lot of disappointment.
But the reality is, Projects are still necessary in an agile environment.
If for no other reason, they are necessary because the people funding the Project (whether that's external customers or internal sponsors) expect to know what the outcome will be, if they invest their hard-earned money in your Project.
What, exactly, will I get? Exactly how long will it take? What exactly will it cost? How can you assure me the project will be a success?
Obviously in traditional software development projects, people have known these details precisely, because they've specified everything up-front and planned everything in detail :-) And of course things are always then delivered to those expectations, right? :-)
Of course not.
Of course we all know it's a false sense of security, and in reality there is little that will really assure the people funding the Project that they will actually get everything they wished for, on time and in budget. According to independent research, 75% of projects fail to meet expectations. Fact.
But still, Board members and customers continue to expect the impossible. Expecting development teams to predict, up-front, the outcome of their Project in terms of cost, time and quality/scope/features. Fixing all three dimensions.
Unfortunately, however, this is the culture in which most companies operate. It's what they are used to.
Until the 2nd or 3rd generation of agile teams is coming through, and the 1st generation of agilists are in senior positions of influence with customers or the Board, this false expectation will continue to exist.
So Projects are necessary. A necessary evil, maybe? But necessary.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by dotbenjamin
30 July 2008 18:48
Kelly,
I like your post. However, I believe that projects have gone away with an agile approach. Instead of projects, the focus should be on RELEASES. I agree that teams can't just go from sprint-to-sprint without a direction and an end point. Teams needs to do release planning across sprints/iterations based on their velocity. Beyond release planning, roadmaps can be used to determine how the product will evolve over time.
So, something is needed for the reasons you mention, but not sure projects work anymore. Projects tend to indicate a starting and stopping place. Products usually continue beyond releases. Projects also tend to pull resources together for a period of time. Agile advocates dedicated cross-functional teams throughout the life of the product.
Thanks for listening,
Skip Angel
Agile Coach/Trainer
SolutionsIQ
30 July 2008 21:03
Kelly - great post and a great question. Skip makes a great point. A project is nothing more than a container for (product, release, and sprint) backlogs. Take the "project" out of the equation and you are left with what you actually do - teams focus on adding value to products, and people fund product development.
The focus in agile is on the product - enhancing it with additional features and making it better. You don't need a project to do that.
1 August 2008 02:44
I still think having a "Project" is useful. I have been on Agile teams that have gotten to the point of continuous flow and all of the sudden the work becomes monotonous and the energy starts to die off. With a project, the team would at least see an end in sight and I predict (with no real evidence) that the teams would retain a bit of their energy.
Maybe themed releases would work as a substitute for "project" in my scenario...
5 August 2008 00:18
Projects are not dead. However, I do think that how projects, ideas and generic development continues has, and will continue to change. There will be more interaction between end-users and "suppliers" and more of a move towards colaborative working. Agile has been at the forefront of takingthat concept forwad.
6 August 2008 15:00
The need for projects is very dependent on the nature of the company and the software being developed. My company has a variety of software development tasks - some are small enough feature enhancements to 'the webapp' that they don't require a project of their own - they can just be part of business as usual. But there are larger efforts, like a site redesign, or a data importer, or significant chunks of new functionality in the webapp, that need a 'project' wrapper to define their scope. Having a project can help keep the team and the product owner focused on what is and what is not part of this software development activity.
12 September 2008 15:35
I love this topic, and have been struggling with this very thing in my department for six months. I whole-heartedly agree that any time we can eliminate the effort involved in construction and maintenance of a fictitious virtual entity (the Project), we should. As the Project is not tangible, it seems the grouping of features would be better described by techniques posted previously (themes, feature epics, customer processes or benefits, etc.). We have also found that with Lean practices, batching for Releases can add value to the process but batching for Projects adds chunking waste and can delay throughput without adding value.
The need to reasonably apply a financing model deserves much more discussion, as throughput would stop without it. Internally, we have aggregated the funding to a 'Program' level, and aligned high-level objectives with the funding. This affords us more room to be Agile and reduces the effort involved in justifying deliveries against the funding investment because it is done less frequently and at a higher level. However, the Program falls suspect to the same arguments of fictitious projects. I'd be interested in conversations on attaching funding directly to customer benefits or requests for software. This would help with team focus and remove yet another fictitious element.
17 June 2010 10:56
I believe we will always need projects to focus us (development and the business).
But maybe a project needs to stop being "We need something that does ABC" but "We need something to achieve XYZ".
So not "We need a new website" which will become BAU. But "We need to modify our existing website to increase sales by 10% in France". Time limit it if its a lost cause but stop when we achieve and let the business decide the next area to focus on.