
Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches - jrs235
https://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/
======
paulddraper
Issues I've seen with scrum

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.

~~~
TheCoelacanth
Would you really have all of these "Requirements, product design, UX
detailing, quality assurance, marketing, and sales" done by the same team?
That is what your point two seems to imply and I have never seen teams
structured like that before.

~~~
paulddraper
Agile teams are supposed to be "cross-functional", meaning they can define,
build, test, and operate.

~~~
TheCoelacanth
Cross-functional doesn't mean that the entire world is part of your team.
Sales and marketing are stake-holders that work with the Product Owner to
define a Product Backlog. They are not part of the Development Team.

------
Pfhreak
One of the best lessons I've learned as an engineer manager (and former
engineer) is to let the engineers drive the process.

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.

~~~
cottsak
Agree with letting the team choose and adapt it over time. Seems to correlate
with my experiences and insights that I've cataloged here
[https://leanpub.com/agileforleads/](https://leanpub.com/agileforleads/) ( <\-
also FREE )

------
hnzix
Adding a JIRA Kanban board has hugely improved my team's daily standups.
Workflow goes: Backlog ⮕ Prioritized Backlog ⮕ Doing ⮕ Ready For QA ⮕ Doing QA
⮕ Ready For Release ⮕ Done, and there's a quick filter for each team member
that will show only their tasks, as well as a major release filter.

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.

~~~
SlowRobotAhead
I’ve got a similar setup in Trello that’s really just for me and a couple
other people. I’ll have to look into JIRA, but I have a little bit of “what
did I do before this?”

~~~
nameless912
JIRA's query language is Turing complete[1], don't bother if you don't need an
unrealistically huge amount of power over your data.

[1]: I don't actually know if this is true, but my point is it's way overkill
for small projects.

------
Clubber
I'm sure this won't be popular with the devoted, but I find Scrum, Kanban and
daily stand-ups a huge waste of time. It's funny how rigid agile becomes when
you can make a lot of money making it rigid through consulting dollars.

~~~
cstejerean
Anything that's rigid is by definition not agile. For every practice it's
important to understand the reason behind it and what it's supposed to
accomplish, and then you can determine if that's something that you care to
accomplish, or if perhaps there is a better way to accomplish it within your
own team.

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.

~~~
cottsak
> Anything that's rigid is by definition not agile.

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/](https://leanpub.com/agileforleads/)

~~~
nameless912
Right, this is my view on agile. The only constant should be re-evaluation.

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.

------
brightball
Scrum fixed one of the biggest issues that came with it when it corrected
loaded wording.

[https://www.scrum.org/resources/commitment-vs-
forecast](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.

------
peterevans
It kinda depends!

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.

~~~
tomelders
I'd argue that Kanban doesn't prevent you from having regular points in which
to communicate. It's just that the work itself isn't bound by those points.

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.

~~~
peterevans
I agree with you that the name itself (kanban) does not preclude one from
having those regular times to get together.

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.

------
rushabh
This may sound crazy but we manage our entire SAAS and open source project
with GitHub Issues. We have monthly milestones and assignments and seems to
work well for our team of 15 devs. Where we are hurting is managing multiple
projects.

It would be awesome is if GitHub would allow us to set milestones across
repos. Then we don’t really need anything else.

~~~
mr_november
There are tools to help you with multi repo GitHub issue management. A little
bit of a plug but [https://codetree.com](https://codetree.com) is built to
solve your exact problem - we sync up milestones (and labels) across many
repos and allow you to visualize and work with cross-repo issues in either
kanban or list view.

~~~
saltcured
Right, we've been using ZenHub's issue board on top of our dozens of GitHub
repos to do something that is Kanban-ish. It works well enough for the teams
that actually want to follow a process.

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.

------
ryanmarsh
Agile coach here.

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...](https://www.amazon.com/Process-Dynamics-Modeling-Babatunde-
Ogunnaike/dp/0195091191)

~~~
richliss
FYI Kanban isn't a process according to Kanban author David J. Anderson:
[http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba...](http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development).

~~~
ryanmarsh
The link didn’t work for me but I can do you one better I have (saved
somewhere) a Yahoo groups conversation where David goes on a tirade about
exactly this.

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.

------
neolander
This should have (2012) at the end of the title.

------
vannevar
Once you're in steady state maintenance/incremental improvement mode, then
sure, kanban is probably the appropriate approach. But for initial product
development, and major new feature releases or product re-writes, scrum with
its measured discipline and time restrictions is better. It's more difficult
to force functionality/schedule tradeoffs with kanban. You simply end up
reinventing scrum by grouping stories and imposing deadlines.

------
krupan
"At no point in the execution of this Issue was it discussed by the team
(neither in a daily stand-up meeting nor in any other meeting). In fact, any
type of a team discussion would have probably doubled the overall time spent
on this Issue."

This lack of ceremony sounds very refreshing.

