The Agile Funnel Problem

 

"The pressure of delivering should never outweigh the pressure of delivering the right solution."

In Agile Development the company as a whole is often tripped up by the undue pressures put on the Product Team.  Stakeholders always wants more than can be delivered in a given time frame, they want it yesterday, but they also expect it to be strategic.  Yes, essentially they want it Cheap, Fast and Good.

In the "Agile delivery" scenarios that often evolve around Agile Development shops, a pressure-cooker style product management approach begins to take shape by default.  The Product Team optimizes by beginning to boil down the deliverable expectations to the exact solution that was described by the stakeholders.  This allows them to remain with their head above water and allows everyone quick wins that verify that indeed "Agile is working".

In this common scenario however, the product team is subconsciously never really allowed to plan for the future.  Not taking enough time with the stakeholders (and leadership) to understand what they want vs. what they ask for begins a sort of solutioneering life-cycle.  This does in general satiate the documented need and gives everyone immediate reasons to celebrate; but a lot of knowledge and opportunity is lost in the process.  This is usually not noticed until much later; many Sprints into the Agile delivery process.  At this time the company usually begins to stagnate with products that are in the wider market seen as un-remarkable.  What defines truly remarkable I will save for a future topic.  (Hint: it's not about spending big bucks with a design agency.)

Effort vs. Real Cost

As Feature Requests are boiled down into User Stories that minimize the perceived necessary Effort (note: in-sprint development hours ≠ real cost over time), the deliverables are usually too customized to properly be reusable and have any long term benefit.  Plus the User Experience is probably handled by just sticking it somewhere on the existing screens, or asking a UX person where they should put it.  In many cases, if you assume they'll be able to magically fix your User Experience at this point, you may not want to know where they think you should "put it".  Though a good UX practitioner will hopefully have engaged with you long before.

The pressure of delivering should never outweigh
the pressure of delivering the right solution. 

Over time, this just piles up in an unrecognizable mess, at least to the person who started the company with the goal of changing the way things are done.

If you don't plan ahead (something that is often shorted by merely "trusting the Agile method" too much) and you don't allow development to ever re-factor something (a foundation of Agile Development that is often skipped due to the pressure of too many short-sighted Feature Requests, aka. solutioneering), then you are really just creating really tiny waterfalls.

In true Agile fashion, you could just let each development cycle handle deciding whether you found the right solution; or you could adopt a more agile approach within Product Management as well and delivering more thought through User Stories to Development.  These stories would already have considered the future, at least in terms of validating the proposed solution.

That doesn’t mean that first delivering the Minimum Viable Product and staying Agile doesn’t still hold true.  Delivering the Right Solution is still helped by the more nimble Agile approach.  The point really, is that Agile Development is not an excuse for passing on Unvalidated Ideas to development.  Development has enough things to juggle and figure out.  Help them understand where you are collectively headed and help them understand how things are best formulated for the most flexible application (within scope of the long term direction).  This puts you in charge of the direction instead of reacting to yesterday's needs.

Build towards your vision every day, starting now.  

Don't put the right solution off by sentencing it to the prison of the unreachable 'tomorrow'.  Make sure you’ll get the pieces you really want, not just what you need in order to make it through the day.  If you act like a burned out also-ran, you're more likely to become one.

Plan intelligently.  Empower your developers with the information you filtered out.  They will still pass things back into the sprint for adjustment, but you're less likely to throw away an entire pie, when all it needs is a little more time in the oven.

The "Think System" or Systems Thinking

The Music Man (1962 film)

Some Agile coaches come in promising that if you just trust in the old Agile Methodology everything will magically happen. I’ve seen this happen twice with the same coach at large companies. He’d been coaching since the earlier days of Agile, when it was more appropriate method for small start-ups or small teams trying to get something quick out the door. Over the past decade Agile has become a common mantra of big organizations who are trying to solve the time-to-market issues of their old approach which is usually associated with the Waterfall Method. Because of the pains and complaint they get about time-to-market, they’re easily sold on the idea that if you just trust it and don’t look outside of your 2 week sprints, once you’ve done it long enough you’ll end up with a wonderful magical new system that just works. Both times, what the coach had sold the organization failed and the teams realized a need for a comprehensive approach. Something akin to knowing that you’re taking a road trip to somewhere and estimating how long you might drive each day; without falling into the trap of either a) planning every mile down to the minute or b) taking a Kerouac-esque trip to… we’ll know when we get there.

This rage against Waterfall reminds me of The Think System, from the old 50’s musical The Music Man. A bunch of townspeople are so eager to hear that their children are musical geniuses that they believe a talentless con-man who tells them that if their kids just “think the notes really hard” they’ll be able to play them. Only to leave town with the money before the first concert. This reminds me of those Agile coaches who are more interested in “coaching” you than in your result. Not saying that all Agile coaches are bad, some are quite excellent, but the truth is in whether they are more interested in getting you to practice the method and trust them than worrying about the fact that you’re actually building something specific with critical real-world applications that will make or break your strategy. Just like if you hire an agency to design your product for you; they’ll potentially be more interested in impressing you and getting that quick win, than integrating Design Thinking into your entire organization. If you're not starting out with something akin to Systems Thinking (see Wikipedia), you probably don't have a good idea of where you want to go. And unless you're Kerouac, that's probably not a good thing.

