Agile Software Development has been around since the mid 90's and is gaining acceptance. If you implement mid-range packaged accounting software, like Microsoft Dynamics, you really need to look at this methodology. It is characterized by:
- Customer satisfaction by rapid, continuous delivery of useful software
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Even late changes in requirements are welcomed
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
I would argue that this approach should extend to training as well. Classroom training set up in a generic, simple company with prepackaged exercises that always work has a limited usefulness in my experience. It is more useful for clients to deal with their own system and learn to solve their own problems. For example, one of my clients does an international consolidation of numerous subsidiaries. Instead of designing a training course around the consolidation, I chose one subsidiary and converted it in a test environment. Then I sat with the two analysts and we did one together. As we finished each step, one of the analysts took a screen capture and annotated it in Word for our documentation. Finally, the analysts each did their own companies, with me available for questions. As we hit setup, data and security issues, we solved them together. The analysts came away with a better understanding of the configuration of their system than they would have had it been a pre-packaged demo that ran perfectly.
What do you think?
3 comments:
Brilliant.
The documentation you describe being created by the analysts is also crucially helpful when the auditors roll in.
I have worked in both Agile and more traditional environments. I do like the Agile approach and in my experience it does appeal to some very talented developers and architects. However it is crucial that both the client and the supplier have the same expectations around how it will work. As ever, things become fraught when attention turns to money... the client sponsor has a limit, the end user and supplier is willing to continue developing. What advice does anyone have concerning the appropriate commercial model to support an Agile project? Time and materials (scares the client) or fixed price (how does the supplier continue to absorb late arriving requirements?)
Thanks Anonymous! Feel free to post an example of an Agile project you were involved with.
My advice on the commercial model is to move to fixed price. As you note, scope creep is a huge issue with fixed price. Client and supplier have to be on the same page and trust each other, so that they can have a frank conversation about what is in scope and what constitutes additional services. If that meeting of the minds / trust isn't there, then T&M is the only way to go.
Bill
Post a Comment