Some Agile Practices

Agile Practices that I'm thinking of implementing and as adapted to the environment I work in.

1) Have daily meeting for 10 minutes; Being agile requires open communication; everyone should know what's going on all the time.
Each person states:
a. What s/he accomplished yesterday
b. What s/he's going to do today
c. Any pain points/issues/obstacles

2) Have a process improvement meeting every month or even bi-weekly in the beginning
a. Figure out what's working/not working in the process and make adjustments

3) The BA should be available as development proceeds in each iteration to answer questions that come up and to test. This happens naturally in practice anyway. Much as we prefer a complete spec up-front (which few people read anyway), we should be honest about what the actual process is. Do we want to spend time developing the best spec ever up-front or proceed with Just Good enough requirements and start coding so we get working software?

These questions can be asked in a one-off basis (developer calls BA) or during the short, daily status meeting.

4) Use Burndown charts rather than project plans to track progress. Burndown charts are effective and especially look good to management because you can compare your original estimate to how you're actually doing. You can absorb all kinds of info including your 'velocity', where you hit bumps in the road, etc. Traditional project plans do not offer this because you just keep overwriting the same plan over and over with the latest dates. The n-th plan, after it is updated, looks like it was supposed to happen by design when in reality, you made it conform to the current status of the project. There is no way to compare the n-th plan to the 1st plan to show you how close you were to your estimates. And if you can't do this, how are you going to improve your process? Process Improvement depends on measurement and re-measurement! [I know people will object and say MS Project allows you to do such and such; and this might be true but to date, I haven't found anyone who uses this feature.]

5) Iterative Development and scheduling by feature delivery rather than Initiation, Definition, Design, etc.

6) Get estimates based on time to implement features rather than Initiation, Definition, Design, etc. These estimates would likely be more accurate and something developers can give and live up to.

7) Deploy prototypes and let developers have a go at them to give feedback so you can make it even more bulletproof and to also advertise to them what's coming. Prototypes help developers get familiar with upcoming changes and new features and will enable them to give better estimates on implementation time after playing with a prototype. Prototypes also act as requirements specifications in and of themselves. Rather than have a developer wade through a huge specification document, s/he can fire up the prototype and see the actual behavior demonstrated! A prototype is worth a thousand pages [of requirements documents]!

8) After incorporating feedback from the Dev team, I would go show my users. The prototype needn't do everything. It's a good idea to storyboard a typical scenario and walk the user through it and paint a picture. Picture a child enraptured by a parent telling a story. You want to fully engage the user with a prototype and have s/he contribute meaningful feedback.