Waterfall, Agile, now “Sim”?

Dan Woods in Forbes (here) highlights one of the emerging trends in development: user-interface simulation.  This takes agile development a step further, because…

[b]y creating a simulation of the user experience, instead of a full-working version, a team can avoid a large amount of work but still get a full test that can confirm requirements. Simulation accelerates the agile cycle by lowering the cost of each iteration and improving the quality of the feedback. At the end of several simulation iterations, designers have a rock-solid sense of what is needed.

Simulation also provides a better way to test the quality of business processes because it improves on the typical flow diagrams that only sophisticated users can understand.

iRise is the vendor that Woods mentions and that I’ve heard of (here).  They have a SAP-oriented solution (here), but I can’t vouch for it yet.

Also, because this piece is in Forbes, I’ll bet that smart c-level folks will soon be asking their PMOs about whether they are incorporating this approach into their methodologies.  Time to crack the “sim” books!

PM Quote of the Day — Tacitus

All enterprises that are entered into with indiscreet zeal may be pursued with great vigor at first, but are sure to collapse in the end.

Keep this quote in mind when trying agile or iterative development for the first time. There’s a great temptation to be all “gung-ho” during the first sprints of one’s first projects. But agile puts more of a premium on consistent, repeatable execution than one might first imagine.

Because the idea is to go through repeated iterations, agile approaches can burn out teams if a team starts with and tries to sustain a “heroic” pace. Select and work your sprint backlog judiciously!

Planning and flexibility aren’t mutually exclusive

Excellent post by Craig (here) which gets to the way we need to be thinking about our projects and programs these days.  Our methodological ideologies can get in the way of using the appropriate approach for what we’re building, implementing, or upgrading. 

What is presented as an either/or choice, isn’t.  The answer is “both”.  A plan is not “that which is carved in stone just after the project is chartered” (and shall not be deviated from save for acts of one God as one understands God).  And agile isn’t “doing whatever the heck we think should be done as quickly as possible” (and the product owner be damned). 

The post comes with some great comments as well. 

Finally, nice graph.  I would go with “rigid” vs. “stubborn”.

Good testers = crap code?

Fascinating phenomenon noted by Kevin Rutherford at Silk and Spinach (post here).  As he notes in his original post (here), a good tester (or testing team) can tempt developers to outsource all quality management to the testers.

However, because this is described as an “agile” project, I’m curious: What flavor of agile was used?   It sounds like that the “bad code” developers were throwing code over the wall to their tester, which seems like a parody of a waterfall life-cycle. 

The lack of details leads me to wonder how well the poorer-performing team was organized and led.  Per Kevin Schlabach’s comment, I’d expect that testers would be in the sprint team already.  That sounds like pretty standard practice.  I wonder about the team dynamics as well.  Lots of questions on that point:

  1. Where there interpersonal issues?
  2. How short were the effective iterations?  In other words, did the poorer-performing team behave more like a waterfall team, waiting until the last possible moment to turn over code (or did the tester only accept code at that last possible moment)?
  3. Implied in Kevin S’s comment are questions about the relative strengths of the sprint/iteration teams.  If the business team was working closely w/ developers, how did the tester end up testing so much crap code?
%d bloggers like this: