Products Are Hard

You are here: Home / Archives for Featured

Agile for Executives

By

Often when we work with product and engineering teams to improve their processes we also end up talking with executives that aren’t directly involved in building the product. Of course, products are not built in a black box — you cannot adopt the good thinking that has gone into Agile practices without having organizational buy-in. But many product teams struggle to get executives to see Agile thinking as more than just an engineering practice.

We put together a short presentation hitting some of the key tenets of Agile specifically for a non-engineering, non-product audience. The presentation has been well received, so we’re sharing it here in case it’s helpful for your organization.


Deconstructing Agile Part 1: The Language of Agile is Broken

By

The vocabulary of Agile does more harm than good. In helping companies adopt Agile methods we find we need to correct mistaken impressions people have gotten from Agile literature. Our first task is often to help them unlearn unhelpful language so that they can set the right goals and get buy-in from teams. As George Orwell wrote in his famous essay, “Politics and the English Language,” “language can also corrupt thought. A bad usage can spread by tradition and imitation even among people who should and do know better.” Perhaps Agile is dead, but in any case it’s definitely time for a new product development vernacular.

Teams that are new to Agile are particularly susceptible to flaws in the lexicon, often getting the wrong impressions about why these practices might help them. We’ve seen teams go from openly hostile to embracing Agile practices when we get them past the literal meaning of the words, so let’s stop needing to explain so hard and start getting a better set of words to use.

The worst words we use…

“Sprint”

A sprint implies a furious run as fast as you can over a short distance, after which you are out of breath, sweaty, and generally spent. Agile is supposed to be the opposite of that. We want a regular rhythm – not death marches to hit arbitrary deadlines, not idle time waiting for monolithic product requirements documents to get finished. Many teams want “going agile” to make them faster – a goal that is counterproductive and ultimately damaging to success. The theme of speed is woven throughout the Agile lexicon, and it has not served product people well. The language should imply doing work on a regular cadence in intervals short enough to allow for confidence in estimating what we can get done but long enough to allow for meaningful progress in each cycle. I prefer words like “cycle” or “interval” or “period” or “stretch” (I don’t care for “iteration” because it often implies for too many people that we will only ever make small changes).

“Velocity”

In an ideal world teams are relatively stable from cycle to cycle and have a consistent level of productivity. The point of velocity is to give us a reflection of the amount of work we can expect to produce as a team over a known period, so it’s seductive. But teams are rarely ideally configured, and how many points we get done can vary widely. Even when we are producing at a consistent pace the implication is still that we’re measuring speed, and it’s hard to resist the temptation to want to go “faster,” especially since we’re measuring our velocity with a number (assuming we’re using story points).

Velocity, as a quantifiable measure of productivity, is destructive to the goals most teams set out with in changing their processes. Managers tend to want to increase velocity by doing things like giving bonuses for getting more story points done. That attitude is profoundly misguided, not least because of the obvious corruption of incentives when teams are given reasons to inflate points or otherwise come up with a larger aggregate number for its own sake. What we actually want is frank assessments of relative difficulty in order to accurately and confidently gauge what we can get done in a given cycle. When velocity is corrupted to be something other than a means to achieve decent estimates (and thus commitments) it has a net-negative impact on producing good software.

I much prefer words like “capacity” or “load” that get us away from thinking about speed and the sensation of hurtling to the finish line and towards thinking about how we can do our own reality check on the work we commit to do.

“Backlog”

Backlog isn’t nearly as bad as sprint or velocity, but it isn’t great. The biggest problem is that in other parts of life we don’t want backlogs – the word implies things that are piling up, undone. It implies chores you have been putting off, things that stress you out because they are backed up. Constipated. We don’t have a “backlog” in any other domain that we are looking forward to tackling, so why use that word in our work? How about “pipeline”? We like to have a healthy pipeline of things. Or perhaps “slate” or even the very broad “board” as a more general list of things we’re currently focused on.

“Story”

