I know I always advocate for “velocity!” and “Speed of iteration beats quality of iteration” (John Boyd) and “Move fast and break things. If you’re not breaking things you’re not moving fast enough” (Mark Zuckerbeg).  For a startup environment, where the goal is to get to minimum-viable-product (MVP) as quickly as possible, even with bugs and technical debt, then maybe this is ok. But how many of us are really in that kind of environment?  Most of us are actually in mid- to large- sized enterprises with more fickle customers, and sustainment and technical debt are very real concerns.

One common thing I’ve seen with software teams, once they’ve moved from Waterfall to Scrum, is they feel like the natural continuation is to get to Kanban (or Scrum-ban).  After all, it’s even faster! No sprint planning meetings! No retros or reviews! In fact, the only meetings you have are daily 15-minute standups, so that’s awesome! This especially works well with remote distributed teams because you don’t have to deal with the logistics of trying to do an all-hands meeting.

But there are some pitfalls that can come with moving too fast.  It can be very tricky to see why there are negative consequences for these; it can take months or even a year for them to manifest themselves and it requires someone with broad awareness across the organization to see the consequences playing out and how to root causes trace back to these pitfalls.

• Lack of Design Reviews

Sprint Planning Meetings are more than just about estimation, they are about validating your design.  In order to accurately break your work into 4-to-16 hour chunks, you have to decompose the effort, and in order to do that there has to be a clear understanding of the architecture.  Effort estimation, such as Planning Poker, forces the team to talk through the proposed design and creates an automatic peer review event. It also helps ensure that more than one person agrees the design is the correct one to use (thus ensuring the design is indeed a good one), and the lead or architect can be present to ensure the design aligns with the overall strategy.

• Lack of QC

I’ve talked about this in other blog posts, but all that nifty Continuous Integration, Test Driven Development, Automated Unit Testing, and so forth, only works if the developers are actually doing all those things.  If you are left completely to your own devices, it becomes too easy to get into a zone where you are just writing features and fixing bugs and not doing all the other housekeeping to keep your codebase integrated into the pipeline. By having Sprint Reviews, it forces you to ensure those other tasks are done because you have to show that work to everyone else.

• Lack of communication and understanding

Even though people like to be left completely alone, internal team communications is really important.  Too frequently I’ve seen that everyone is working hard, but then they come together three weeks later and none of their work integrates.  One person didn’t publish their REST API, so the person writing the consumer just designed their own way of POSTing the data, and now neither of those line up so all that code has to be rewritten.

A common complaint I also hear from developers is that they are not getting good prioritization and direction.  (Yet at the same time they want to work from home and never speak to anyone.) By presenting your sprint-long workplan, which includes a detailed design of the features and bugs you’ll be working on, the lead or architect can be there to provide feedback and validation that you have the right prioritization and your efforts are going in the right direction.  Otherwise, all that work you’re doing might just end up sitting on the shelf, or even being thrown away or redone.

• Complacency

Many developers and engineers I’ve met, if they had their way, would be left completely alone and never have to explain what they are doing to anyone, and never have anyone tell them what to do.  I’ve literally been told, if I just left someone alone then greatness would just flow out of them into the organization and things would be just fine.

I don’t understand why people don’t like meetings.  The gamification of effort estimation, plus the camaraderie and creativity of working together at the whiteboard to design something, can be fairly enjoyable if you just let it.  You are allowed to have fun at work, you know. I think that there are some people that feel like they have to hate meetings, and refuse to admit they could be fun.

There’s also another common trap where a developer feels if they are not at a keyboard writing code, then they are not making forward progress.  This is what’s dangerous; the belief that the only possible way to get forward momentum is to be typing things into a computer. As we’ve discussed above, there are other things that are just as important as getting some specific module or app working.  You can have the best, most awesomest app in the universe, but if there’s no rollout plan, maintenance and support plan (which might just be some basic architecture drawings), or alignment with vision, then the app is basically some amazing thing sitting in a closet that’s never used.

Kanban/Scrum-ban might work for efforts that are more Ops or Maintenance based, where things like the design, architecture, and vision are already well-understood.  But for a two-pizza team (5-7 people) working on a new product or service, having those Planning and Review meetings can ensure that some of these long-term issues don’t appear.  Although it will seem like you’re going slower at first, over the life of the project it will actually be faster because there will be less rework and your MVP can be reached more quickly.