Increase the odds of a lasting, healthy software project

Standard project life today: same as 15 years ago... with iterations

I have too often witnessed (and heard about) the same dramatic pattern of behavior over the course of software development projects:

1. Startup: Zeal, pleasure, exploratory thinking, excitement and optimism in the first few months, typically lead by a very small team of focused people with a pioneer mentality. They get acquainted with the domain, form a shared vision of the project with stakeholders, produce a product backlog of user stories to attain that goal, and happily engage in the battle (after optionally having spiked few technical solutions),
2. Expansion: the team expands (often too much and/or too quickly), in order to increase its “story production capacity”. The shared vision and momentum from the first months begin to falter. Yet, most team members still feel motivated and involved in what appears to be a great adventure. Code base grows at light speed.
3. Cruise control: The team less and less considers the long term aspects, and enters in a routine mode, continuously stacking up features, patching here and there the old design to make it fit, without questioning it in depth. In this context, project stakeholders consider the project mature and focus on team velocity. The project’s no longer appealing to innovators, that flee towards more juicy, creative horizons. Technical and functional debts become the norm, but there is very little time and money to address them: let’s be serious, clients pay for getting features now, or they will leave for competition, right?
4. Great Depression: The project has become a huge, fat mammoth, deadly wounded with numerous patches, obsolete code, and technical debts. Adding features turns difficult as heck, and stakeholders just don’t understand why. The team, almost exclusively composed of recent members now, suffers the consequences of past lousy project management. They ask the pace of demands to slow down for some time in order to cut the fat off the code. However, who are these guys anyway? They get slower and slower every month, and would like to slow down even more? They must be either lazy, incompetent, or, more likely, dumb idealists striving for perfection everywhere... Let’s push for quick and dirty for the moment ; we’ll invest time in beauty later, promised!
5. Collapse: Adding a very basic feature takes a month or two. The management decides we need to redesign from scratch, or the client stop to pay altogether and go for competition. The project slowly dies, a ghost team manages the transition to the new system with a mixed feeling of bitterness, rage and lack of interest.

Does it look even vaguely familiar to your experience? Of course, this “tale” depicts a very simplistic and tragic view of the reality. Yet, some projects succeed! How come? With courage and support from management, there is room for action in steps 2, 3 and even 4.

My three cents of advice

If I had only 3 meta-advices to give for software projects, these would be today:

1/ Alignment first :

Teamates strive to be aligned at all times on standards and processes to move forward and respond to change. 
Very small teams (from 4 to 6 members) achieve this with very little effort. By my experience, the difficulty is simply exponential above 8 members.
However remember that alignment applies outside the team boundaries as well :

• build a ubiquitous language from the code to the user stories
• manage stakeholders expectations, to build trust (read the instructive book from Naomi Karten on the subject, or at least this introductory article)
• maintain and update a shared vision, a common understanding of where you stand and where you would like to be a year or two from now (this kind of product ownership develops a genuine motivation for everybody as a side effect).
  
  

2/ Expertise within: 

Nobody should be indispensable, I agree with that. Yet, if the project’s technically complex, a healthy team needs at least 2 proficient or expert members full time (see Dreyfus model on Wikipedia for more details on this skill distribution model).
On living (features under development) projects in Cruise Control phase, the day-to-day activities may require less innovation. However, this certainly does not mean the coding activity has become trivial ; you always need technical leaders on your team, attached to high quality built-into the code, and that other members will trust. Their resignation could represent the visible sign of the future collapse, unless you make sure the best elements in your team are more than just “competent”.

3/ Beginner’s mind and Continuous Exploration:

Extend (or revive) the high energy momentum of step 1, by encouraging focused exploration activities at every iterations (functional, technical or organisational, decided in iteration retrospectives).  

Let me share with you this piece of Zen wisdom from a blog (http://zenhabits.net/how-to-live-life-to-the-max-with-beginners-mind/): “Zen philosophy encourages us to keep our beginner’s mind. What does this mean? Beginner's Mind is about using the spirit of enquiry – without getting stuck in preconceived ideas.”

Invest part-time on learning, broaden and stretch your mind beyond the mainstream thinking, listen to your intuition, experiment new techniques and share with your peers. Reject those silver-bullet dogmas said to be applicable everywhere.

Hey, what about the current mainstream Agile dogmas then?
I reckon Agile may not be applicable everywhere. Values and principles advocated by Agile methodologies will help only if applied matter-of-factly by people who deeply understand their underlying reasons and motivations. Same thing for Lean thinking process: start your journey with a Lean coach that also happens to know intimately what software development is all about (this is a rare gem today).

Exploration requires a large enough Time Horizon

Investing on middle and long-term future in a context of strong market pressure... how many organisations dare to do that? Aren’t they aware of the risks?

In his 4th volume of the QSM series, “Anticipating Changes”, Jerry Weinberg introduces the concept of Time Horizon: “Any change seems more expensive than the status quo, and it is, if you look on a short enough time horizon”.

Striving to convince managers to invest in costly activities that (you think) will guarantee a high ROI potential in the long run makes little sense, if you don’t first make sure they value this Time Horizon... the bad news is that they often don’t so much, or giving in because of too much market pressure.

I read from a blog post (http://tinyurl.com/252r4wx) : “At the operational level one has a time horizon of days and weeks, while at the strategic level one has a time horizon of several years”

Well, I believe any responsible, competent, developer should work at both levels. Stakeholders seldom understand this, which makes our job so terribly interesting and difficult at the same time!

Indeed, it is our responsibility, as developers, to develop a strategic attention for the project inner quality. The growing, insidious decay of code over time is completely invisible to stakeholders (unlike in manufacturing, where any external attentive eyes can notice the inventory stacks, the mess on the floor impeding movements or the bottleneck machine on the production line...).

A team without this level of attention can develop relatively fast for months, in some cases even a couple years, before bad effects start to show up. However, then it is often too late, or at least very expensive, to turn the system into a healthy, productive, state again. (See the story at the beginning of this post) I like to often recall my coworkers that code is both the product we ship to end users and our working environment. Are we ready to mess it up? (unless I know my project will be killed in less than a month, I’m not)

What can we do at our level?

There are several scales of actions :

- At a fine-grained level, the Refactoring automatism before every commit represents the only sustainable way to clean code, and allows best designs to emerge naturally over time through the coding activity flow itself.

- Pair-Programming and Retrospectives (after every iteration and quaterly) are also strong allies, as they offer room for tactical and strategic exchanges between peers, to build up alignment and shared vision. Retrospectives also make it easy to share problems and develop corresponding action plans as a team.

- Slack time ensures the long term success of a project. The key is to put some distance between you and your project from time to time and:

• explore design ideas
• take control of yet “enemy” territories (harness legacy with tests, and redesign parts)
• perfect the testing DSL (invest in your production tools)
• share your knowledge (dojos, presentations...)
• expand your mind with new techniques, new paradigms (invest in yourself)

- Finally, develop Awareness for you and stakeholders, with visible data and charts:
Gather data evidence before irreparable damages surface, in order to effectively communicate the problem with stakeholders.
Be factual, and treat stakeholders with much respect to gain their trust (they don’t know, or don’t remember, what software development is... and what? This is our area of expertise, not theirs, right?).

Of course, those measures will not guarantee the success of your project, but I feel ready to bet they will significantly increase the odds!