Hacker News new | past | comments | ask | show | jobs | submit login
Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches (onsaasproducts.wordpress.com)
90 points by jrs235 on Feb 19, 2018 | hide | past | favorite | 36 comments



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.


These are 4 great points. I really like the 2 & 3 about heterogeneous work and resources. No work is just the same in eng and no devs or QA are even the same. Not a widget factory!

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".


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.


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


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.


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.


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/ ( <- also FREE )


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.


> You can see the switch flip in people's eyes as soon as their tasks are up on the board.

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?


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?”


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.


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.


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.


> 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.

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.


> 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/


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.


Kanban is not that bad. It's essentially a prioritized pipeline of things that need to be done. You can do it without standups.


Agreed with mandatory daily standups. Nothing that prevents you from skipping or doing it differently. I always found Kanban to be the more "do whatever works" approach, that might work better for teams that know each other very well.


Am not devoted but was tempted to downvote this. They may be a waste of time depending on project/team size, or they may facilitate communication to avoid folks "going dark."

As always it depends on many factors, so I wouldn't be quick to throw out absolutes.


It was never stated as an absolute. I stated it as "I find that."

There are much more efficient uses of communication when direct communication isn't required:

  - Email
  - Messaging service
  - Backlog queue
Here's the problem with standups and sprint debriefings, etc. They halt all progress to basically read from a computer screen out loud to people who can read it for themselves. Not only that, depending on the size of the team, most people aren't concerned with what I did yesterday and what I'm going to do today. The only benefit is identification of blockers, and that can be more efficiently done in an email.

To me, it's just ritualistic for the sake of ritual.


> find that they are…

No ifs, whens, or buts?

That said, you are preaching to the choir here.


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

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.


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.


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.


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.


>It's always more important to have processes that are clear to everyone so they know what their expectations should be.

FTFY


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.


It sounds entirely reasonable. One way of reading the popularity of Agile is simply that it is a vehicle for non-creators to get their head around dealing with todo lists, testing, documentation and releases. Github is great at all of that.


There are tools to help you with multi repo GitHub issue management. A little bit of a plug but 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.


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.


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...


FYI Kanban isn't a process according to Kanban author David J. Anderson: http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba....


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.


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


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.


"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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: