Being agile vs Doing Agile
Article 6. Being Agile versus Doing Agile
Agile started as a software development methodology to build a software incrementally using short iterations of 2 to 4 weeks so that the development process is aligned with the changing business needs. Agile adopts a process of frequent feedback where a workable product is delivered after each iteration.
Methodologies include Scrum, Crystal Methodology, DSDM, Feature-driven development (FDD), Lean Software Development and Extreme programming (XP).
Agile development promises solutions to perennial IT concerns: planning and delivering for months before results, projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.
The Agile approach flips the Waterfall approach on its head. Instead of fixing the scope and then estimate the time and the cost to deliver the desired solution, Agile fixes the time and costs for development and estimates the features that the development will deliver.
Agile basics
- A cross-functional team of developers, testers and analysts is assembled. If Scrum is being used, a Scrum Master is on point to act as the facilitator of the team, working closely with the Product Owner/client.
- A product owner creates a wish list of ‘user stories’ called a product backlog.
- The user stories on the product backlog are estimated based on t-shirt sizes (S,M,L) and prioritised with the product owner.
- During sprint planning, the team pulls a small chunk from the top of that wish list (the product backlog) and add to the sprint backlog, and decides how to implement those pieces.
- The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
- Along the way, the Scrum Master keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the product owner re-prioritises the product backlog and the team chooses another chunk of user stories to add to the sprint backlog (based on how much work they progressed in the previous cycle) and begin working again.
However, a number of issues arose and organisations are now trending towards more structure, rigour and control before, during and after the development cycles (and therefore trending back towards Waterfall- see my last article of product vs project for more details).
Traditionally, Agile promoted sloppy requirements- More focus now on controlled and prioritised requirements.
Agile costs were generally higher than reported since a dedicated team of 6-8 is kept around throughout the sprints, not just BA’s and developers.
Different agendas (from the diverse team) arose during sprints which prevented effective management. More control is needed.
Agile, contrary to what we're told to expect, leads to long-running projects because extra sprint (and extra costs) are just added until the scope and requirements are satisfied. More discipline gives the delivery team more certainty.
Agile is not a silver bullet, but it can be very effective for research/prototyping/ discovery-type projects. Being able to learn, adapt, and repeat is an important part of these types of projects.
Agile was created for SOFTWARE development, however it can be leveraged for other types or combinations of projects, but that’s a project in itself!
Also, do not confuse agile with Agile. One is a cultural trait. One is a method. We do Agile. We are agile.
Next up project roles and responsibilities and job families.