The formal structure of common templates for user stories can be very useful. We’ve seen lots of people embrace the “As a… I want to… So that…” model with good results. That said, we’ve also seen a lot of product managers get very hung up on trying to write a “story” because that word implies a lot of structure and skill, not to mention just sheer word count. We would prefer the artifact use as few words as needed, and we find that over time teams start to find the formal structure to be cumbersome. If we have developed short-hands through conversations, that’s exactly what we want, and feeling pressure to make each line item a “story” with a narrative structure can be counter-productive. Call me old-fashioned, but I think “ticket” works well because it’s fairly general, cognitively allowing for a wide range of granularity. Some might prefer “feature” as distinct from bugs or tasks.

“Scrum Master”

The role of Scrum Master is the most problematic for organizations making a transition to Agile processes. Much of the difficulty has nothing to do with the name, but the name does carry unnecessary baggage into the discussion of what a Scrum Master does and why they are good to have. As a role that isn’t directly responsible for making something concrete, many managers who would otherwise be enthusiastic about Agile are loathe to pay for someone to “just” run sprint rituals. That resistance is exacerbated by confusion about the power (or lack thereof) that person will hold by virtue of the title “master.” Sometimes the best people to play this role are actually up-and-coming engineers who are eager to better understand Agile methods and take on a leadership role. “Coach” or “captain” can help frame the role better in the minds of managers and team members.

“Agile”

Finally we come to the name of the entire discipline. Once again we are faced with speed-based thinking, and once again we endanger the success of our process by focusing on the wrong thing. We’re right back to setting the wrong expectations that we’ll be magically faster and cheaper. It’s nice to have a named set of tenets, but the reality is that teams have specific and distinct challenges and constraints. Rarely should we implement a pure version of any of the flavors of Agile practices. It has become increasingly common to see long-time advocates for Agile practices become disillusioned with what “Agile” has come to mean.

In our consulting work we focus on tailoring the recommended changes to the specific team and the goals they have. Usually we end up focusing on being more adaptive and responsive or on shortening the distance between ideas and manifestation of those ideas (both in terms of communication and elapsed time). A process well-matched to a team should be derived by that team based on first principles that come from introspective self-awareness by that team.

In summary, here’s a mapping of some suggested changes to the vernacular, in rough order of my preference.

Agile → Responsive; Humanized

Sprint → Cycle; Interval; Period

Velocity → Capacity; Throughput

Backlog → Pipeline; Slate

Story → Ticket; Feature; Token

Scrum Master → Coach; Captain

The age of holistic product development

By

Over the last decade a few major themes have dominated the evolution of product development, particularly software development: a shift towards agile practices, customer-centric decision-making, and better integration and collaboration across disciplines. The last of those – the increasing porousness between the “Big Three” disciplines of product management, design, and engineering – is evolving the most rapidly. The tenets of Agile development are fairly mature at this point. Customer development and Lean practices are now considered conventional wisdom. But the ways in which designers, product managers, and engineers work together are in flux. The boundaries between the Big Three pillars of product development are just beginning to blur.

Design has changed the most dramatically and had the most significant impact on engineering and product management. A decade ago design was little more than static mockups or graphic treatments of engineering output. Today, not only is design key to creating successful products at all stages of the lifecycle, it has also become a viable strategic differentiator for the companies that do it best. Design as a discipline has always encompassed more than just the façade (the “chrome” as we called it before Google appropriated the word). In software, however, only recently has design been acknowledged as a major strategic input. Product managers are the voice of the customers, but designers are the voice of the humans.

Designers in software have also become more rigorous and technically proficient. A shiny mockup that gives a good first impression was all a good designer used to have to make. Today we expect the design process to start from a clear set of first principles derived from a deep understanding of the people using the product. We expect designers to understand information architecture and to create a consistent, reasoned visual vocabulary and a sensible flow. We expect designers to intimately understand the capabilities of the technologies used to implement their ideas, and increasingly we see designers with substantial software development experience working with the same tools as engineers.

