Blog

Iterations, truly defined, are ‘idea to successful deployment’.  This concept will apply at various levels.  An overall application of the iterative process is a high level start to finish accomplishment.  Business has an idea of how things can work.  Requirements are gathered… communicated.  Work is done and deployed to QA, UAT.  Deployed to production and verified.. Voila, we have an iteration.  Anything that disrupts that smooth process (lol) decreases velocity.  Whether it is management, communication, watched pots, personal grudges.. you name it.

On a different level, an iteration can be defined at more of a micro level… micro-iterations.  A developer gets a requirement, makes changes, tests (hopefully, maybe… well it compiles anyway) sends it to the QA team… it comes back.   Maybe the developer didn’t have the right requirements, maybe bad testing, maybe changes in requirements, maybe the inability to test because of lack of a good test environment.  Whatever the reason, we are back to square 1.05.   Here are a few suggestions of how to increase this velocity…

1. Set up a good test environment with reasonably comprehensive data.
2. If release to QA environment is laborious, as it often is, developer can communicate and demonstrate results to QA with a simple 5 minute screen-share.
3. Emphasize developer testing… require screen shots of results on tickets.

More coming…

Years ago, I helped coach a track team.  I got USATF certified and everything… One thing I noticed is the velocity is a product of stride and turnover.  Bear with me on this one.  In other words, if you run 165 steps a minute, and if you have a a stride of 6.5 feet, you will run 5280 feet (a mile) in 4:55.38462.  ((5280/6.5)/165)  If you intend to run a sub 4 minute mile, you must either lengthen your stride, or increase you turnover.  A rate of 180 steps per minute, with a stride of 7 1/3 feet per stride will get exactly a 4 minute mile… it’s simple math!  Anything quicker or longer will increase the velocity.  The same is with agile projects.  Decrease the time of each iteration (from idea to successful deployment), and you will increase velocity.   Increase the amount accomplished in each iteration, and you will increase velocity.  Increase both, and you may have a world class team…

More on this later…

Most organizations at this point start out with good intentions. It’s like the dual monitor craze 15-20 years ago.  Productive people had dual monitors… so everyone should have dual monitors so they can be productive too… or watch reels on one while they try to accomplish work tasks on the other.. at least during the ads.  So when the “Agile” buzz word erupted, everyone was supposed to jump on board.. because xly corporation had success adopting it.  Teams of unknowing scape-goats herded toward the newly found timesheet bazaar.. a smorgasbord of tasks and acronyms that gave the wonderful appearance of business; and looked most productive.

More on this topic soon…

I recently read a large organizations agile technical document that defined “Iteration- a period of time”.  Talk about redefining a word.  How in the English languishing, can iteration come to mean a ‘period of time’… only in the corporate universe.   An iteration is repetition according to any dictionary.  Trying to make it a ‘period of time’ forces the term to mean quite the opposite of it’s true meaning.  An iteration in the agile world, the development world, is the successful cycle from idea to deployment of the idea.  This cycle is repeated… well repeatedly.

More on iterations and velocity soon…

This slog is a blog about agile projects.  Not simply ‘agile management’, but agile projects overall and in detail.  Agile projects, in most organizations, have lost their agility.  “Agile”, has become just another catch-phrase that has wandered far from the original intent and definition of the term.  Agile by any other name should still be “agile”.   This site is dedicated to demonstrating the benefits of holding fast to the core values in the Agile Manifesto, and warning of the cost of wandering and redefining the methods, bogging down the productivity with unneeded layers and details.  And practical suggestions on how to escape from the traps of over-management.