Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was....[drumroll]...five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.
Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works." Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
The implications of these changes in emphasis could be significant in terms of mindset and capabilities in and out of IT departments. From a focus on standardization, optimization, and cost control, the focus shifts to innovative uses of emerging technologies such as social media, cloud computing, and mobile devices; speed to market; flexibility to follow changing opportunities, and building new products and services.
Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.
To a large extent, these practices deal with the easier varieties of failure. Prototyping a feature quickly, so that you can invite feedback when you actually have enough time to respond to it, is an extremely valuable technique for lowering the risk that you build something the wrong way. You need a different approach to identifying the features that you should not build, period.
Why, oh, why is it that every time I hear about a BI project from an IT person, or from a business stakeholder describing how IT delivered it, with few exceptions, these are the stories plagued with multiple challenges? And why is it that when I hear a BI story about an application that was installed, built, and used by a business user, with little or no support from IT, it’s almost always a success story?
I think we all know the answer to that question. It’s all about IT/business misalignment. A business user wants flexibility, while an IT person is charged with keeping order and controlling data, applications, scope, and projects. A business user wants to react to ever-changing requirements, but an IT person needs to have a formal planning process. A businessperson wants to have a tool best-suited for the business requirements, and an IT person wants to leverage enterprise standard platforms.
Who’s right and who’s wrong? Both. The only real answer is somewhere in the middle. There’s also a new emerging alternative, especially when applied to specific domains, like customer analytics. As I have repeatedly written in multiple research documents, front-office processes are especially poorly-suited for traditional analytics. Front office processes like sales and marketing need to be infinitely more agile and reactive, as their back office cousins from finance and HR for obvious reasons.
[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
Another excellent post from Scott Sehlhorst, this time pointing out that, even without product managers, product management still happens. Scott’s post is a response to Jason Calcanis, the founder of Mahalo, who wrote the following:
In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product. We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).
If Calcanis is arguing that his company doesn’t need product managers, because they just are in the way, Scott makes the obvious counterargument:
When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code. There is, at the minimum, implicit design happening in the mind of the programmer. It might not be “good” design, but there is always design. There is always a method to the madness, just not always a considered method. The same is true of product management...Eliminating product managers does not eliminate product management.
[For earlier posts in this series, click here and here.]
Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.
You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).
The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump.
In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.
Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:
Politics is a word that we use so loosely that it risks losing meaning altogether. When we talk about office politics, as some recent posts by product management bloggers, we're usually expressing scorn for odious behaviors that stand in the way of some rational course of action. Every organization is susceptible to politics, in this negative sense, including every development team. Better to assume it, or even take advantage of it when possible, than to pretend that some magic tool or methodology will do away with politics.
Can't Live With Politics. Can't Live Without Politics
In their blogs, both Jim Holland and Jennifer Doctor recounted a session about politics at a recent Product Camp in Seattle. The topic struck a nerve, as evidenced by the outpouring of complaints from the audience. We've all heard them, whether we're product managers or not: Empire builders put themselves ahead of the interests of the group; real decisions happen in a back channel, instead of in the open; teams decide in haste, and repent at leisure . . . It sounds as if this session was as therapeutic for the audience as it was informative.
Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:
Some collaboration is transient – communication happens right now, and is only important right now. Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.
Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information.
Ever since I got an iPad, I've been eager for the update to the upgrade to the iOS4 operating system that premiered on the iPhone months ago. The ease of use of the iPad erodes, grain by grain, with each app that you add to it, as long as you're forced to keep sweeping across page after page of apps. Organizing apps into functional groups across pages is a tedious process. After a while, you really feel the need for folders to organize your apps more effectively.
Imagine my disappointment, therefore, when iTunes froze as soon as I launched it. It was the start of yet another chapter in the story of my hate-hate relationship with iTunes, because of its unstoppable bloat and accompanying seizures. With every major update, iTunes grows another layer of fat, causing more frequent electronic coronaries when it needs to run (or waddle) through its paces. I can't say I was surprised that iTunes froze, forcing me to reinstall it (the software equivalent of sending someone to fat camp?) before I could get it working again.
Here, from a single company, on a single desktop, is the history of the tech industry's problems with complexity. A device that is consummately simple to use, the iPad, is handcuffed, like a slender Sidney Poitier to a morbidly obese Tony Curtis, to iTunes. As Apple keeps jamming more of its business plan, in the form of new features (Genius, Ping, etc.) and new content (anything that could be described as "released" or "published"), iTunes swells to ever-increasing levels of complexity.