Waterfall, Scrum, and Kanban, Oh My

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

Waterfall, Scrum, and Kanban, Oh My

        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.


<h2>Chaos</h2>


Goal/Theme: Pay the rent.


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


<h2>Waterfall</h2>


Goal/Theme: Be able to plan ahead.


<ul>
<li>+ learn how to write requirements</li>
    <li>+ learn how to manage code <div class="post-limited-image"><img src="http://feeds.feedburner.com/~ff/SoftiesOnRails?i=br3U-L9DiBw:xeUgyHjELzs:V_sGLiPBpWU" border="0"></div>

Continue reading “Waterfall, Scrum, and Kanban, Oh My”

Ruby Job Opening

I’ve got a Ruby Software Engineering position open on my team at Leapfrog Online, in Evanston, IL.

The ideal Rails candidate has:

  • Real-world experience using MVC frameworks to build high-traffic web sites and applications. While we don’t expect any graphic design skills from our developers, candidates should be well-versed in the world of HTML, CSS and Javascript/Ajax. Knowing how to develop RESTful applications is a big plus.
  • A love of testing and test-driven development. You should know how to write standard Rails unit tests, and/or a popular specification framework like RSpec, shoulda, Cucumber, etc.
  • Real-world experience with Agile engineering practices (test-driven development, object-oriented design, refactoring, DRY, YAGNI)
  • Thorough understanding of common web and e-commerce concepts and technologies, such as: HTTP, SSL, XML and associated technologies, background job processing, message queues, content management concepts, public-key cryptography, application and data security and privacy issues, basic TCP/IP networking. Experience producing and consuming web services (SOAP, REST, XML-RPC) is a big plus.

Interested? Email me (cohen.jeff@gmail.com) or find me on twitter (@jeffcohen).

Ruby Job Opening

        I’ve got a Ruby Software Engineering position open on my team at Leapfrog Online, in Evanston, IL.


The ideal Rails candidate has:


<ul>
<li>Real-world experience using <span class="caps">MVC</span> frameworks to build high-traffic web sites and applications. While we don’t expect any graphic design skills from our developers, candidates should be well-versed in the world of <span class="caps">HTML</span>, CSS and Javascript/Ajax.  Knowing how to develop RESTful applications is a big plus.</li>
</ul>


<ul>
<li>A love of testing and test-driven development.  You should know how to write standard Rails unit tests, and/or a popular specification framework like RSpec, shoulda, Cucumber, etc.</li>
</ul>


<ul>
<li>Real-world experience with Agile engineering practices (test-driven development, object-oriented design, refactoring, <span class="caps">DRY</span>, YAGNI)</li>
</ul>


<ul>
<li>Thorough understanding of common web and e-commerce concepts and technologies, such as: <span class="caps">HTTP</span>, SSL, <span class="caps">XML</span> and associated technologies, background job processing, message queues, content management concepts, public-key cryptography, application and data security and privacy issues, basic <span class="caps">TCP</span>/IP networking.  Experience <div class="post-limited-image"><img src="http://feeds.feedburner.com/~ff/SoftiesOnRails?i=6tp9NlnZDWw:EEuX-8kckgU:V_sGLiPBpWU" border="0"></div>

Continue reading “Ruby Job Opening”

Last Call for Rails for Everyone

Technically the registration window has closed, but if you sign up this week we’ll let you in.

Register now.

Last Call for Rails for Everyone

        Technically the registration window has closed, but if you sign up this week we’ll let you in.


<a href="http://purpleworkshops.com/workshops/rails-for-everyone">Register now.</a>
      <div class="feedflare">