The 12 Secrets to Application Development Nirvana
As I wing my way back to Seattle, returning from an IT conference in Las Vegas, I find myself reflecting, not on all the latest and greatest IT trends that were discussed over the past week, but on some of the basics I’ve learned during several decades in applications development. Although these practices manifest themselves differently at different times, as technologies and methodology movements come and go, they seem to me to have remained fundamentally constant over all these many years.
So here it is: my 12-Step Program to App Dev Nirvana.
1. Start with the right sort of people. You need people who are smart, who get things done, who enjoy learning, and who interact constructively with customers, management and teammates. I don’t mean to imply that these sorts of people are hard to find. Most of the people I’ve worked with in my career fit this description on a good day, and almost everyone I’ve known (myself included) fails to meet one or more of these standards on a bad day. And certainly all of us have room for development in these areas, and do indeed develop in positive ways over time.
On the other hand, there are situations where not everyone lives up to these standards consistently, where people are progressing slowly if at all, and where you can’t afford to wait for a long-term turnaround plan. These situations are unfortunate for all involved, but ignoring them doesn’t make them go away.
2. Pick the right sorts of problems. Many IT development projects are doomed from the start, either because they are too large, because stakeholder expectations are unrealistic, because the chosen technology is too immature, because organizational politics present insurmountable problems, because you are automating a fundamentally poor process, or for a whole host of other reasons. These projects generally proceed, not because these problems are unknown, or their impact is underestimated, but because people are afraid to speak up, or are not listened to when they do.
3. Form developers into mid-sized teams of 8 - 12 people who work closely together and who are dependent on each other for success. These sorts of teams have wonderful qualities. People learn from each other. People challenge each other. Communication tends to happen quickly and effectively. Performance standards tend to be embraced and enforced by the teams themselves, in a much more effective way than would ever be possible through the intervention of management or a central process group.
4. Give the teams the resources they need to succeed. These resources may be tools, skills, training, outside consulting, or elements of hardware and software infrastructure.
5. Give everyone line-of-sight access to their key customers. Key customers will always include the users and primary beneficiaries of a software development effort, but may also include internal customers (in the way that programmers are customers of functional analysts writing requirements specifications). By line-of-sight access, I mean to imply clear channels of communication, rapid, unambiguous feedback, and availability.
6. Give someone the job of reminding everyone of everything else. By everything else, I mean all the things that could go wrong — late deliveries of software or hardware, dramatic changes in business conditions, inability of the solution to scale to potential volumes of users or transactions, and on and on. By everything else, I also mean the requirements of secondary stakeholders, such as Enterprise Architecture, Information Security, senior management, audit groups responsible for maintaining compliance with Sarbanes-Oxley, etc. (These other requirements should not impede the satisfaction of key customers, and should not over-burden the project team, but they do exist, and cannot be ignored without imperiling the success of a project.)
This is traditionally the role of the project manager, by the way, although it is not often stated as such.
7. Create an environment of continuous learning. Encourage developers to take time to learn new technologies and practices. Provide books, seminars, conferences, training classes and time for experimentation. Hold retrospectives at the end of software delivery cycles. Challenge people to improve and to develop, rather than just continuing to do what they are already good at. Have team members cross-train each other. Make it OK for people not to know all the answers, and to try things that don’t work. Challenge complacency. Don’t settle for the status quo.
If you want a more concrete guideline, everyone should be encouraged to spend 5 - 20% of their time — day after day, week after week — in some form of learning not directly required by their immediate job assignments.
8. Create diverse teams. People don’t learn a lot from other people who are just like themselves. Consider as many dimensions of diversity as possible, including years of experience at software development. (Disparities in this dimension should lead to some healthy mentoring relationships.)
By the way, since teammates will tend to become more like each other over time, new team members will need to be added periodically in order to maintain healthy levels of diversity.
9. Identify clear and unambiguous success indicators. These may be meaningful, numeric metrics, or may be other indicators such as customer feedback at software prototyping sessions, or results of usability testing.
10. Shorten feedback loops. (These should also be thought of as learning loops.) Practices such as continuous build integration, automated testing, software prototyping, daily stand-up meetings, and short software delivery cycles are all variations on this theme. Don’t underestimate the power of this suggestion. When a development team is performing one-month sprints, they suddenly learn and change things about their process that they would never have noticed or bothered with if they were taking a year or two to complete one iteration of their development lifecycle.
11. Foster a healthy attitude towards documentation. Hey, sometimes it helps to write things down. Sometimes pictures help. Don’t make it more complicated than that. Watch out for those who tend to polarize this discussion into document everything vs. document nothing, since both of those extremes are generally disastrous. Also watch out for ceremonial approvals of documents. When 10 people have to approve everything that’s been written down, that’s a sure sign that no one understands any of it and no one trusts anyone else.
An egalitarian authoring tool that includes lightweight content management — such as a wiki — can help here.
12. Avoid extremes and religious movements. In other words, If you meet the Software Development Guru on the Road, Take Him off His Pedestal. Notice that I haven’t used the phrase “employee empowerment” here anywhere — not because it isn’t implicit in much of what I’ve said, but because it’s lately become fashionable jargon used to mean radical abdication of responsibility by management — but there is no faster way to disempower a software development team than to have them put absolute faith in a particular author, book, manifesto, movement or institution. Learn from all of them, but place absolute faith in none of them.
There. That’s it. These things won’t guarantee success — nothing will do that — but if followed faithfully, I sincerely believe they will result in pretty spectacular success rates, much better than industry averages. Why? Because I’ve seen projects and teams succeed when these elements are present, and seen them fail when they are not. And when I boil down all the collective wisdom I’ve heard from colleagues, authors and various distinguished bodies of knowledge over the years, these same elements show up over and over again.
Now, there are a few interesting attributes of this list that I want to call your attention to.
First, these items includes elements of Lean, Agile, the CMMI and the PMBOK.
Second, the list is short, easy to comprehend and actionable. Long, complicated bodies of knowledge have their value, but they should fundamentally supplement this list, not replace it. And while doing all of this stuff consistently will never be easy — what fun would that be? — neither is it impossible or something that will take years to accomplish.
Third — and I think this is a big one — none of these twelve items are exclusively or even primarily actions for developers, or process improvement professionals. Rather, all of these items require at least as much of management as they do of software developers.
Let me say that again: all of the items above are primarily the responsibility of management.
In fact, based on the contents of this list, I might go so far as to assert that management tends to be the missing link in software development improvement efforts. After all, most approaches, including CMMI and Agile, tend to treat managers as at most passive sponsors of improvement efforts being worked by vendors, developers and methodologists. Implementing this list, however, will require more of management than to sit behind their desk and occasionally sign documents supporting the labors of others. In fact, implementation of this list requires management to play a very active and ongoing role in such improvement efforts.