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.
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.
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.
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.
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.
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...
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.
Another one of these foggy articles.
Wish people would understand pioneer, settler and townplaner.
http://blog.gardeviance.org/2015/03/on-pioneers-settlers-tow...
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.