Often we work harder in Scrum teams, but not necessarily smarter. Therefore the way we work has to change. Five tips for more effective agile work.
As a technical Scrum Master and technical Agile Coach, I travel a lot with teams and accompany them on their adventures. The adventure consists of regular deliveries of valuable software for effective product development.
Regular delivery is the thought that comes from the DevOps Movement (Are we building fast enough?) and effective finding the right product is the value-driven thought (Are we building the right thing?). Where the right product means that the product improves the end user's world. That means the user can work faster, do a task differently or do something that was not possible before (one could almost think of innovation).
Do you know what is effective in agile?
What I can often observe is that teams work in mini-waterfall mode.
That means in a Scrum Sprint they work in four or five phases.
It looks something like this:
The problem with this is that it only makes us work harder, but not smarter.
This means that we haven't changed anything in the way we work, except that we might be bringing smaller pieces into production (which is a good progress). But it takes more than that to realize the advantages of agile software development. It needs a different approach.
Let's focus on "testing". This means that teams talk about "testing" (the role) and "testing" as a phase or task.
This looks like this:
Do you see the connection to the waterfall approach?
And do you see the problem that usually arises then?
In my experience, that's what usually happens:
- "Ahh... we're not quite done with development yet."
- "Can you hold off on testing?"
- "Can't you just test in the next Sprint while we're still working?"
→. This should be the warning bell ringing by now.
That's usually what it looks like as a visualization:
This means that the time for testing will be too short. Too little, done later, or tested in large batches (a lot at once), and that leads to blame, long test nights, late integration, bimonthly deployments, and general frustration.
So how do we get that out?
How to get from waterfall to 1 week Sprints
What works well in my experience is the following sequence (perhaps one could also say progression in the team):
1 We focus on 1-piece flow
This is a thought from the Lean philosophy, where we finish a small job and only then get the next job.
2 We build in quality from the start
Only high quality allows us to become faster over time, and we use this approach for long-term development.
3 We automate a lot of tests
... and can focus us as humans on the exciting manual exploratory tests. Humans are bad automatons. Machines are much better at checking out boring automated things.
4 We work test-driven
A red test from the outside perspective tells us that we need to add or rebuild a feature. We use tests as an indicator for: There's work to be done.
5 We help build the best system
... through early communication with questions and focus on quality. The team now has more time to communicate with the outside world and to challenge, model and validate ideas, hypotheses and requirements. The outside world consists of the "stakeholders": users, managers and other involved parties.
I have explained this in details in this video: How Testing is Different in an Agile Project https://www.youtube.com/watch?v=xdak981_v3g
If you work as shown in points 1 to 5, it typically looks like this:
How to rethink that:
- Testing is an activity.
- Testing takes place all the time.
What you have to do differently:
- Our automated testing is what drives development.
- Our automated tests drive the architecture.
- All green testing means "we're done"
Or sign up for the next Professional Scrum Developer ("PSD"), then we can learn how to do it.
Not convinced yet?
Here you can find a video in English from the training in February: What's the best thing in this Scrum Developer Training?
Peter