The evolution of design has impacted product managers and engineers as well. Product managers are now expected to understand and utilize design thinking. Engineers need to be conversant in the design vernacular and are becoming increasingly skilled in basic design principles. These cross-pollinations are a healthy development, and as the last vestiges of linear, waterfall-style processes fall away, teams are looking for ways to integrate their efforts and break free of assembly-line metaphors (GANTT charts are not exactly in fashion in software development). Classic Scrum orthodoxy has also left teams looking to loosen the bottleneck created by a single Product Owner who must be the conduit between the entire business and the Team. At the previous two Products Are Hard conferences, for example, we saw a great deal of interest in talks about ways to better integrate designers into the development process.

We use the world “holistic” to describe this evolving approach because of the convergence of disciplines, processes, and strategies that are all based on integrating across disciplinary boundaries. Designers, product managers, and engineers are influencing each other and are working more closely than ever before. We have built new processes to favor responsiveness and experimentation over predictability and certainty. We have pushed our business strategy to be more informed and harmonized with the human needs and desires of those we build for.

We’re curious about your experiences. Are you seeing a similar trend? Different trends? Let us know: @productsarehard

Sprint is a four-letter word

By

I’ve always been uncomfortable with the term sprint. It’s a short word, easy to say and quick to type, but the connotations can be misleading, especially for people new to Scrum. I used to run track in high school, and I have a pretty vivid body memory of what it felt like to sprint – an all-out blast of energy expenditure that left me panting, heaving, and, sometimes, if I’d pushed hard enough, even nauseated. I was no Usain Bolt, but I wasn’t a slug either. I was a regular person, reasonably able to run pretty well. It left me in no condition to do anything but sit there recuperating until my muscles and lungs stopped screaming and returned to functioning normally.

You can’t sprint your ass off, pause for a minute, and then do it all over again. It’s not sustainable. And yet one of the most important benefits of the Scrum framework is that it provides a sustainable rhythm for work. It’s meant to be the opposite of a death march or a self-destructive series of Jolt-fueled all-nighters followed by days of hibernation and recovery.

There’s always the argument that after enough use, the word itself becomes a signifier for the concept and its connotations become less relevant. Who, after all, thinks about chitinous little bugs when talking about John, Paul, George, and Ringo? But words do matter, otherwise we’d refer to everything with algebraic letters, symbols, or glyphs. So, no, I’m not proposing that we start referring to sprints with Σ (even though that would be awfully cool), but language being what it is, the other commonly used terms are each fraught in their own ways. I tried using iteration for a while, but Nathan found that made people think about dozens of tiny, obsessive refinements towards a specific ideal. Sprints are about getting shit done and perfect being the enemy of good, most definitely not about obsessiveness or idealism. Timebox, another common-ish term, feels cold, bureaucratic, and constricting. So, in the spirit of Scrum, we continue to try out different words, getting a sense of how well they do or don’t work, and we iterate our way forward. We may never have the definitive word, there certainly isn’t a perfect one, but in the meantime we’ll keep talking, training, coaching, and working.

UPDATE: Sasha Magee offered some interesting proposals from the sport of cycling:

The five pillars of product management

By

A few years ago, as I prepared to leave a product manager position, I trained a junior member of the team, someone new to the role of product management, as my replacement. I told him the role comes down to the following five elements.

Gather

A huge part of product management is simply knowing what’s going on — what people do all day as it relates to the product, what kinds of things they wish they could change, and how the various constituencies interact. While most product managers have plenty of good ideas on how to improve the product, gathering ideas from and identifying problems in the rest of the organization are just as important.

Synthesize

As ideas and issues emerge, a product manager must create connections where others do not see them. Two groups in an organization may have two very different problems. A product manager should be able to find a way to make a single, better-abstracted view of the underlying concern. Synthesizing also involves creating named themes, initiatives, and goals for a product. Never underestimate the power of synthesis to create common understanding and bring sanity to the chaos of “line item” requests. Synthesis is also instrumental in winning the hearts of product team members.

Prioritize

