In this series I want to write about Agile, Scrum, Lean and DevOps. Like it is the case with many buzzwords, they are used often and sometimes only understood shallowly without consideration to the initial intent. I'll start with a relatively short definition of each of the terms and later on try to explain how I think they mesh together. Let's start with Agile.
Agile
Agile has its roots in a dissatisfaction with the way software is/was developed. One of the ways to develop software is the Waterfall model. In a nutshell, and a bit hyperbolic, with the waterfall model you do a lot of upfront work (requirements engineering, system design, ...), work for years on the implementation, present the result of your hard work to the users, and they say "that's not what I wanted/imagined", or "huh, our requirements have actually changed, we don't need this anymore", ... .
To be clear, the Waterfall model is not all bad and definitely has its use cases.
To improve on the way we develop Software, some developers got together to find better ways to develop software.
Some of you might object to the phrasing "some developers" as many of them are quite famous - at least as far as software developers can become famous. Some notable mentions are:
- Kent Beck, also known for Extreme Programming (XP) and refactoring
- Robert C. Martin aka "Uncle Bob", Clean Code Uncle Bob is actually so synonymous with Clean Code that Wikipedia directly redirects Clean Code to his profile if not instructed otherwise.
- Martin Fowler, Refactoring and OOAD
- Alistair Cockburn, Hexagonal Architecture
The result of this retreat was the "Manifesto for Agile Software Development", which states the following.
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:"
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
And behind this manifesto stand twelve principles. Some of these principles are:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Go read them all (mandatory reading 😉): Principles behind the Agile Manifesto
It's always good to have principles, but what do we actually do with them? That's where Scrum enters the stage.
Scrum
Wikipedia defines Scrum as follows:
"Scrum is a framework for project management with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies."
I like to think of Scrum simply as a blueprint on how to implement the Agile Manifesto. I'll explain in a minute, but first some Scrum basics/terminology.
- A sprint is a time box in which we work on our next product increment. A sprint is usually one to four weeks long.
- A Scrum team consists of all the people that work on our next product increment. The team is multidisciplinary, and the following roles are represented:
- Product Owner (represents the stakeholders, maximizes the value the team delivers by prioritizing work)
- Developers (do the work 😉)
- Scrum Master (coaches the team, removes impediments that prevent the team from delivering their product increment)
Scrum explicitly specifies these as roles and not positions. Every member of the team can temporarily take on other roles. E.g. a developer could have a new feature idea or remove an impediment by automating a tedious manual task.
- All the work of the Scrum team is gathered in a Backlog. You can think of this a list of user stories and bugs. The product owner prioritizes the work by juxtaposing the expected business value with the estimated effort to implement the work.
With that out of the way, let's see how Scrum helps us implement the Agile Manifesto.
One of the principles of the Agile Manifesto states:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Scrum suggests we do the following to implement this principle:
- at the end of every sprint, the Scrum team gathers in a meeting called the Sprint Retrospective. There, the team discusses what went well in the sprint and what can be improved in the next sprint(s).
- every day the Scrum team meets for a short meeting called the Daily Scrum. Every team member answers the following three questions: "What have I done since the last daily Scrum?", "What do I intend to do next?" and "What impedes my progress?"
Test Driven Design/Development (TDD)
This is not Scrum related, but there's another neat even shorter improvement cycle (Sprint: Sprint Retrospective, Day: Daily Scrum) when you employ TDD. Where you write a failing test first (red), make it run successfully (green) and then try to figure out if you can improve on your implementation (refactor).
I chose this principle because, for me it's the core tenant of the entire thing: Do, Inspect, Adapt. It's also the first sentence of the Agile Manifesto:
"We are uncovering better ways of developing software by doing it and helping others do it."
But there are other examples, like:
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
and
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
For these two, Scrum recommends to work in Sprints of one to four weeks - with a preference to the shorter timescale. Additionally, we should have a potentially shippable product increment at the end of every Sprint. This benefits the user as the software can already partially support his workflow (instead of entirely after several months with the Waterfall model). It also benefits the product owner, and the developers because they get feedback earlier.
Another term that is often associated with Scrum is MVP (Minimum Viable Product). What is the smallest product increment we can implement that is of value to the users? This question allows us to help make work smaller/fit into a sprint more easily and therefore allows us to deliver value more often.
There are a some additional things that Scrum brings to the table, like Planning Poker during Sprint Planning, Kanban, ... but for now this is enough to get a basic grasp on Agile and Scrum.
Summary
- Agile wants to improve the way we develop software, by delivering value to the customer more often and reacting to changing requirements.
- Scrum helps us with suggestions and "rules" to be more agile. Scrum is more than Daily Scrum and Planning Poker - it's a mindset.
Agile and Scrum build a pair, kind of intention and a way to implement it. In the next post in this series we'll look at, spoiler, the next pair.
Something missing? Awesome, leave me a comment.
Keep on struggling.
Oldest comments (0)