Here’s what happens. I’m sure you’ve seen it before. A software project starts with lots of enthusiasm. The team is assembled. A kickoff meeting is held. New relationships are formed. Everyone is energized.
The team is focused on solving a business problem. There is a sense of urgency and a commitment to deliver. The team is at its peak of performance. It doesn’t get any better than this!
The project gets off to a great start. There are no unusual or unexpected problems. Then, usually about one-quarter to one-third of the way through the project, the energy and enthusiasm are greatly diminished. The team has delivered documents, charts, graphs, maybe even some executable code, but nothing to get excited about. The project has become routine — dull.
The project is stuck in a trough of tranquility. Work is getting done and artifacts are being delivered but it’s just not exciting.
Then it gets worse.
The project team becomes complacent. They start to arrive late for meetings or miss them entirely. They miss deadlines by a day or two. They don’t communicate as often or as clearly as they should.
In the worst case (and this happens far too often), there is a crisis on another project and management decides to pull someone from your project team to assist. Hey, things are going so well on your project that you can afford to help out, right?
This scenario is one of the critical problems with a strict linear (a.k.a. waterfall) development approach — analysis, requirements, design, code, test, deploy, user acceptance. By the time the team delivers anything functional, everyone has lost their enthusiasm and worse, they have lost sight of the original project goals. This is how defeat is seized from the jaws of victory.
Any iterative approach — modified waterfall (such as the Unified Process or a spiral model) or agile (such as Scrum, XP, Kanban, Lean, etc.) — that delivers working software early and often will help keep the development team and the stakeholders interested and engaged.
When people are delivering results and receiving targeted feedback, they are motivated to do more. The team will learn faster and the stakeholders will provide better feedback sooner. No approach to software development is perfect but iterative approaches have proven benefits.
Minimize the analysis, planning and designing. Maximize the delivery of functional software. Your thoughts?
I find that this can also happen to just part of the team or only to certain members. They tend to drag the whole team down, and I (the PM) end up running around to make sure things keep moving. Very tiring.
Constant results and a continued sense of starting something new really does help keep people engaged.