7 ms·

Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches

90 points by jrs235 9y ago

neolander 9y ago
This should have (2012) at the end of the title.
peterevans 9y ago
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 9y ago
  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 9y ago
    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.
- djglass 9y ago
  >It's always more important to have processes that are clear to everyone so they know what their expectations should be. FTFY
hnzix 9y ago
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 9y ago
  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 9y ago
    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.
- Vinnl 9y ago
  > 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?
krupan 9y ago
"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.
Clubber 9y ago
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.
- maxxxxx 9y ago
  Kanban is not that bad. It's essentially a prioritized pipeline of things that need to be done. You can do it without standups.
  - 0xFFFF0000 9y ago
    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.
- cstejerean 9y ago
  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.
  - GVIrish 9y ago
paulddraper 9y ago
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.
- cakeface 9y ago
  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".
- TheCoelacanth 9y ago
  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.
brightball 9y ago
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.
rushabh 9y ago
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 9y ago
  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 9y ago
    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.
- fergie 9y ago
  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.
Pfhreak 9y ago
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 9y ago
  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 )
TheLostOne 9y ago
Another one of these foggy articles. Wish people would understand pioneer, settler and townplaner. http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html http://blog.gardeviance.org/2015/03/on-pioneers-settlers-tow...
ryanmarsh 9y ago
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-Ogunnaike/dp/0195091191 https://www.amazon.com/Process-Dynamics-Modeling-Babatunde-O...
- richliss 9y ago
  FYI Kanban isn't a process according to Kanban author David J. Anderson: http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba....
  - ryanmarsh 9y ago
    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.
vannevar 9y ago
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.

90 points by jrs235 9y ago

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

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 9y ago
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 9y ago
  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.
djglass 9y ago
>It's always more important to have processes that are clear to everyone so they know what their expectations should be. FTFY

hnzix 9y ago

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 9y ago
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 9y ago
  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.
Vinnl 9y ago
> 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?

krupan 9y ago

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

Clubber 9y ago

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.

maxxxxx 9y ago
Kanban is not that bad. It's essentially a prioritized pipeline of things that need to be done. You can do it without standups.
- 0xFFFF0000 9y ago
  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.
cstejerean 9y ago
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.
- GVIrish 9y ago

paulddraper 9y ago

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.

cakeface 9y ago
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".
TheCoelacanth 9y ago
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.

brightball 9y ago

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.

rushabh 9y ago

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 9y ago
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 9y ago
  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.
fergie 9y ago
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.

Pfhreak 9y ago

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 9y ago
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 )

TheLostOne 9y ago

Another one of these foggy articles. Wish people would understand pioneer, settler and townplaner. http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html http://blog.gardeviance.org/2015/03/on-pioneers-settlers-tow...

ryanmarsh 9y ago

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

richliss 9y ago
FYI Kanban isn't a process according to Kanban author David J. Anderson: http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba....
- ryanmarsh 9y ago
  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.

vannevar 9y ago

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.