What is Agile Workflow? (ELI5)
TL;DR — Agile is a repetitive approach to project delivery. Your team delivers multiple smaller steps from the start, instead of delivering everything at the end.
Wikipedia describes Agile as:
“A set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.”
… what?! To techs that may make sense, but to a laymen, that’s not particularly easy to digest.
Why Agile?
TL;DR — To embrace changing requirements!
Agile processes recognise that humans are naturally bad at planning, and estimating. Don’t feel bad about it! No matter how much practise you get there’s always something lurking that can’t be accounted for.
More traditional approaches such as ‘Waterfall’ dictate total planning, and if it’s not in the plan, it doesn’t get done.
On any project, be it a piece of software, a marketing campaign, or a recruitment strategy, extra scope will appear or requirements will change. Especially on larger projects! This either needs to be disregarded (usually not ideal), or wedged into a tight plan, throwing the plan into disarray. Why plan at all, right?
Wrong! Embrace the uncertainty, and build it into your process. Some of the best ideas don’t emerge until you are up close.
What is Agile?
TL;DR — A set of practises to help you be adaptable, and ensure your team is always working on something important.
“Agile — able to move quickly and easily”
Agile is the process of breaking down a large project into smaller tasks (usually called stories) and prioritising them.
This prioritisation is important and is the essence of agile. Ensuring the team’s focus is on the current sprint, or on the most important deliverable to the business is key to ensuring you meet your business goals. This prevents teams getting lost in a torrent of requirements and requests, and ensures that every story that gets worked on in a given time is important to the progress of the project.
These stories are delivered either continuously, or in short cycles called sprints (Scrum).
How does Agile work?
TL;DR — Requirements > Plan > Do > Review > Repeat
Use your project requirements to make a list of everything that needs to happen. Don’t worry if you forget some things, it can be added to later.
Estimate each item, either by time, or more commonly by story points (arbritrary numbers, based on comparing complexity, relative to each other). Expect this to be somewhat inaccurate. This will give you a rough idea on project duration.
Set some priorities, most important stuff first. This is usually ever evolving, so prioritise quickly and often. In Kanban this frequency is very reactive. Scrum is based on fixed cycles (sprints), generally 2 weeks in length (or whatever suits your project).
Review recent work. If you are crushing everything, increase your sprint workload. If there’s always outstanding items, you are being too ambitious!
Scrum vs Kanban
Real quickly (more detail incoming in another post), these are the 2 main frameworks for Agile. Framework sounds techy, it’s really just a posh way of describing the process and practises that you follow.
Scrum
- Breaks work into chunks called sprints (usually 2 weeks per sprint)
- Plan sprints based on important requirements for that point in time
- Don’t estimate specific time, compare amount / size of work
- Sprint review to see how it went, what could be improved
- Gain feedback on your deliverables
- Daily stand up (super short) meetings, highlight blockers, keep things moving
Kanban
- Weekly meetings
- Continuous flow
- Visualise the process on board / column type layout
- Most important thing first. Constant reflection on this.
- Incremental improvements
Conclusion
Agile is being able to adapt, and being able to put off decisions until you know enough to make them properly.
The highest priority is to satisfy the customer, whether they’re your client, a product owner, your boss, or yourself. Embrace changing requirements, while still getting things done, through early and continuous delivery. This reduces risk, as it prevents delivering the wrong thing, and not realising until you get right to the end!
Thanks for reading the Scrumi.io blog! Make sure you give this post your 👏 50 claps 👏 and take a minute to follow us on here and on Twitter if you enjoyed this post and want to see more.
Note: A lot of the above is generalising, and misses some in depth elements of Agile. That’s fine, there are thousands of lengthy and complex articles discussing Agile practises in great (usually too great) detail. Google is your friend :)