Choosing what is most important is an art. Deep understanding of business strategy, market realities, and resource capabilities is key. Knowing what’s hard vs. what’s easy and what’s of broad vs. narrow value helps to create a prioritized list of the various tasks to be completed. Given infinite time and infinite resources everything would be possible, but in the real world, making the hard choices (or, more importantly, helping the rest of the organization make the hard choices) becomes one of the central functions of a good product manager.

Define

A product manager must own the detailed definition of what the product should do so that engineering knows what they will build. This involves plenty of documentation, though much less than you probably think. Document only as much as you have to. Don’t create detail for detail’s sake. With web-based software the need to be quick and iterate frequently makes it essential to move forward with imperfect information and adjust as you go. If you’ve been an engineer or worked closely with engineers, you know the unique horrors of changing the spec and the dread of feature-creep. Part of the reason for the rise of agile methods is that rather than constantly reacting to attempts to get to a “finished” spec of a project (only to see that spec change in the middle of the cycle) engineers started to simply build the dynamic nature of requirements into the system. “Define” does not always mean writing down as much as being the Source of Truth.

Shepherd

A big part of my day as a product manager involves, quite literally, walking around the building. Keeping all of the balls in the air is a critical part of product management. In most organizations there is nobody else who sees all the various pieces and how they must fit together. Many product efforts require coordinating distributed efforts towards a single destination (and doing that over and over again). In my world, having the engineering “done” is only about 2/3 of the process. Once the actual “product” is at a finished state, packaging, documenting, training, and distributing all remain.

When I first put these 5 elements on a white board I wrote the word “CONTEXT” next to them. Ultimately, you must undertake all of these activities with a full appreciation for the business as a whole — the goals, strategies, capabilities, culture, and, most importantly, the people.

Product is a curious function. It is often under-appreciated, yet it is also the domain of some of the most powerful people in Silicon Valley. Product people must be generalists while also obsessing about small details. They must cross cultures within their organizations. They must be able to step outside the organization and sit on the same side of the table as the people for whom the product is made. It’s a hard, rewarding job and it’s the glue that holds many great organizations together.

 

Choosing a technology is choosing a culture

By

Which technology is best to use in launching a new site or web application? There was a time when I would answer this question by getting into the details of the various features and performance characteristics of a given platform, but over the years I’ve realized it’s really not a technology question; it’s a people question.

The issues are: who is going to build it, and who are you going to want to hire to continue to build it. Anyone who has been around software engineers (or any engineers) knows that a truly great engineer is worth many mediocre engineers, so if you’re starting a technology-intensive business, it’s critical that you be able to attract high caliber people. For instance, Adobe ColdFusion (formerly Macromedia ColdFusion, formerly Allaire ColdFusion) is an extremely productive platform for building web applications — in terms of getting something done quickly it’s great, but good luck finding great engineers who want to work with ColdFusion. Deserved or not, ColdFusion has a reputation in the industry for not being a “real” programming environment (there’s a whole other discussion to be had about the perversely inverse relationship between the ease-of-use and productivity of a programming environment and the credibility it receives in engineering communities). Most software developers wouldn’t want to be forced to work with ColdFusion for fear their other skills would atrophy. This is not a statement about how good ColdFusion is as a technology; it is a statement about the realities of putting together a team.

This is a nuance lost on a lot of entrepreneurs and managers who haven’t done hands-on coding before — the tools you choose define the nature of the team you will build moving forward, and in most cases it’s extremely difficult to switch gears. To be fair, this nuance is also usually lost on engineers, who can easily burn a lot of cycles debating the merits of Ruby vs. PHP vs. Java vs. ColdFusion vs. every other thing. In the end,  the tools listed here, among many others, are mature enough that they can all serve well to create web-based applications. Some might take longer, some might not scale as readily, some might not integrate with other technologies as easily, but from the standpoint of “can it be built in a reasonable amount of time and be production-ready and reasonably scalable” the answer is yes in all cases. The best technology to choose is the one that creates the culture you want.

Get in touch

415.683.6936
@productsarehard