Introduction to Agile Practices
Heard a lot about this Agile melarkey? Wondered what it involves? This post explains the processes and practices in running a project using an Agile approach.
It covers the concepts of the approach, explains the processes involved. Describes the meetings (or ceremonies) you should have, what to discuss and what their outcomes should be. It also explains who should do what, and when.
The focus of an Agile project is on working software over comprehensive, up-front planning and documentation.
We know the traditional Waterfall approach has 5 phases: Spec, Design, Implement, Test, Release.
The Iterative/Agile approach involves a series of iterations that last 1 to 2 weeks, each iteration encompassing all 5 phases of the Waterfall approach.
Before each iteration, there is a short, fixed-duration meeting called an Iteration planning or a Story Extraction ceremony, involving all the people working on the project and the client.
- Identify features that the site could have. Break them down into minimum working functions that have value to the business. Try to describe them in a way that is visible to the client. Write this scope down on post-its or index cards.
- Prioritise features in terms of must have, nice to have and icing on the cake, using 3, 2 or 1 stars respectively, and note on the card.
- Estimate the effort required to implement a feature. This should be done separately for each person/discipline/team (depends on your organisation e.g. design, front end build and back end build) in points where 1 point = 0.5 person/days, then add them up and note them on the card.
- Identify tests for each feature (something that allows you to know when you are done). This ensures consistent understanding of the scope amongst the collaborators.
- There will be a continual negotiation/reconsideration between scope, priority and effort throughout this extraction process. The result is a collection of Stories. The whole team negotiates which stories to do in the next iteration, don’t do everything, just the most important things that are achievable in the time.
The production team then works on the stories identified for this iteration.
- Specify: e.g. flesh out the scope with any more details required, write down stuff that other people need to refer to now or later, describe user flows, identify UI requirements. Specification should be kept to a minimum, and if none is required, that’s fine. This phase can also help identify questions or information you need the project manager to get to implement the story.
- Design: e.g. architect the system, design the database, plan UI and layout, wireframes, information architecture, usability. N.B. The design decisions made should be based on the objectives of the story with respect to the scope of the story and with the information available. Do not focus on second guessing future requirements as they may not be required or you may get it wrong. Remember: do the minimum to achieve the story – this refers to scope not quality.
- Implement: e.g. build database, write code, style elements, create visuals.
- Test: e.g. ensure functionality works, check implementation against visuals. Only the project manager can confirm whether a story is finished.
- Release to the client.
During the iteration, the production team is encouraged to have daily stand-up ceremonies which are held at the same time and place every day and are time-boxed to 15 minutes, where the team discusses what they did yesterday, what they are doing today and any obstacles they might face. This encourages transparency, knowledge sharing and awareness and reduces the possibility of a developer hiding the true progress from a project manager.
Having completed the iteration you can either have separate Client Demo, Client Feedback and the next Iteration Planning ceremonies, or roll them into one, or do the demo, then let the client have a play on their own, then do the Client Feedback and next Iteration Planning ceremony at the same time.
- The Client Demo ceremony involves going through the tests of the completed stories, explanation of the status of part completed or unstarted stories. It may also include non-technical deliverables e.g. mood boards. The whole team does not necessarily have to attend this ceremony.
- The Client Feedback ceremony allows the client to communicate their thoughts on the stories demoed. Having seen a working prototype, they may identify new requirements or changes to existing functionality or design.
- These become new stories that are described, prioritised and estimated in the next Iteration Planning ceremony. In addition, the stories that were not completed during the last iteration have their effort adjusted to indicate the remaining effort required for completion. Finally, the scope, priorities and effort of all outstanding stories are reviewed and the team collectively decides what to do in the next iteration. The number of stories that you plan to complete in the next iteration should depend on your team’s Velocity. The Velocity of the team is the number of points of effort completed in the last iteration.
And so the process continues until all the stories, or all the stories that the client still wants to pay for, are completed.
There’s an interesting concept in Agile that says ceremonies are like fry-ups: you have pigs and chickens. Chickens are involved, they lay eggs and that’s it, pigs are committed, they die to provide the bacon and sausage. Ideally, you only want pigs at the ceremonies, but if chickens are there, they can only listen in. Project managers must keep the chickens at bay. They run the ceremonies by retaining focus, which are all time boxed.







Leave a comment