Saturday, October 21, 2017

Agile Development on Infrastructure

After a friend asked about using agile, I started thinking about the skateboard to car drawing.  The author of this, Henrik Kniberg, wrote a really good blog breaking this down, called Making sense of MVP (Minimum Viable Product).  This model is absolutely important, and makes a very good case for going about building something brand new.

Not wheel, drive train, part of car, to car; skateboard, scooter, cycle, motorcycle, car

I've spent most of my post-Agile time doing infrastructure projects.  I'm not building a product for end-users.  I spend most of my time replacing things that are already integral to a finished product.  I did Agile work for over two years convinced that the MVP model was meaningful but that it doesn't really reflect what I do.  I turns out, I was using this model, but thinking about it wrong.


Extending the metaphor above, the group I work for got to step 4 of the top line.  They did that in the 1990s.  As I learned about agile, and got my certification, the wheel, the original step 1, needed to be replaced and updated.  The wheel was doing more than it was designed for.  Imagine, if you will:

Don't Overload Your Car

This is much harder than developing for something new.  I work for a big company, so it's important to understand that millions of dollars of revenue, per month, is travelling in this metaphorical car.  I can't pull out the wheel work on it.  I can't build part of a wheel, and present it to the production product flow.

Rethinking the Customer

I didn't realize it at the time, but my customer was tests.  Fairly early in the project, a test suite was built to validate things.  The first time we, as a group, were able to validate what we were doing against a test suite, we had our first MVP.  That took 8 sprints (about four months).  I forgive this for anybody new to Agile and anybody working on anything truly large.  That four months wasn't aimless.

Think of this time as the wheel above.  Wheels, when they cannot simply be sourced from somewhere, are amazingly complex.  What was built during that time was very important, and I'm honestly not sure, even in hind-sight, how we could have brought that chunk down.

The project I worked on took 20 months (on an 18 month estimate), and there was no part of this project that could actually be used in production until the day it was done.  Yet, I couldn't have done that project without Agile methodologies, and I couldn't have done it without several minimum viable product points.  The tests were early enough so that we didn't waste time doing something that was broken, they were unforgiving, and they are still useful for further improvements to this day.

Why I think I can talk about this:

No comments:

Post a Comment