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?


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

8 Answers 8


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.


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.

  • 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
    Commented Jun 23, 2011 at 15:59

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.


"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"

  • 3
    +1 for "We need to leverage our synergistic flexibility to generate a just-in-time full service solution"
    – CaffGeek
    Commented Jun 10, 2011 at 17:23
  • Are people really more familiar with movie-making than software-making? Or were you riffing off of "senior director"? Commented Jun 10, 2011 at 18:25

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.


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.


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.

  • 5
    Manager: "We're already done? Great! Let's just use the prototype"
    – Homde
    Commented Jun 10, 2011 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
    Commented Jun 10, 2011 at 17:37

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.