I have been caught in a lot of discussions over the past year or so about software development productivity. How to measure it. What improves productivity? Does it come at the expense of quality? All kinds of things to think about. In researching this topic, along with quite a few other folks that I have worked with, I have a set of principles that I would like to discuss.
One area that concerns a lot of enterprise is the requirements process. How do you get good requirements up front. It seems like it should be easy right? Nope! It isn't easy at all. Software systems are difficult for end users to describe before they see them. I think it is one of the reasons that packaged applications have been popular versus writing the application in-house. So what can you do about requirements?
The only thing, that I believe can be done, is to follow an iterative process. That is, don't bother trying to gather requirements up front, because they will never be right, no matter what process is followed. Define some high-level goals, and write something that illustrates those goals. If the requirements cannot be written down on 3x5 cards, then you are specifying too much. Keep it simple, and get something concrete in a short two to four week cycle that the end user can actually look at. The end users will be able to articulate what they like and don't like, and how something should work only after seeing an implementation. That will get the ball rolling, and you can then do iteration after iteration to refine, add features, correct things that may otherwise go way off course.
This iterative process shouldn't be dragged on for a long time either. The entire project life-cycle should be complete within a twelve to sixteen week process at the most. Did you know that research has shown that projects that go on for six months have a less than 50% chance of being implemented! If you go all the way out to thirty-six months, the odds drop to zero! That's right, zero! Keep the projects small and managable, and release early and often, not just in your iterations, but to production as well.
For both principles above to succeed, you must work directly with the end users of what you are building. Don't fall into the trap that a lot of organizations fall into, where they have organizations dedicated to working with business people, and they will translate the requirements for developers. This is a huge expense burden on the company, and it only makes matters worse. Think about it. Haven't we all played the telephone game, where one person starts and whispers something in the next persons ear, and so on, and so on. When you get to the last person, is what the first person said ever repeated? No! Of course, not! This same principle is at work with layers of organizations that are supposedly there to help, but only serve to scramble the message. Let developers, no matter what you think of their people skills, work directly with end users. You will find that you get a better product, quicker, and you will have happier end users.
Keep team sizes small. In knowledge work, which software development is, you should never have a team size larger than seven people. Why do I say that? How did I come up with seven as the magic number? If you look at the research done by Quantitative Software Management on project team sizes, you will see that team sizes between three and seven are the most productive. Large team sizes can cost upwards of 400% more, and deliver 29% later, doing the same size work! This is dramatic. If you have a project that just seems to large to deliver with a small group, don't trust your intuition. It is wrong! Keep the team size small, and if something really is very large, break it up into sub-projects that can be delivered to production in a twelve to sixteen week period. You will deliver value quicker, and the overall project will get completed much quicker and at a much lower cost.
Where are these principles demonstrated for everyone to see right out in the open? Well, its obvious (at least to me). Open source projects work this way be default. They have small sets of contributors at the center. Even large open source communities have divided things into sub-systems that can be worked on by a very small groups with committer access. They work directly with their end users. No middle man. Requirements are not expressed in large documents. In fact designs are not documented at all! Instead, implementations that only demonstrate the overall goal of the project, is how things get started. The process is iterative, with many small releases, some labeled aphas or betas, or release candidates, while others become a "stable" release. This allows the project to get feedback from users early, and users can give feedback in the form of feature requests, bugs, etc. See the parallels to what should be happening in the enterprise?
If you adopt the open source model of development in-house, you will find a huge productivity boost for your organization, and you will find that your end users are much happier, because they will actually get what they need and want, in a reasonable amount of time, for a lot lower cost.
Think about it!
One area that concerns a lot of enterprise is the requirements process. How do you get good requirements up front. It seems like it should be easy right? Nope! It isn't easy at all. Software systems are difficult for end users to describe before they see them. I think it is one of the reasons that packaged applications have been popular versus writing the application in-house. So what can you do about requirements?
The only thing, that I believe can be done, is to follow an iterative process. That is, don't bother trying to gather requirements up front, because they will never be right, no matter what process is followed. Define some high-level goals, and write something that illustrates those goals. If the requirements cannot be written down on 3x5 cards, then you are specifying too much. Keep it simple, and get something concrete in a short two to four week cycle that the end user can actually look at. The end users will be able to articulate what they like and don't like, and how something should work only after seeing an implementation. That will get the ball rolling, and you can then do iteration after iteration to refine, add features, correct things that may otherwise go way off course.
This iterative process shouldn't be dragged on for a long time either. The entire project life-cycle should be complete within a twelve to sixteen week process at the most. Did you know that research has shown that projects that go on for six months have a less than 50% chance of being implemented! If you go all the way out to thirty-six months, the odds drop to zero! That's right, zero! Keep the projects small and managable, and release early and often, not just in your iterations, but to production as well.
For both principles above to succeed, you must work directly with the end users of what you are building. Don't fall into the trap that a lot of organizations fall into, where they have organizations dedicated to working with business people, and they will translate the requirements for developers. This is a huge expense burden on the company, and it only makes matters worse. Think about it. Haven't we all played the telephone game, where one person starts and whispers something in the next persons ear, and so on, and so on. When you get to the last person, is what the first person said ever repeated? No! Of course, not! This same principle is at work with layers of organizations that are supposedly there to help, but only serve to scramble the message. Let developers, no matter what you think of their people skills, work directly with end users. You will find that you get a better product, quicker, and you will have happier end users.
Keep team sizes small. In knowledge work, which software development is, you should never have a team size larger than seven people. Why do I say that? How did I come up with seven as the magic number? If you look at the research done by Quantitative Software Management on project team sizes, you will see that team sizes between three and seven are the most productive. Large team sizes can cost upwards of 400% more, and deliver 29% later, doing the same size work! This is dramatic. If you have a project that just seems to large to deliver with a small group, don't trust your intuition. It is wrong! Keep the team size small, and if something really is very large, break it up into sub-projects that can be delivered to production in a twelve to sixteen week period. You will deliver value quicker, and the overall project will get completed much quicker and at a much lower cost.
Where are these principles demonstrated for everyone to see right out in the open? Well, its obvious (at least to me). Open source projects work this way be default. They have small sets of contributors at the center. Even large open source communities have divided things into sub-systems that can be worked on by a very small groups with committer access. They work directly with their end users. No middle man. Requirements are not expressed in large documents. In fact designs are not documented at all! Instead, implementations that only demonstrate the overall goal of the project, is how things get started. The process is iterative, with many small releases, some labeled aphas or betas, or release candidates, while others become a "stable" release. This allows the project to get feedback from users early, and users can give feedback in the form of feature requests, bugs, etc. See the parallels to what should be happening in the enterprise?
If you adopt the open source model of development in-house, you will find a huge productivity boost for your organization, and you will find that your end users are much happier, because they will actually get what they need and want, in a reasonable amount of time, for a lot lower cost.
Think about it!
2 comments:
Andy -
Todd Sherman here. Very much agree with your philosophies on software development. My software development and management experience has been a slow evolution from the big, huge, requirement heavy big deliverable projects (from my days of big 5 consulting) to recently starting the move to Agile with Scrum.
Just last night, a developer on my team presented a demo. to some of management of a pilot project we'd been asked to complete. He and another person that understood the business side had basically completed the work for the pilot in record time, unencombered by unnecessary requirement sessions, etc., etc. The most senior manager in the room asked the developer, "how long, code time?" 2 weeks was his reply. She was really impressed and commented on a different project she's been attempting to get moving and how they'd been spending all their time in meetings talking about the project, not a thing having been accomplished.
I'm evolving, old habits can take a while to break, but definitely becoming more and more an advocate of the small team, short development, iterative cycle concept every day.
I'd love to hear your thoughts on how best to metric and measure software development productivity.
Todd. Good to here from you. Metrics for software development productivity is definitely a good topic to blog on. I will see if I can put together some coherent thoughts on that for my next blog post.
Post a Comment