Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches
onsaasproducts.wordpress.com
onsaasproducts.wordpress.com
1. Ratcheting workload
Your sprint commitments are based on average past velocity. Because it is an average, half of the time, you take too much, and half the time you take too little. But no one likes schedules that are finished only 50% of the time, so teams push to reach commitments. Thus measured velocity is naturally much more prone to increasing than decreasing.
2. Heterogeneous work
Scrum was created by engineers. Scrum treats each story as pre-dev, in-dev, or post-dev, and only estimates and plans the in-dev work. In the real-world, engineering is not the only work (or even most of the work!). Requirements, product design, UX detailing, quality assurance, marketing, and sales are no less of a feature than its engineering. "Okay," you say, "include these aspects in the scrum estimation too". But....
3. Heterogeneous resources
Each story has a different composition of types of work needed. And each of these types requires a specialized skill set. Your blanket cover-all estimate will wind up with engineering-heavy, or UX-heavy, or QA-heavy sprints.
I would no sooner have an engineer market a product as a I would have a marketer engineer a product. But that's what scrum sprint estimates seem to imply.
4. Uneven cadance
On the first day of the sprint, all devs are starting stories. On the last day of the sprint, all devs are ending stories. This causes uneven sense of cadence (I need to get this in), uneven needs (lots of QA, now!), and unnecessary contention (everybody merging, conflicts, breakage).
---
To sum it up: At the end of the day, pipelines are simply a more accurate domain model.
I do think that scrum and sprints are worth the bother if you have to ship the product externally on a timeline. I've worked on client contract projects where it worked well as you could give a release over to a client "on time".
Some teams will want to do scrum, some will want to do kanban, some will mix and match. Some of my teams have wanted a heavy process with actual planning poker cards, others just want a few standups and a simple retro.
The important thing is to communicate the needs of the other teams they'll be working with, and not demand the methods. Team boundaries are in many ways like API boundaries -- as long as you implement the interface, who cares how you go about doing it. (As long as it isn't needlessly wasteful.)
I'm happy to offer past experiences and ideas when teams get wedged, but in general I've found everyone is happier and more keyed in when they've built the process we're all going to be working by.
In standup we have the board on a large screen and filter through by person. The difference is night and day. Standups have gone from vague "uh yeah I'm working on some 1.2 features" to snappy, concise updates that help focus the person on their daily tasks. You can see the switch flip in people's eyes as soon as their tasks are up on the board.
Project Management has essentially been reduced to prioritizing new tasks into the pipeline. It's wonderful.
[1]: I don't actually know if this is true, but my point is it's way overkill for small projects.
Does that mean people are tuned out when it's their team members' tasks on the board? And if so, is the stand-up still useful?
The converse is also true though. A lot of things will get resistance because people don't like to change, or they'd rather not leave their desk and talk to other people, or they only want to optimize for their personal productivity without considering the productivity of the team as a whole. That last one in particular is the source of a lot of friction with developers in my experience. Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer.
So as long as you're being mindful of your practices, what you're doing and why you're doing it, and looking to constantly improve the output of the team as a whole then feel free to adopt what makes sense and discard what doesn't work, and ignore anyone trying to sell you on dogma that they barely understand themselves.
This makes a lot of things click into place for me. I've consistently seen it be a struggle for people to buy into the activities that may not immediately make things easier for the individual, but are necessary for the team, myself included. Stating it this way cuts right to the essence of why those activities are vital.
Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense?
More of my views here https://leanpub.com/agileforleads/
We started out differently than most teams, where we began with a very loose process and tightened it over time (as opposed to many who start out very rigidly and let them slack over time) and this has led to us:
1. Predicting with surprisingly good accuracy (within 10% usually) how much work we can get done
2. Spending only ~3 hours a week doing "rituals" (we do our stand ups in HipChat and we have two backlog grooming sessions a week; every other week we spend an hour for review/retro and an hour for planning), which gives us an overhead of ~8% time "wasted" doing our planning
3. onboarding new members in only a couple of weeks; we plan so that they always join mid-sprint so that they get a solid week to just read up on our code and observe our process before jumping in for their first planning
4. creating a really cross-functional "everyone works on everything" team; for my part, I spend most of my day in the weeds of Kubernetes for a variety of projects, but I'm able to cross-train on the other components my team works on, and I'm slowly teaching all of them K8s.
I won't call it "agile" because it's a dirty word apparently, but I really like it now that we've spent a few months hammering out the kinks.
As always it depends on many factors, so I wouldn't be quick to throw out absolutes.
There are much more efficient uses of communication when direct communication isn't required:
- Email
- Messaging service
- Backlog queue
To me, it's just ritualistic for the sake of ritual.
No ifs, whens, or buts?
That said, you are preaching to the choir here.
https://www.scrum.org/resources/commitment-vs-forecast
I totally agree that Kanban is much better for SaaS development, but that small change corrects Scrum's biggest issue.
If you have a small team, kanban is really great. It's easy to communicate what goals are; everyone's pretty aware of what is going on, development-wise, company-wise. You just need a good workflow, and that is what kanban is.
I like scrum more when you have a larger development team, because it's much harder to communicate what goals there are. People are less aware of what's going on in the platform, in the company, etc. The start and stop points in scrum are great times to reconnect and allow that communication to happen.
But, there are lots of contexts, and lots of ways to solve communication problems, so it's really difficult for me to tell you what you should or shouldn't be using. It's almost more important to just have a process that is clear to everyone so they know what their expectations should be.
Having worked both scrum and kanban, I feel kanban is better for both large and small teams, so long as the team puts some thought into which items each person takes out of the backlog.
People joke that nobody actually follows "Scrum" or "Kanban"; it's interpreted differently everywhere. I personally think that's a good thing, if it is done so in a directed fashion. (E.g.—don't estimate hours if that's not a useful thing to do for your team.)
Kanban and Scrum are themselves starting points, and perhaps a statement of where you align philosophically; in the end you are either using an agile process, where you kept what was useful or added what was needed, or you are in a muddle, where inefficient processes have crept in that are frustrating to the team.
FTFY
It would be awesome is if GitHub would allow us to set milestones across repos. Then we don’t really need anything else.
With open source, it can be frustrating when other loosely coupled teams and silos have a dependency for a release, but their overall issue-tracking process is mostly an abandoned in place mock-up or fiction. If their repo is included in our board, their issues show up as noise across the whole pipeline. You start remembering to ignore certain issues that you know don't reflect reality, then ignoring everything for certain assignees or reporters, and eventually decide to toggle off their repo from your board view.
Although I love Kanban this article is only half right. Scrum and Kanban solve two different problems and you might encounter either when developing SaaS. Let's get down to first principles.
Scrum is a batch oriented process. Batch processes are useful when the outcome of a process is uncertain and requires inspection and reconfiguration of the inputs after each batch until a stable and predictable process can be produced and the variables understood.
Kanban is a throughput oriented process. It is useful for reducing waste and optimizing for consistent and high output in a process where the inputs are already well understood and the output is of a more consistent quality.
You can then imagine how at the start of things when you aren't sure how everyone is going to work together well, or when you introduce a new paradigm or technology to the mix, Scrum might make sense.
You can also see how a long running SaaS endeavor with incremental upgrades, no major changes to staff or technology, could use Kanban to increase throughput and reduce waste.
For more information please see the fantastic "Process Dynamics, Modeling, and Control"[0] who's author was consulted, ironically, in the very first Scrum book from Beedle and Schwaber.
The lack of science and first principles in the Agile space is why people say "agile is dead" and Agile coaches are treated like hacks.
This is my plea for more science and rational thought.
0: https://www.amazon.com/Process-Dynamics-Modeling-Babatunde-O...
Also, David can split hairs all he wants about this (as agilists love to do) but the process theory around this stuff was laid down long before he graduated high school.
This lack of ceremony sounds very refreshing.