A rifle instructor knows how dangerous a rifle is and makes sure every one of his riflemen keep their guns pointing down range rather than at each other. Any great team will have an enormous supply of competitive energy, and much like a rifle, this competitive energy can be dangerous to the team if it’s pointed inward.
A key role of a leader is to harness all that hyper-competitive energy and point it down range. A leader needs to make sure competition doesn’t turn inward and become self-destructive, devolving into political infighting. A leader gives his team someone or something outside of the team to focus on and target with their attack energies. A great leader rallies his troops against either a common enemy outside of the organization such as the company’s competitors or on an opportunity for fame and fortune. Team meetings are not about how the team sucks but about how the team can build it’s strength to beat a common enemy and attain glorious victory.
Jeff Cohen has a nice comparison of Kanban vs Scrum. In a nutshell, Kanban emphasizes pull- instead of push-based queues which, among other benefits, is better at handling non-brick-laying development (i.e. new tools, new languages, new problems) where time estimates are hard to judge. From Jeff Cohen:
Goal/Theme: Maximize flow through your development department by introducing the concept of limits.
Can work alongside scrum in terms of requirements mangement; but replaces the predictive, timeboxed, pushed-work sprint system with a series of small work queues from which all team members “pull” tasks whenever they’re ready for new work. Velocity is still a measurement of how many features/bugs/tickets that can flow from the starting queue to the final queue in a given week or month.
Kanban does not prescribe any meetings; the ability of the team to figure out their own communication style is assumed. Many teams adopt the estimation and prioritization concepts from scrum to manage the requirements and decide what goes into the kanban queues. Search google for “scrumban” to get a variety of opinions on this.
+ drives progress within a team or across multiple teams equally well
+ the notion of limited work queues tend to improve focus and remove excessive context-switching
+ no sprint predictions: team members pull new work whenever they’re ready for more
+ deployment/release management not a special step, but simply another kanban queue
+ features can be released can occur in step with, or out-of-band of, ongoing development
+ engineers can work on short tasks, or long-running tasks, without the limited timebox of a scrum sprint
- no prescription for how to manage requirements
- no opinion on management technique; many kanban teams choose a simplified version of scrum
- some people think it’s “scrum without sprints,” but that underestimates the subtle but important difference between pull* – vs. push-based work scheduling
The article also compares the other methodologies such as Waterfall, XP, and everyone’s favorite: Chaos.