-
This question raised some very good points on how introduce it, and also sell the idea to the relevant people.
In terms of documentation - we document everything on a wiki on an "as needed basis". Anything that will be helpful to other developers (and other people in the company) goes there. We try and cut down on unnecessary documentation that never gets read, or gets out of sync with the code too easily.
If the requirements in your company are different however - I don't see any harm in enforcing rules to say that everything needs to be documented to a particular level. Just remember - it's your software that makes money and you can't sell your documentation!
-
At my company we went through the book, Implementing Lean Software Development: From Concept to Cash, by Tom and Mary Poppendiek. It helped with selling to upper management. It is fairly light on what to do with documentation but that is largely the point of Agile and Lean development, to get rid of extra information that you never use. We took a look back and 90% of the documentation we were keeping was never used even though we did keep it up to date.
What we do now for QA is to bring them in while we are developing and we all work very closely together so we don't need a pile of documentation to give to QA they know what we are working on and the tests are written while we are coding. It is a big transition but it so far it is working very well. There are less bugs that make it through the development cycle and it takes less time to fix them as they are typically found within a day of when they were introduced.
-
Regarding documentation:
What I've seen work well in Agile teams/departments/companies is setting up some simple criteria for deciding if something will be documented. Documentation for the sake of documentation just leads to massive amounts of wasted work resulting in binders of docs that no one ever reads.
Here are some good questions to ask to help you decide if you should document something:
Is the information redundant (is it already documented in the code or the bug database)?
Does this information need to live on past your decision making process. Really? Check again.
Does the information need to be scaled to people outside of your immediate geographic or temporal vicinity?
Once you've decided you need this information to stay around, equally important is choosing the appropriate form of documentation. Email, bug report, Unit Test, wiki entry, ratified document signed in triplicate?
Here are some questions to ask:
Who is the intended audience?
How long will the information be valid? The only thing worse than no documentation is misleading documentation.
Can the "documentation" be automated as a unit test or automation test?
Who is going to receive this documentation, and how do they prefer to receive it?
How often will the documentation be checked?
As for agile examples in actual companies, check out Ken Schwaber's two scrum books. They have many real world examples and are both very short and easy reads.
-
Agile Development can't be sold using documentations.
Instead, ask your management to let you be Agile on a small pilot projet. For this pilot project, you must:
- find a motivated end user to help you.
- be free not to use the standard developping processes of your company.
Then, succeed !!!
-
Is this an internal project or is it for a product that you are selling or delivering to a third party? There is a big difference, but ultimately the user should determine what docs they need, not the devs.
Inform the QA person that one of the key tenets of agile development is to test early and continuously. The tests then become the reference docs, instead of a spec. The conceptual docs can then be handled by a wiki or something similar.
-
An agile process typically produces only one kind of non-code documentation: scenarios and use case descriptions. Implementing the scenarios and use cases is the base of the iterative process. Since one of the point of Agile is to get rid of pointless paperwork, you cannot sell it to an upper management with a paperwork fetish.
"If it's not broken don't fix it" does not work for project management. If your project management merely looks non-broken, it's likely mediocre. You probably need to start by convincing your management that the process just might be improved. Once you are there, you can suggest experimenting with different approaches. Good places to start might be a small self-contained project, or a single bugfix cycle for a big project.
One large company which openly endorses agile development is Google. Nowadays, you would be hard-pressed to find any other fortune-500 company that does not just suck at software development. I do have any reference handy, but you might start by the LEAN talk by Mary Poppendieck at Google HQ.
-
Well, if it ain't broke, then don't fix it.
If your development team is perfectly aligned with your IT department and management, producing value at a quality level and a rate that management is enthusiastic about, then they aren't going to be amenable to change.
If, on the other hand, what you mean is that your audience is either:
- Skeptical about yet another cure for a chronic problem, or
- Believes that software development is the sound of keyboards clacking
You've got a chance. The #1 thing that resonates with management is shorter delivery cycles. The #1 thing that resonates with IT is lowered integration drama.
Your QA manager has reason to be concerned; your aim is to no longer produce those great comfortable reams of plans that gather dust so comfortingly in his/her office and which provide all the finger-pointing ammunition necessary when things go wrong. Hopefully he/she is not purely obstructionist and will be amenable to your arguments that agile processes centralize quality in the development process; instead of fighting for a scrap of attention and resources, quality becomes the driver. "No one knows or cares more about quality than you, Bob, and that's why this initiative is REALLY all about taking the concerns that you've been pushing for years and years, and FINALLY listening to what you've been telling us all along about how important QA is."
Vis a vis "quantity of documentation" : you can dress up tests and user stories and make all the lovely bulleted Word sections and PowerPoint presentations that you want. The classic text is David Parnas' A Rational Design Process: How and Why to Fake It
-
Regarding selling agile, one angle of approach is proposing agile techniques as a way of reducing the "project crunch". By this I mean the overwhelming list of deferred issues, "99% complete" code and oversights that accumulate towards the end of the project. This normally causes a lot of stress and compromises in order to meet the deadline. If a development organisation has never experienced project crunch, it would be a big surprise to me. Therefore I think this is a neat way of locking into a some shared pain and suggesting agile techniques as a load-levelling technique should provoke some interest that can lead onto a more complete discussion of the methodology(s).
-
Not exactly an answer to your question, but I have to say this.
There is a lot of room to improve waterfall process, and agile development is not necessarily the best choice. While agile is favored by current fashion, it's not a silver bullet. It might be worthwhile to consider all possibilities and present your management with a study of several possible processes with technical and business analysis. If agile comes out as best in comparision, it would be a very good selling point.
-
I agree with a previous poster that agile is not a silver bullet. For me, it simply helped make some sense of the chaos, and gave me common-sense principles to get behind.
The first step is to understand the key reasons WHY you might want to consider another methodology. Once you have that, then you can start to review your practices with that in mind and make informed decisions about the right thing to do.
Now, it might be that the right thing to do is to get permission from up high and change everything. But remember, you can adopt any number of agile philosophies without ever saying you "do agile" or having to sell this to upper management. You might still follow a Gantt chart and plan a number of months in advance etc, but you can still pair program or write unit tests first or tackle one complete feature at a time providing you hit your time commitments. And changing your approach internally might just make selling the idea later on easier...
-
Just to chime in with some additional information about my specific situation.
The applications in question are all internal, used to help with various business processes. My job is a government job, so politics are rampant, money is wasted. Essentially every stereotype that plagues government jobs is probably in effect.
The development we have been doing lately is small projects; small teams (3-6 people) and should only take about 6 months of work.
Unfortunately our "one size fits all" SDLC easily takes a year to get all the necessary paper work done. It destroys progress.
Our biggest problem is the mountains of paperwork. When documentation exceeds source code by a order of magnitude there is a problem. Especially when no one bothers to read or update the documentation.
Unfortunately the people in charge of the SDLC are rather set in their ways, they have been doing it this way for longer than I have been alive. They want to do it this way until they retire (so they don't have to learn something new).
What my manager (and myself) want to do is to try to "sell" agile as a new and better approach for these small projects. We want to show the managers that other companies are using it and are having great success with it. We essentially want to sell them on the buzz word despite it being unlikely that they'll understand it.
As mentioned our biggest stumbling block is the guy who oversees the whole SDLC.
-
That does sound like a real challenge to overcome. Documentation tends to be quite a painful subject.
Have you tried to use prior projects and their artifacts as "evidence" of something not being right, in order to "buy" the opportunity to try something different on a small project? Showing someone reams of outdated and useless documentation should allow you to at least ask the question "what could we do differently to solve this" ?
Does the effect of this get felt by your customers? Could you perhaps approach them to partner up on this change? I feel sure you can create more value for your customer a lot sooner, maybe they'd be good advocates for change?
