Getting Real and Agile Development
7 December 2008, 16:13 by Chad Reynoldson
Getting Real
I have just finished reading Getting Real for the second time. I first picked it up a couple of years ago and was instantly hooked on the message.
This second reading was mostly to prepare myself for a large web application that I am developing. However, with this reading I took notes to communicate the key messages that directly apply to control system development.
First, read What is getting real? to gain a fundamental understanding. Then look at my key messages and see if you believe me.
- Skip the detailed documentation
- This document is generally filled with errors because there is no objective quality check by a 3rd party.
- It generally contains useless information. Do we really need to go into great detail on how the DVD play button works?
- It generally does not contain all of the valuable information needed to make the system work. A programmer looking for details on what happens when a DVD is to be displayed on the projector will hardly ever find this information.
- A programmer will usually read it once, see all of the holes and errors in it, and then discard it. How much time was spent creating this document?
- Generally it is sent to the customer for sign-off. This sign-off is the CYA in case the lawyers call later. I’ve actually never seen this happen in the real world. When the customer is unhappy, you fix it.
- Unfortunately the results of the time spent on creating this document only delay the project, with the threat of pushing out the delivery date. In reality, the delivery date never moves, so the team needs to work evenings and weekends to recover the lost time.
- Use the GUI design as your documentation
- If the GUI design is solid, a good programmer can take off and run with it. You may need some supporting documentation, stuff that I call A/V modeling. This will be a simple list of inputs and outputs of the A/V equipment in the system, taken from the drawings. This keeps an in-experienced programmer from constantly shuffling through the drawings.
- The customer can see the GUI and more fully understand what they are purchasing. They will have solid input on any changes they may want because they have something concrete that they can see.
- The sign-off on the GUI is much more valuable than the one described above. This sign-off is a better agreement that the customer knows what they will be getting.
- Collaboration with the end-user is a key component for happier customers. When you get them involved in the GUI screens early on, they feel more a part of the team and it helps us deliver something that will make them happy.
- I use GatherPlace and host online simulation sessions with the customer of the GUI design. You’ll have happier customers if you get them involved early.
- Launch, Tweak, Improve
- After launch, don’t give up on your customers and leave them hanging. Make yourself available for changes, tweaks, and support during the warranty period.
- After the warranty period is over, communicate with the customer that you are still available for changes on a fee basis or a maintenance contract. There is no one better to maintain the code than you.
- Reynoldson Control provides a 90 day warranty for this iteration period. We also provide an optional maintenance contract for sustainable support.
Agile Manifesto
After reading Getting Real, I then found the Agile Manifesto . I believe so strongly in this message that I signed the manifesto .
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It is extremely simple. It will make you a happier designer/developer. You will have happier customers.
For additional reading, check out the agile posting on A List Apart .
Comments
Comments are turned off for this article.