Software Project Process: Focus on Core Beliefs
For the experienced software developers out there, I have a question: what are the main things you believe, based on your experience, most influence the success of a software project? I should provide some context. I’m not talking about a trivial project, or a throw-away prototype, although I’m sure we all recognize that there are some principles and practices that apply to all software projects – for all projects of any type, for that matter. However, for this discussion, consider projects whose goal is to produce a production-quality, enterprise-scale application. In a previous post, Wise Project Management Always Starts With “Why?”, I said that I believe we can only be effective in execution of any project when we first understand why we need to do certain things and everyone understands the “why”. This can help us to keep our focus on value – if we can’t articulate the “why” behind what we’re planning to spend significant time and effort on, there’s a red flag that maybe we shouldn’t be doing it, or should at most be spending minimal effort on it.
In this post, I’d like to consider this idea from a slightly more concrete perspective. Consider some of the core beliefs you hold about what can make or break a software project. I hope issues such as “which line the team decides the curly braces should be placed on” are not in this list for you. I’m talking about issues that really impact the team morale, the ability to deliver on agreed quality and schedule, to keep the project moving down the tracks in a positive direction, with clear intention.
So, let’s think about this idea of focusing first on what we believe to be those core “make or break” principles. I’m not going to argue over whether to consider these values, principles, tenets or whatever – in practice, I don’t believe that really matters. I’ll just refer to them as “principles” for the remainder of this post. What is it that you believe to be absolutely critical? And, back to the point of the previous article, WHY do you believe these tenets are so important? There may be some principles that you believe apply to all projects, but there will almost certainly be a need to closely consider a particular project as well, since some principles obviously have a “when this is true, then that is also true” aspect.
Let me share a sample of some principles I personally hold to be true for most production-quality software projects, along with some of the reasons behind them – i.e., the “why”:
1. Features slip, not schedule.
Why? Something needs to be predictable. Moving the schedule around constantly creates chaos and hurts team confidence. It also delays much-needed feedback for your team, which occurs at delivery time. Also, once you start making exceptions, the “exceptions” become the rule. And, before you know it, project stakeholders start to question your team’s performance because all that most of them see is that your team doesn’t seem to be able to keep its promises. Pushing your schedule out is also a “project smell” that may indicate that your team needs to improve its ability to estimate work. When your process needs work, don’t let yourself off the hook – fix that issue, rather than making yourself feel better by placing a band-aid on it. There are so many more reasons for timeboxing iterations and sticking to this.
2. Iterations are less than 30 days.
Why? Well, the exact number of days – 30 – is somewhat arbitrary, but I like to be as concrete as possible. The idea is really that iterations need to be very short. Your team needs frequent feedback – from end users on how well requirements have been interpreted, the level of quality of the system, how well the team is able to estimate and deliver on those estimates, etc. The longer you delay feedback, the longer the team runs the risk of remaining on the wrong path. Like an airplane, projects need to make constant course adjustments, and the longer the plane continues on the wrong course, the greater the chances are that it will waste valuable fuel and its arrival will be delayed.
3. Follow the patterns: not just the well-known “gang-of-four” software patterns. Your team should establish common patterns for recurring themes throughout the system and communicate those and ensure they’re being followed during code reviews (we are doing code reviews, right?).
Why? Software design and development is tough enough without making it harder by having a half dozen different approaches to implementing a web service, for example. Reserve the creative juices for new problems, where creativity matters. Every new way of coding the same, or similar, type of capability introduces yet another complexity that every developer maintaining or extending that system will have to grapple with. Each new way of coding something also introduces yet another opportunity for new bugs.
4. Demo at the end of every iteration.
Why? When you know you have to perform a demo, especially to someone outside the development team, you’re more committed to quality and to sticking to the principle of timeboxing. The team will want the demo to go smoothly and, since customers will likely need to block out time to attend in advance, it becomes more difficult to allow the schedule to slip. If there is no demo, it is all too easy to ignore known issues and project challenges, to allow the schedule to slip, and to not clearly communicate the features that did not get implemented and why.
5. Be courageous, tell the hard truth.
Why? Duh! If we have to ask, there’s a big problem. But, I’ve personally witnessed many occasions when teams are tempted to hide the truth or commit to something they have no way of knowing can be accomplished, often hoping that something will miraculously change so that the truth becomes irrelevant. The truth is never irrelevant. While there may be some cases in which it seems to turn out OK – in that, you don’t get “found out” – in almost every case, covering up will eventually lead to you being discovered. For example, you tell the customer “Yep, the team can deliver that new feature in two weeks”, when you haven’t even discussed with the team what it takes to deliver that feature. The truth would sound more like this: “We don’t yet know what it takes. The team will need to first understand the requirement in more detail and then estimate the work involved."
You may disagree with some of the above principles or you may disagree with my reasons for them. And, of course, this is not my entire list. My intention for this post is not to sell you on the specific principles that I personally believe in (that may be for a future post ). My goal is to get you to consider taking some time to think through your own beliefs and even take some time to write them down and challenge them. We must also recognize that others will come to projects with their own beliefs, based on their own experience. The value lies in being intentional about what the team will agree on as its guiding principles and then communicating those clearly, both internally and externally. I’d even go as far as to put the team’s agreed-upon principles in a very public place for your team and its stakeholders to see. Make sure all project stakeholders understand that these are the things that guide the team. This is a major part of setting clear expectations, which is so much more important than we often allow ourselves to believe. This can serve as a very powerful map, or at least a compass, for the team.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)