I'm a developer who is fascinated by the delivery flow in project management systems. I've spent a lot of time thinking about it, and read books like Agile Management for Software Engineering, The Art of Agile Development, Slack, and my personal favorite, The Phoenix Project.
The Phoenix Project has really opened my eyes to the many inefficiencies we face. I'm also really fortunate to have had the opportunity not to just study different delivery methods, but to practice them by managing delivery teams.
For this article I've decided to combine my two passions: software engineering and delivery flow.
In fact, I've ended up building a basic throughput simulator!
What You're Going to Learn
- Eight major inefficiencies that increase wait time
- How the following delivery flows perform in practice:
- Waterfall
- Scrum
- Kanban
- Why everyone should chill out and give each other some slack
- Why wait time is the root of all evil when it comes to efficiency
- That it's all about the team, not the individual, when it comes to delivering software
The 8 Wastes in Software Development
Before we start, it's important that you understand different types of waste in software development.
This list is not comprehensive, and I am sure that someone could write a book on this that runs hundreds of pages long. But this list will give you the main models you need to consider.
1. Transport
These inefficiencies occur when you are moving artefacts around. Perhaps you're submitting code to several branches, or cherry-picking check-ins.
2. Inventory
This is when produced artefacts are not being used.
Artefacts such as:
- Requirements
- Architecture designs
- Graphics and wireframes
- Proof-of-concepts
- Code
... are produced weeks or months upfront. The moment an artefact is produced, it's out of date and needs changing.
3. Motion
These inefficiencies occur during the creation of artefacts.
Most developers need to juggle many tasks at the same time. There's a cost that comes with context switching and multitasking.
Maybe you need to keep track of different software versions, projects and roadmaps. Or people are constantly calling you, or coming over to see you about something.
You need to pick up work that you haven't touched in days, months or years, and you need to relearn what you've already done.
4. Waiting
You're waiting for your check-in to build. Or you are waiting for artefacts to be produced.
Your IT infrastructure is flaky, your computer stops working, the internet goes down, or the email server is not working.
Your testers in the team get back-ended. They're waiting around for work for days, and get it right at the end of the iteration.
You have discovered that you have misunderstood the requirement — now there is more work to do.
Or maybe you're waiting on someone to review your code.
5. Overproduction
You've produced your software, but you're not shipping it. It's sitting on the shelf and nobody is buying it. The work you've produced is no longer needed.
6. Over-processing
This happens when you produce artefacts that weren't requested.
You're polishing your code and adding in extra extension points for those amazing features that'll be built in the future.
You actually working on something that nobody asked for, and you are doing it because it's "cool".
7. Defects
This occurs when your artefacts have errors in them.
What you have produced doesn't meet the agreed acceptance criteria. Or maybe what it doesn't meet the technical standards (performance, security, maintainability).
8. Skills
This occurs when the producer of the artefacts is being under-utilized.
Perhaps you have not been given adequate training to do the actual job. Or you can do much more complicated work... but it's not being given to you.
What Is Slack?
Yes, it's a messaging app — but in this case, I'm talking about an influential book called "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency." It's 209 pages long — I'm not going to do it justice, but here's a summary:
In order for your teams to be happier, less burnt out, more innovative, and for your organisation to respond better to change, you should add "free time" to your delivery process.
When you plan your iteration, you just add 10%, 20% or whatever percentage of time you decide for innovation.
Our simulation is going to put this theory to the test, and see if it improves delivery rate.
The Simulation
I've created a set of simulations for three project management methodologies. You'll see them below, as well as a chart that will compare the throughput speed of each delivery approach.
Continue reading %We Simulated Waterfall, Kanban & Scrum. Which Works Best?%
by Zan Kavtaskin via SitePoint
No comments:
Post a Comment