So, if you’re trying to build a $100 million system or if you’d like to achieve a great User Experience using this pure Agile concept, I’m sure you will perhaps get there after about 10,000 sprints. But that goes against the whole reason for adopting the Agile Methodology in the first place. The point is, getting something out the door for a quick win can’t be your main goal, unless you're boot-strapping the next big thing in a shed near Silicon Valley. Speed is critically important, but unless you have an idea of the complete eco-system, including your User Experience Strategy you are bound to keep fixing problems instead of innovating and building towards a greater whole. And your product will undoubtedly suffer.

If you know what you're trying to achieve (in the big picture) and what your priorities are (in context), you're going to be be able to plan and deliver better than either of the other options.

Good UX is all about 'Innovation'

Good UX is all about 'Innovation'. This is not to say that UX has to be innovative to be good, but it does have to evolve properly to achieve the right result. 

One of the things I've learned, from designing products and systems for a wide variety of companies over the years, is that the initial expectation is that you will come in and churn through a few requirements each day; putting each brick in place and finally arriving at a complete product. This is usually done once they realize that there is a need for UX and isn't always done with a lot of forethought. While this is certainly a proven way to get a job 'done', it's just as likely to produce the least innovative result. In many cases delivering little more than a reprogrammed/refreshed version of what they might have already had. Being able to fundamentally re-think how a user interacts with a system means understanding both the system and the interaction as a whole, not in a step-by-step basis. We live in a three dimensional world, not a one dimensional one; so why do companies naturally approach their UX as if it always follows a one dimensional 'wizard' like flow?
Some companies prioritize the guaranteed and predicable method this gives you because of their size and the amount of money they invested in the project in the first place. In other words, they're so afraid to fail they forget the true meaning of innovation. There are of course other reasons for this approach, like tackling the limited set of requirements that business has already signed off on and the immediate need for delivering UX artifacts to the developers in waiting. (Whether development has other building blocks they could be working on is a separate discussion.)

This would probably explain one of the reasons smaller companies (or even more often, start-ups) seem to be able to innovate so easily while others try and try again to replicate the same results. Leading to the frequent need for the larger, more established companies, to acquire the smaller ones for their innovative solutions to help put them back on the fast track. 

Many larger companies have started to adapt the Agile Development Method in order to try to capture the magic that allows smaller shops to bring better stuff to market faster. While it works for getting stuff done, I have yet to see a case of pure Agile Development of a multi-million dollar project leading to an innovative User Experience without some major advance planning of where you want the UX to go. You either have to plan ahead or you will no doubt end up with some major UI rework at the end, which often forces a project to go well over-budget.

Some companies of course are more hampered by an existing customer and partner base so vast that it has little choice but to keep the status quo while trying desperately to also add innovation to an already complex suburban sprawl like environment. This complexity aside, it is always possible to look to the future and set your company on a path to more innovative and up-to-date customer experiences.

So, how does a larger company innovate and still stay on the safe path?

The solution that most often works for me sounds quite simple. UX is holistic; so designing as you code isn't really much of a UX strategy. Since much of the perceived bottleneck (or pain-points) of a UX team is producing the wireframes themselves, especially in Agile, you need to change the understanding of wireframing. It's not something you do to merely illustrate where buttons and info go on the screen. If that is all you're doing, you're doing it wrong; well, at least in the context of User Experience. 

When it comes to wireframing, if you truly want to be "agile", you should sketch out the general functionality in advance of development in an iterative way. The goal being to understand the users and the system goals in context of the whole experience. If you think of your wireframing stage as a mini-"Agile" design phase you can more quickly visualize and test out the intuitiveness, simplicity and complexity of the system cohesively. This allows you to more quickly verify the fundamentals of your UX in the same way that you test out your code at the end of each sprint.

In most cases, the up-front iteration on your wireframes is more than made up for by avoiding the constant daily struggle of trying to solve UI problems (and later re-work those same things) within your scrum teams. It is also an extremely efficient way to manage your UX Strategy and User Interface when you're dealing with several development teams working on different parts of a much bigger project.

Rethink Simplicity

Some say that UX designers live, breathe and eat product design.  One thing I know for certain is that we can't not analyze everything we interact with.  Whether it's a door handle or a car radio.

Recently, I started working on a project for a large hospitality company.  Since our project wouldn't be widely used for 1-2 years, I found myself pondering what types of systems our users would be interacting with by then.  The logical answer is of course that tablets would be well part of the mix by then.  For several years, I've been advocating including tablets in the standard design process for corporate projects (ex: the challenge with rollovers on touch devices) to ensure that you at least have a basic solution that covers them, but in this case I found myself planning for them as part of the standard environment for any of our personae.  This led to a whole bunch of new thoughts (most of them to be documented later).

As everyone who has ever stayed in a hotel can tell you, the first steps of booking are always to enter your check-in and check-out dates (or the number of nights of your stay).  The same would go for anyone taking your reservation.  This has traditionally been presented as a text field with an icon next to it for each date, which pops up a calendar.  This adds quite a few steps and clicks to the beginning of any reservation and seems a bit tedious for a hospitality rep.  When you switch a mouse cursor with a fingertip, the process seems even more tedious.

So the natural question was: How can we change the approach to make it more natural (and much quicker) to select a range of dates when using a touch device, but not make it more difficult when using a mouse?

Why not just let the user point and drag?

Seems like a no-brainer to me.  What say you?