Monday, January 27, 2014

This isn’t the agililty I signed up for….

We’ve trained up on Agile, now let’s get back to work.  There’s not a minute to lose! 

This can’t be right, say Executives and Product Managers.  We’re supposed to be able to tack from minute to minute because the market calls for reactivity and hairpin turns.   

This can’t be right, say the developers. We’re supposed to be able to develop in a dark corner until we deliver the full product you asked us to built.  We should be left alone for the next two years, if need be.

At first it may seem a disappointing compromise to both the "business" and development, but Agile finds the healthy intersection of the two extremes.  Development DOES take time and focus.  If an organization does not allow for that, only the smallest implementations, and very little truly innovative work can be developed.  The market DOES require adaptivity and quick shifts.  If that doesn’t happen, viable products aren’t delivered, revenue isn’t generated, companies fold. 

So, what would happen if we time-boxed development cycles so that every 2-4 weeks, we could depend on developers to built a Minimally Viable Product (MVP)?  Not the whole kit and caboodle with all the bells and whistles, but just the essentials.  Let’s say we were developing an app for finding the best business blogs?  We might first build a simple search interface using Google that tracked down most trafficked sites with the top three keywords.  That’s it.  Nothing more.  Developers would have 2 business weeks to focus only on that small manageable development task.  Then Product Owners and management would have a complete and deliverable product to get out to the consumers after 2 weeks.  Is two weeks fast enough to deliver a product to market?  Most would say yes.  Is 2 weeks of uninterrupted development time long enough to do some version of valuable work?  Most would say yes.  

Your team will likely be initially uncomfortable adapting to the Agile paradigm, but stick with it.  Everyone will be feeling the benefits soon enough.

Monday, January 6, 2014

The Dreaded P-Word

To executives, it’s meaningless, beneath their scope.  To developers and designers, it’s a waste of time.  To Product Managers, it’s an impediment to their work.  Why do we expend any energy at all on something as unnecessary as “process”? 

The classic worst case example is the well-known bureaucracy known as the government.  You want something done?  Here, fill out 20 forms, speak to these 30 people, jump through these 40 hoops, and wait these 50 years.  In this era of all-industry instability, break-neck technology changes with shorter and shorter cycles, and quick-hit investment and exit strategies, it seems that spending any time or thought on process is purely detrimental.  We all need to just get s*&^t done. 

Unfortunately, when we don’t take a moment to think through what we’re rushing to build and how we’re building it, that’s exactly what “gets done”: a big pile of crap.  And another company bites the dust.
The primary reason every organization should put time into the “how” of delivering their products?  Because the how actually directly contributes to the value of what’s being delivered and when.  And you don’t even need to put that much thought into it.  An entire methodology has been devised (and continues to be adapted along the way) to address the very circumstances with which today’s businesses are steeped.  It’s called Agile. 

For some of you, the word “methodology” triggered your eyes to start rolling back into your head. For some of you, seeing the word “agile”turned the thinking right back to “get s*&^t done.”  I’ll talk more about what this means to your business, and how Agile dramatically increases efficiency and value, but it’s not without some of the p-word (process), so apologies in advance. I'll try to go easy.