A la Carte Agile

Let’s say you’ve decided that since "agile" means to move fast and quickly adapt, like 72%  of American companies using some version of Agile, you’ll adopt it too…. 

Only it’s too much to commit to preparing stories (can’t we just call them product requirements?) in advance of a sprint because you never know how the market will change or what the vendor will deliver.  And you can’t really fill the three roles (Scrum Master, Product Owner, Delivery Team) because you have folks who wear a lot of hats, and you don’t have the resources to nail down dedicated teams.  And how is it “agile” to require that the product owner lock down what needs to be done before a sprint?  That doesn’t sound flexible.  The team should be able to change direction at any point in any cycle.  And you really can’t require your developers to spend all that time in these warm, fuzzy meetings that Agile calls, “ceremonies.” That’s a waste of time. And certainly your developers need to put careful thought into building the foundation of the software, so really, sprint cycles should allow for continued work from cycle to cycle without unreasonably requiring folks to deliver end-to-end in two to four week sprints.  Other than that, you are 100% behind whatever those crazy team leads what to do.  By all means, go, agile!  Fast and nimble! 

Hard reality: when you take out any of these factors, you’re not really doing Agile development.  You’re doing some sort of hybrid of Agile and Waterfall, and that can be okay; you certainly may end up making  improvements by implementing some, but not all of the system.  I’ve done it, and it’s the preferred alternative to mayhem. But you’re not making a full paradigm shift to true transformation, and you’ll continue to experience foundational roadblocks. 

People confuse the formal title of the methodology “Agile” with the lower case “a” adjective, “agile.”  While the methodology does allow organizations to be agile, as in nimble, it’s not without structure, and specific process.

Save yourself and your organization unneeded, drawn-out heartache by ripping off the bandage as quickly as possible, adhering to the fundamentals and diving into the benefits right away.

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.

Is there a manager in the house?

We’ve all seen it: So-and-so has a manager title, and the whispered comments begin floating about the office, “What does So-and-so actually DO?”  It’s the classic upper management go-to:  promoting the SME or the technician to a management position, or hiring up a tennis partner, college buddy, or the guy from the last startup who single-handedly “managed” a guerilla implementation of that quick-sell app that got everyone cashing out fast.   

Don't be too hard on your leadership. It's human nature to rely on the people we know or have relied on previously; still, all of these hiring decisions assume one consistent fallacy: that management is innately easy. 

It’s unfortunate that SMEs/individual contributors don’t have a way to move up in title and salary by adhering to what they excel at.  Instead, organizations require that they manage.  The genius who unraveled and re-configured code in a way that leapfrogged two generations in front of what is currently in the market, is also assumed to also have the skills to manage and communicate risk to a project, or mentor employees.

Executives tend to get a bad rap when they hire cronies to run departments.  Back room bar deals and golden parachutes come to mind.  But even the most self-focused business leaders have a laser-sharp focus on generating a successful business that turns a profit.  So it’s safe to say that very few would hire a friend thinking, "There's no way he can do the job, but, oh well."  The same goes for hiring a great executor as a manager.  The most common assumption is:  of course a strong executor can build and manage a team of strong executors.  It ain't necessarily so. 

What business leaders frequently fail to realize is that effective management has its own set of skills that are distinct from other business skills.  To make matters more complex, these tend to be soft skills that are often difficult to identify and hire for: situational leadership abilities, varying approaches to decision-making, project and risk management, the full spectrum of communication skills.   Probably over and above all of these is the discernment to identify the best approach after speed-analyzing data points in an ever-changing problem set. The best managers have analytic skills and a high degree of social intelligence, with a proclivity toward servant leadership. 

And you know what, even when you have a manager like this, the file room conversations might still include the question, “What do they actually DO?”  Why?  Because if things are going right, they aren't generating all the deliverables, nor are they constantly in firefighting mode.  A good manager will have subject matter expertise, but will distribute work to their teams, empowering them to be the best they can be, and making sure the trains are running smoothly.  They are transparently communicating the work their team is doing, the roadmap ahead, and the ROI at all times, up, down and across the food chain.  This is often quiet, behind the scenes hard work. 

To my mind, the best managerial KPI would be something akin tothe plus/minus rating in sports.  The +/- rating tells us: did the team gain or lose points when that player was on the court/field/ice, and if so, how many?  That player may not have had their hands on the ball when the point was scored, but these are the key behind the scenes playmakers, setting up others in the team for success.  

So next time someone asks, “What does Manager X do?,” look carefully.  Maybe nothing.  But maybe that person is exactly the kind of manager you want on your team. 

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.