The Problem
Software development team is stressed to the limit. Nights are long, weekends spent fixing critical defects. Releases are far between, yet each is without exception followed by a long string of frequent patches. And as customers are churning in ever larger numbers, employees are quitting one after another.Doomsday? Apocalypse? No, just software development business as usual.
However, just like every problem is an opportunity for improvement, this is your chance to test your software development management intelligence quotient (SDMIQ).
The Test
The test could hardly be simpler: all you have to do is pick a next action you would take if you were in charge of software development organization described above from a list below (and sorry, but only one action can ever be next action):
a) Take a vacation
b) Increase number of developers 10-fold
c) Increase number of testers 10-fold
d) Start having status meetings twice a day every day
e) Increase the number of automated regression tests 10-fold
f) Run all existing automated tests every night and eMail results to the whole software development team
g) Ensure that every change to the product is performed by a stable cross-functional team, and is not released before it's verified by an automated test
Now, take a deep breath, think hard, and pick an answer. Then find out below what the answer you've picked says about your SDMIQ.
The Results
If you've picked action a), you must be wondering what all the fuss is about: description above applies to every software development team you've ever seen and you can't think of anything that's wrong with it. Read on, and you just might get surprised. The bad news: you're as clueless about managing software development as it gets.If you've picked action b), you think that throwing people at the problem can solve it. Well, it may have worked for Egyptians building the pyramids by brute, slave force. But I've got news for you: software development is a different kind of activity, and throwing people at software development problems just makes the problems bigger. Perhaps you should actually read that book "The Mythical Man-Month" by Frederick Brooks, that you've heard mentioned every now and then - no, it's not a piece of Greek mythology! You're in the bottom 50%, so you've got plenty to learn about managing software development and this book is a great place to start!
If you've picked action c), you realize that the problems listed above come from low quality of the software this team is producing, and that testers are a bottleneck in finding all the defects in the product. Unfortunately, you haven't correctly identified the root cause of this low quality, so you're trying to cure the consequence, rather than fixing the problem at its root. Also, try to guess which part of the waterfall will become the bottleneck once the testers are not? You have good intentions, but there's much more to learn, so read on!
If you've picked action d), you've appareantly heard that "those Agile guys" have something called "Scrum", which makes them have status meetings every day. Well, you know you can do better than that, that is: two such meetings a day! Unfortunately, you're completely missing the point of these meetings, which is not to increase the stress by asking everyone to constantly show progress while simultaneously taking away a quarter of their working day. Which easily becomes full working day, for those fortunate souls whose managers have assigned them to four different projects at the same time. Similar to people picking action b), your management style hasn't evolved much since the age of Pharaohs, and it's about time it finally does!
If you've picked action e), at least you realize that manual testing doesn't scale, and that there's a better way to assure quality of your software product. Unfortunately, you don't realize that automated tests that are built separately from the system they test are very limited in the value they can provide. They are bound to be very slow, brittle, and defects that they do find will be constantly challenged by developers as "artificial" (e.g., "I don't think that our users ever press the tab key on this page"). Your SDMIQ is better than average, but there's still quite a bit of room for improvement!
If you've picked action f), you realize that automated tests that are not being constantly run are useless, which is better than 75% of today's software development managers. That's the good news. The bad news is that you, just like the person that picked action e), don't realize that automated tests produced by teams that build them after the fact are very limited in their ability to find defects, and thus in their usefulness, And if your tests were all written first, you wouldn't have the problems described above at the first place!
By now, it should be clear that the optimal action is g), and if you've picked it, congratulations are due - your SDMIQ is in the top 5%!
Establishing stable cross-functional teams will enable easier flow of information between product managers, user experience designers, developers, testers, writers, operations engineers, support engineers, sales, marketing and executive sponsors, lack of which has been the root cause of your organization's problems all along.
Verifying each change through automated tests will then leverage this flow of information to clearly establish which behaviors the product should exhibit, from the business value proposition, all the way to the nitty-gritty details of its implementation (e.g., "what should happen when the user presses the tab key on this page?"). Discussing these details at the same time when the changes are being built allows for iterative clarification of scope, which is how automation of tests can add most value to the whole software development process.
This organizational change shifts the responsibility to get changes verified by automated tests in a timely manner to the whole team, which enforces the testability of the product as its top quality. Now there is a single and simple measure of progress - only changes that are verified by automated tests can be considered done, and everything else is just work in progress (whose quantity should be limited). This keeps the whole organization transparent and honest, as now the fallacies of "code complete" and other artificial milestones can (and thus must) be completely avoided.
Once the cross-functional team learns how to minimize the size of individual changes, limiting work in progress will minimize all kinds of waste and improve their agility, which will mean solving the most important business problems first, rather than following some obsolete plan. This will improve customer satisfaction and minimize their churn.
Having unambiguous definition of when a change is done, and releasing each change as soon, but no sooner than when it is done, will also prevent excessive patching, which will even further limit the amount of work in progress, all of which will stop employee turnover, and drastically improve their morale.
Regardless of your current SDMIQ, it can be improved, and my hope is that going through this exercise has already gotten you started in that direction.
