Take the 2-minute tour ×

I have a problem with a senior director who doesn't understand iterative development (much less Agile). He is insistent that our software design specification (SDS) be complete before any line of code is written. Complete, to him, means all functional detail is there. Also, being a former Cobol programmer, he wants to see "modules" and flowcharts. This is a Java web app for crying out loud!

Anyway, I'm trying to find a simple place to gently point him to show that the SDS need not be 100% complete before we begin coding (nor can it be complete). Any suggestions?


share|improve this question

migrated from stackoverflow.com Jun 10 '11 at 12:04

This question came from our site for professional and enthusiast programmers.

What does SDS mean? Tried googling, but get a lot of interference. –  Max Jun 10 '11 at 12:18
SDS is "Software Design Specification". He uses that phrase earlier in the post, as well. –  Thomas Owens Jun 10 '11 at 12:36
Flowcharts? Seriously?? Run! Run and don't look back! –  nikie Jun 10 '11 at 18:59
Nothing wrong with a flowchart to illustrate how an algorithm works, can be much easier to read than pseudo code. –  Bjarke Freund-Hansen Apr 15 '13 at 8:34
add comment

8 Answers

As a consultant, I understand one simple rule of consulting:

  • You can't help people that don't want to be helped.

You can't make anyone do anything they don't want to do except by force of authority, which you don't have.

As a coach, I introduce Agile with three rules:

  1. It is impossible to gather all the requirements at the beginning of the project.

  2. Whatever requirements you do gather are guaranteed to change.

  3. There will always be more to do than time and money will allow.

and one goal:

  • Deliver something of value every week.

That's all you need to get started.

Convincing your manager is another thing.

share|improve this answer
add comment

You can't "make" a manager understand agile any differently than you can make a developer understand it. You need to present him with the arguments (the books of Kent Beck are a good start) and let him make up his own mind.

Alternatively, you can ask him to let you run an experiment. Take a small project and run it with iterative development and keep close tabs on time, budget, quality issues, and team satisfaction. Compare it with previous projects (or releases) and see if it was better, worse, or neutral.

share|improve this answer
The 'experiment' approach is what my group is doing now with one of our new pieces of work. Seems to be working so far - 3 iterations in, everyone outside our group is happy; the developers even more so. –  DaveE Jun 23 '11 at 15:59
add comment

You Don't

First of all, why is a Senior Director even involved in the choice of software development methodology? That decision is way below his pay grade, smacks of micro-management, and speaks volumes of distrust.

Second, why does he need to understand it at all? If the software specs are fixed in stone then there will be precisely one iteration. If they're not, then there will be multiple iterations. This is not his decision.

If he thinks it is his decision, then he is undermining the authority of the IT Manager, project manager, IT architect, team leads, and development team. So he should write the @#$%ing software himself, or STFU and let the professionals do their job unencumbered by dinosaur brains.

I am not kidding. If he can't trust you to do your job, he should do it himself and you should run away screaming.

share|improve this answer
+1 for the guts to tell it like it is. –  Wayne M Jun 23 '11 at 13:56
add comment

"Making software is like making a movie, you need to do planning upfront but during filming you need to do re-shots, re-visit old scenes and edit the final product in order to ensure a good outcome"

Then again, he is a manager, so in his words:

"We need to leverage our synergistic flexibility to generate a just-in-time full service solution"

share|improve this answer
+1 for "We need to leverage our synergistic flexibility to generate a just-in-time full service solution" –  CaffGeek Jun 10 '11 at 17:23
Are people really more familiar with movie-making than software-making? Or were you riffing off of "senior director"? –  Alex Feinman Jun 10 '11 at 18:25
add comment

The old saying applies: You can take the horse to the water, but you can't make it drink.

As others have pointed out, what should really matter to this senior director is business value. You could try to provide a quick estimate of how much time you are going to spend drawing up his flowcharts and module diagrams and writing a "complete" SDS (ridiculous concept, but give him what he wants). If I know anything about these things (and when I started writing software, that was the way it was done) then your estimate will easily be several man weeks, if not more for a sizable project. Express that figure in money.

Then show him how much functionality you could deliver in the same time. Talk to a few people in the business on how much time it would save them to have a basic web app doing those things you could deliver in that same time. Then multiply this saving by however often they use this function in, say, 3 years. Express that in money.

There are probably other business benefits that can be expressed in money. My favourite is always "goofball" prevention. If your software can help to minimize disasters or avoid them altogether, then find a recent disaster and express it in money terms. Then say to your boss: If we had this right now, we would have saved this money.

And if the money trick doesn't work, then maybe should walk up to him and tell him to stop micro-managing his team. Although, in my experience, that is more likely to get you fired than anything else.

share|improve this answer
add comment

The simple place might be the Manifesto for Agile Software Development.

The information you find on this place is about the core principals of agile software development defined by a group of well known professionals.

That is

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

But please have a look at the page in detail to get the full intent.

share|improve this answer
and possibly more importantly to get the point across: halfarsedagilemanifesto.org –  gbjbaanb Jun 11 '11 at 0:12
add comment

I would suggest trying to show him that by doing "Rapid Prototyping" (aka starting to code the first few iterations) you can more quickly and accurately flesh out your SDS (meaning less rework later) and begin to deliver business value earlier. Really, most likely business value is all that matters to this director and he has decided that the best way to achieve it is through this sequential process. You need to show him in his terms why your approach is better.

share|improve this answer
Manager: "We're already done? Great! Let's just use the prototype" –  konrad Jun 10 '11 at 12:40
@mko: If the objective of this exercise is to convince the manager not to insist on such detailed specifications, then that kind of response would be a clear win. Though it sounds as if there's virtually no chance of that happening in this scenario. –  Aaronaught Jun 10 '11 at 17:37
add comment

This might be of help - http://www.youtube.com/watch?v=4u5N00ApR_k

In this movie "I want to run an agile project" we follow the experiences of one such brave project leader, Luke, as he has many different encounters throughout the enterprise, working to establish and deliver his Agile project.

share|improve this answer
add comment

Your Answer

