I presented yesterday at the annual Australian Computer Society (ACS) conference in Canberra on strategies for implementation of new media. In the breaks, walking around and chatting to people, I discovered that many organisations are taking the leap and adopting Agile methods to help speed-up delivery of their own projects. But what I learned about how many projects are proceeding on this path made me quite sad as an agilist.
Design before development is not Agile
If the developers are doing agile (ie: using extreme programming) and the designers, BAs and user-experience guys are working (or have worked) up-front, the project is not Agile and neither are its developers. Agile demands a multi-disciplinary approach. Agile also requires a highly collaborative approach. It means everyone working together to complete smaller pieces of the project, delivered in an order that reflects its inherent business and user value.
Serial team work is not Agile
Serial work is just another name for Waterfall. Getting one BA to do a large requirements document, and then another BA to do the Use Cases afterwards is not Agile.
Agile, specifically Scrum, requires the team to work together on the same products at the same time. In essence, they work in parallel doing analysis, design, development and testing all together. They plan this work together, they declare what they can commit to as a team for the specified time of the Sprint. They spend time together refine the backlog. They demo their completed products together to the Product Owner. They have retrospectives together.
Three months is not a Sprint, its a marathon!
Sprints are short, highly focussed, time-boxed periods of collaborative work for the team. The sprint must be short enough in length for the team to adequately understand what they can commit to complete in that time period — too short a time and the team simply won’t have enough time to get things done, but too long a time and the team won’t be able to adapt to estimate what they can actually complete or adapt to changes in requirements or adequately estimate what they can complete within that timeframe.
If it’s important in the project to have significant timeframes for planning and reporting, use Prince2’s Stage Boundaries to help quantify the scope in terms of epics, plan architectural needs, and epics as the milestones. Then, use 2-4 week timeframes for the Sprints to plan and execute the needs of the Stage.
A team of 20 is not Agile
With larger teams comes the need for more communication to create a shared understanding of requirements. In large teams collaboration can suffer as a result. If you’ve got only a few team members there’s typically not sufficient enough different points of view for the team to be multidisciplinary and address all of the needs of each product in parallel work.
If you have a larger team population, try instead to operate using what is known as a ‘Scrum of Scrums‘:
- Break the larger group down into smaller teams
- Extend Sprints from 2 to 4 weeks to enable the smaller groups time to cross-collaborate in ‘virtual teams’
- Increase the level of standardisation and baselining of the architecture and user-experience by adding crtieria to the Definition of Done so that the end products work seamlessly
Doing stand-ups alone is not Agile
Stand-ups are a great time for the team to meet and report to each other on what they’re up to and seems to be a common first step in adopting agile methods. It’s also an important time for the Scum Master to learn what’s going on, understand the progress of tasks based on what the team commited to during Sprint Planning, and see where they can step in to help the team achieve its goals, remove impediments to work, and assess upcoming risks in order to mitigate their effects before they hit the team.
Just because you are doing standups, however, doesn’t mean the team is agile. It just means good communication.
How to become Agile
1. Stick to the agile manifesto’s philosophies
The Agile Manifesto is the best guide to becomming agile and taking your first steps. While the origins of agile are not new, the manifesto represents a set of principles that articulates what agile is today. If you want guidance as to how to apply agility to business projects or products that are not software (and that’s something we’ve done a lot of lately) just assume that ‘working software’ = ‘high-value products’.
2. Get a (Scrum) Coach
There’s a great episode of the Big Bang Theory in which Sheldon Cooper notes that he knows everything there is about swimming — you see, he read a book. Swimming, though, requires you to jump into the water and learn by doing using a qualified teacher.Even great olypmic gold meadalist swimmers, like Ian Thorpe, have a coach to help them become better at swimming.
The analogy is fairly simple, but it suits agile methods. Agile methods are for many people new behaviours to learn. A Coach spends time with their teams, the Product Owner, and the Scrum Master to help them learn the right behaviours that will increase agility and identify and remove behaviours that adversely impact on agility. This independent observer often means the difference between success and failure for new teams learning Scrum for the first time.
3. Don’t just ‘do’ Agile, pick a methodology and stick to it
Scrum is by far the most popular and widespread of the Agile methodologies. It’s a fairly simple process, but that simplicity requires an immense amount of discipline in order to stick to its ‘rule of three’ and achieve results:
- Three roles: Scrum Master, Product Owner and Team. There is no role of BA, or tester, or designer, but there certainly are tasks the whole team have to do in order to analyse, design, code and test their products
- Three products: Sprint planning, daily scrum (stand-up meetings), and sprint review.
- Three artefacts: Product backlog, sprint backlog and the burn-down chart.
If you want to become Agile by using Scrum, these are mandatory requirements. If you’re not using these then you’re not doing Scrum. Some would even suggest that as a result you’re not agile.
4. Be iterative, but not at the cost of delivery
I’ve seen many teams who iterate their concepts rather than deliver whole, completed and tested products at the end of the Sprint. The Agile Manifesto, though, reminds us to focus on working product at the end of each Sprint. Ensure that a product is delivered, in totality, and meets the Product Owners acceptance criteria (ie: Definition of Done), and then leave the Product Owner to decide on whether he wants something else in that Product before the next iteration occurs in the next Sprint.
Conclusions
Seems everyone is getting on the Agile bandwagon and for good reasons — Scrum in particular (my favourite methodology) can bring significant savings to an organisation, but it does come at a cost and that’s by unlearning old, traditional project management ways of working and adopting new approaches to work. Only by giving up what has been learned can you reap those rewards.
M
