Can Projects and Agile Play Nice?

Cleric, Knight and Workman (13th century)
Cleric, Knight and Workman (13th century)

Here is a story for all you Agile kids out there. Once upon a time the only way to get things done was to start a project, because all developers were mostly bogged down in maintenance of all the systems they had ever constructed before. Once in a while upper management had an idea and a project was born. The project leader was appointed and she would elevate some of the developers from the maintenance mud and form a project team. Projects were mostly executed using the Waterfall Model, where the project was initiated, the software was designed, implemented and finally deployed. If a design flaw was found in the implementation phase there was no turning back, because of the dreaded DEADLINE, when money/time/people ran out. Sometimes the project delivered on time, but almost always it delivered crappy software.

OK, so why this scary story from the Medieval times? Well, even if most of us in the software industry have embraced Agile methods for developing software, there’s still this notion around, that projects are the only way to get things done. Even if the developers in your company worship the Agile gods, there are often bean counters in the upper ranks that need to put a price tag on new or larger development efforts, i.e. limited time/resources, i.e. projects. So you end up with Agile development within a project context. Why is this a problem? The Agile guru Henrik Kniberg mentions the conflict in his excellent presentation about the “Unproject” culture of Spotify (see

In my mind, projects are a bit like mining for gold. The geological survey indicates there should be a mother lode of gold beneath our feet. We dig, blast with dynamite and hack away for a long time at great cost to find it. If we’re lucky we strike gold, somewhat lucky: silver and if we’re out of luck: nothing, but never the coveted mother lode that was predicted in the plan.

Agile is more like panning for gold. You can start right away and if you keep at it, the gold nuggets start showing up. If a spot seems barren of gold, we just pick another spot. After a while the project still hasn’t found the mother lode, but the Agile team has been piling up the nuggets from the start.

I believe that if you’re aware of the problems with projects there are a few steps you can take to make a project play nice with Agile:

  • Look at projects as a way to finance Agile product development activities, not a methodology to use for the development process
  • Keep the project within an existing team/product. Usually project teams are handpicked from different teams or hired externally. This leads to problems, e.g.:
    1. Teams losing member(s) to the project will be less productive or even have to stop developing
    2. The new team must go through the group dynamic phases while being less productive compared to an existing team. This is a bad idea especially since a project is limited in time. Furthermore, the new team may turn out to suck half-way through the project
    3. This may be obvious, but here goes anyway: Do not form a project team consisting of external developers only. What do you think happens when the project finishes? Exactly!
  • Before starting the project, make sure you have a plan for which team will be maintaining the product when it’s finished. Ideally, it’s the same project team, or at least some of the members in the project team
  • Tone down the project deliverables (detailed plans, rigid requirement docs, change requests, progress reports) in favour of delivering useful software frequently (the norm in Agile). Working software that you can demo is a pretty solid progress report and easy to give feedback on.

There are people that want to quit working in projects altogether, e.g. Allan Kelly. See a video of his presentation “Beyond Projects – why projects are wrong and what to do instead” here:

I’m sure you have more to add to this topic. Feel free to comment or send feedback on Twitter @ocklund

Bonus feature!
Create your own bedtime story replacing the following in my Medieval story:
Project = Crusade
Developers = Knights
Systems = Castles
Upper management = Queen/King
Team = Army
Waterfall Model = Suicide Attack
Software = Catapult
Deadline = Dragon

A Holistic View on Developer Productivity

What does developer productivity mean, really? Is it churning out more code or less code? Is it to have less bugs in production or shipping code more often? Is it doing a lot of things or just one thing? Let’s think about this for a moment. I believe developer productivity is about getting more things […]

Improving the usability of Aftonbladet Video-clip pages

We have recently started the process of improving the usability of video-clip pages. In order to get an idea of where Aftonbladet stands compared to other world-class online video/news providers, we conducted an online test answered by 110 visitors of Aftonbladet TV. In this test we compared their perception of an Aftonbladet TV video-clip page […]

Schibsted’s 1st iOS Deployment Meet-up

Schibsted’s 1st iOS Deployment Meet-up Thursday, 28th of April 2016: getting to know each other, guests arrive Friday, 29th of April 2016: the meet-up date We here at Aftonbladet had been planning on having a meet-up with iOS developers across various Schibsted companies for many months. We had a range of topics in mind for […]

Hackday: The Future of Storytelling is social, engaging and rewarding

We gathered students, journalists, developers and designers to get together and conceptualize something new for the news industry. This was our first organized hack event – The Future of Storytelling Hack. The hack was a team-based, news-media-focused prototyping and experimentation event within storytelling over two days at Kungsbrohuset, Schibsted and Aftonbladets headquarter in Stockholm. A good story used to […]