I thought I’d write up my thoughts on the various organizational processes I’ve been subjected to over the years. I’m currently on the Kanban wagon but I haven’t completely figured it out yet.

I would put some links to each of these, but I’m too lazy. Use google to follow up on whatever piques your interest. Or link up your favorite site in the comments.

These are just my opinions – everyone has different experiences, and I’m not trying to make any absolute proclamations here. The pluses and minuses are based on my experience only. Feedback welcome.

Chaos

Goal/Theme: Pay the rent.

• - you have no defined process
• - activities that would be recognized as common, seem to be performed differently each time around
• - missing deadlines
• - lots of overtime

Waterfall

Goal/Theme: Be able to plan ahead.

• + learn how to write requirements
• + learn how to manage code in a team environment
• + learn how to identify dependencies
• + learn how to plan for a milestone
• + good for entry-level engineers
• - deadlines too far in the future
• - cost of change increases with time
• - requirements changes cause big rewrites
• - requirements always change before release
• - testing occurs toward the end when cost of change is high
• - lots of overtime
• - experienced engineers will be frustrated by having to wait to see results

Extreme Programming

Goal/Theme: Iterative development, iterative releases.

• + focus on small, achievable increments of value
• + cost of change stays fairly constant
• + focus on better engineering practices
• + learn the value of automated tests
• + get closer to your customer
• + requires engineers to hone their skills
• + engineers are accountable on a daily basis (green bar gate)
• - does not address how to track overall team progress
• - does not manage requirements
• - does not identify or seek to manage dependencies

Scrum

Goal/Theme: Manage incremental progress toward a long-term goal.

• + mutual sense of control: business controls priorities, engineers get sustainable pace
• + works best with engineers practicing xp
• + The quantity of work pushed into a sprint should become easier to judge
• + daily stand encourages communication
• + team relies on daily stand to identify when team members are blocked
• - sprint might become overloaded or underloaded, since initial load is based on estimates given at start of sprint
• - user stories must fit into a sprint
• - religious wars arise over how to estimate (days vs. points vs. poker chips vs. ?)
• - signigicant ceremony; time spent in meetings can become a significant percentage of the sprint
• - best for teams with four or more engineers
• - best for colocated teams with face-to-face interaction (though remote teams are certainly doable)
• - best for teams that have one product to develop and support
• - engineers tend to get praised or criticized based on their scrum velocity, which is a horrible measure of engineering productivity

Kanban

Goal/Theme: Maximize flow through your development department by introducing the concept of limits.

NOTES:

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