It’s what every manager wants — a team that develops better software in less time. Yet all too often, the emphasis is on more software, more documentation, more features, … more, more, more. Does more result in better?
My personal experiences using many software packages and websites strongly suggest that more is everything but better. It brings complexity, confusion, slowness, defects and bloat. In our haste to get more done, we introduce a variety of problems that frustrate and alienate customers and prospects.
Here are seven suggestions for building better software systems. Admittedly, some of these ideas will run into cultural roadblocks. That is, there are situations where caustic behaviors are so ingrained in the culture that any non-conformance will be strongly resisted. You’ll need to apply your own judgement as to how far you can take these ideas.
- Pare down the list of stories planned for the next release. Don’t try to fit in as much as possible. Less is more. Focus on things that really matter to the business. Think market share and profits, not features and functions.
- Allocate time to think, discuss and plan. Don’t charge ahead as fast as you can trying to get as much done as possible. Your work output will improve if you spend more time thinking and less time doing.
- Take a close look at all the activities filling your day. Identify what really matters. Focus on those activities and eliminate, or at least minimize, the rest.
- Determine when, where and how you work best. Set aside some time to work in the conditions that best suit you. Even just a few of hours of “you time” can deliver a big productivity boost.
- Avoid replying to every email you receive. If someone asks you a question, a reply is, of course, expected. If you’re merely copied on an email thread, there is usually no need to reply.
- Don’t attend every meeting you’re invited to. Be selective. Focus on what matters. Try informing the meeting organizer that you’ll be available and can be reached if needed.
- Stop multitasking! It makes you feel like you’re getting more done in less time while you’re really wasting a lot of time switching contexts. Focus on one task from beginning to end, then switch.
Don’t try to implement all of these practices at once. Select a couple that seem to fit your needs and give them a try. Work on others as you make progress. Your productivity will improve and your team’s software will be better.
This is a very sensible post and certainly an approach I take as well. Whilst it goes against the grain of pure agile, I tend to under commit in a sprint but leave the option open to add additional work into a sprint should I find we have the time and bandwidth avaialble.
On top of this, I run 4 week sprint but will only ever fill enough space up for 3 weeks of that sprint. The 4th week, on top of defect fixing and supporting the test process allows the development team to go away and plan for the upcoming sprint (be it architecture discussions, prototyping etc).
Great points, David. I think most software development teams have a tendency to over-commit. We try to do too much in an effort to please the business. Leaving some time available for the unexpected or even for some extra testing and corrective actions makes good sense.