Transcription
SHIP IThow agile product managerscan build better productstable of contents:Introduction: Why We Wrote This Book031. Understanding Agile Through the Lens of a Product Manager042. The Agile Product Development Team253. Agile Product Management in Motion464. Evangelizing the Agile Mindset77Summary: Applying What You’ve Learned842
WHY WE WROTE THIS BOOKWhen the team at ProductPlan originally set out to write a book about agile productmanagement, we realized we were in a unique position. Not only have we had the fortuneof engaging with thousands of product managers over the past few years, but we alsohave several people on our team with long-time experience in agile software development.More than 15 years ago, I wrote my first requirements document for one of the firstSaaS products. At the time, the requirements were detailed in a thick monolithic Worddocument that covered exactly what the new solution needed to be, along with every oneof the “must have” product features.Only then, after I thought I had documented everything, did software development begin.What we eventually developed over the subsequent months was a close approximation ofwhat I had written. But during development, a lot changed. Decisions were made, featurespared back. The vision of the product I had written didn’t exactly match the reality anddifficulty of developing software. Fortunately, the product sold to millions of businesscustomers and remains a commercial success today.Since then I’ve helped launch several products using agile software developmentpractices. The process is a stark contrast to the typical “waterfall” development that isstill in use by many companies today.At ProductPlan, we believe that agile development practices—combined with what we call“agile product management”—can bring products to market faster and more successfully.With this book we hope to give you some practical advice for developing and managingamazing products.We hope you enjoy it.Jim SemickCo-Founder, ProductPlanwww.productplan.com3
1understanding agile through thelens of a product manager
1understanding agile through thelens of a product managerTHE STORY OF AGILEOver the past few decades, software development practitioners around the worldhave helped drive a movement we now refer to as “agile.” But it wasn’t long agothat other traditional approaches to software development were the status quo.Predecessors to agile typically involved long planning and development cyclesthat followed a rigid sequential order. This kind of linear approach is often referredto as “waterfall” development. Waterfall dates back to the 1950s—more or lessthe beginning of software engineering.With the methodologies of the pre-agile era, every single detail had to be plannedahead. Several cycles were spent gathering detailed requirements and producingextensive documentation before a single line of code was written.PHASE 1PHASE 2PHASE 3SHIPTypically waterfall organizations only update their roadmap once a year or so. Andin previous decades, it wasn’t uncommon for software development teams to planrelease cycles that spanned multiple years!5
Without effective ways to quickly validate ideas within the market, many newproducts were developed heavily based on assumptions. (And we all know whatthey say about assumptions.)In the absence of early prototypes, MVPs, and early-stage customer feedbackto shed light on potential product-market-fit, traditional software developmentprocesses carried a lot of risk.We owe a lot to waterfall, which can now be considered the grandfather ofsoftware development methodologies. It served product managers well fordecades. But as with any field, innovation was inevitable. As the landscape ofsoftware development shifted dramatically towards the end of the 20th century,so too did approaches to managing it.1990’S: NEW SOFTWARE DELIVERY OPTIONSDuring the 1990’s, web-based software and SaaS business models began to maketheir debuts. This movement away from physical software sales meant the longdevelopment and release cycles of the past were soon to be on their way out.The ability to deliver software updates to users immediately enabled developmentteams to start deploying principles like iterative testing thanks to immediateaccess to actionable feedback from real customers.PRE-1990’S SOFTWARE DELIVERYTHE BIRTH OF SaaS6
2001: THE AGILE MANIFESTOIn February 2001, 17 software development practitioners gathered at a ski resortin Utah. They were there to ski. They were there to relax. They were there to eatand drink. But most importantly, they were there to lament, pontificate, and solveproblems.Despite having widely varying opinions on the right way to approach softwaredevelopment, the crew agreed on at least one thing: the status quo was notworking. There was increasing need for an alternative to documentation-drivenand heavyweight software development processes.Out of their gathering in Utah that winter came The Agile Manifesto, a briefdocument built on 4 values and 12 principles for agile software development.It’s important to note that agile in itself wasn’t born then. Its creators, and manyother software development practitioners, had long been applying various agilevalues and principles piecemeal. But The Agile Manifesto made concrete theideas that had been permeating the software development world for the lastdecade or so.7
APPLYING THE AGILE MANIFESTO TO PRODUCT MANAGEMENTTHE 4 AGILE VALUESThe agile mentality is guided by 4 overarching values which differentiate it fromtraditional software development processes.4 AGILE VALUES“Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan”INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLSNo matter how well-researched your process and high-tech your tools are, it’s theteam you work with and the way you work together that determines success. Yourteam and their ability to communicate effectively and efficiently is more valuablethan the processes they follow or the tools you use.This isn’t to say that agile philosophies discourage formalized processes ortools. Both can be helpful in providing structure for your team and facilitatinginteractions. But at the end of the day, they come second.After all, processes and tools are worthless if your team can’t communicate.But put a smart, motivated team up to a task without any processes or tools tomanage the project and chances are they’ll find some way to get it done.8
agile values promote giving individuals the trustand autonomy they need to work effectively.WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATIONTraditional product development processes often required extensivedocumentation before a single line of code was written. Under the agilephilosophy, getting software in the hands of customers is the highest priority.After all, how are you going to improve your product if you don’t get it out in thewild and collect feedback from real users?While this value highlights the importance of shipping software over lettingdocumentation be a bottleneck, it’s important to note that documentation in itselfis not a bad thing.as long as you don’t overdo it.CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATIONThe agile philosophy highlights the importance of customer-centric productdevelopment practices over product-centric approaches. While contracts willalways have their place in business, a list of the things you’re offering yourcustomer is no replacement for actually communicating with them about whattheir needs are and where their challenges are.Traditional product-centric processes allowed contracts to dictate what wasdelivered in the end, which left a lot of room for mismatched expectations. Theagile philosophy (and many of the formalized processes that have come out of it)encourage building a continuous customer feedback loop into development cycles.Under the agile philosophy, customer collaboration begins early in the developmentprocess and happens frequently throughout. This culture of close collaborationwith real customers helps product people ensure they’re delivering effective, useful9
solutions to customers. When you talk to customers often and build feedback intoyour development process, you reduce risk and eliminate guesswork.RESPONDING TO CHANGE OVER FOLLOWING A PLANAn important benefit of the agile methodology is that it encourages frequentreviewing and retooling of current plans based on new information that the teamis continually gathering and analyzing. The product roadmap, then, is no longer astatic document, but a dynamic strategy. Product managers in agile environmentswill need to learn to present their dynamic roadmaps to stakeholders in atransparent manner that reflects the likelihood of change based on new ADJUSTGO LIVEIn other words, the agile methodology lets a product team adjust its priorities andplans whenever doing so makes strategic sense. These teams do not get stuck inan outdated plan simply because they have committed to seeing it through.10
THE 12 PRINCIPLES OF AGILE SOFTWARE DEVELOPMENTAGILE PRINCIPLE 1“OUR HIGHEST PRIORITY IS TO SATISFY THE CUSTOMER THROUGH EARLY ANDCONTINUOUS DELIVERY OF VALUABLE SOFTWARE.”The best ways to ensure you make customers happy while continuously deliveringvaluable software are to ship early, iterate frequently, and listen to your marketcontinually.Unlike traditional approaches to product development, which have notoriouslylong development cycles, agile principles encourage minimizing the timebetween ideation and launch. The idea is to get a working product in the hands ofcustomers as soon as possible. Doing this successfully means product managersare able to quickly get a minimum viable product (MVP) out and into the world anduse it to get feedback from real customers. This feedback is then fed back into theproduct development process and used to inform future releases.HOW IT LOOKS IN PRACTICE:nP roduct teams use minimum viable products and rapid experimentationto test hypotheses and validate ideas.nF requent releases help fuel a continuous feedback cycle betweencustomer and product.nS hipped and done are not the same thing. Instead of releasinga “finished” product, iterations continue to make incrementalimprovements to it based on customer and market feedback.11
AGILE PRINCIPLE 2“WELCOME CHANGING REQUIREMENTS, EVEN LATE IN DEVELOPMENT. AGILEPROCESSES HARNESS CHANGE FOR THE CUSTOMER’S COMPETITIVE ADVANTAGE.”In the world around us, change is the only constant. Agile principles and valuessupport responding to these changes rather than moving forward in spite of them.Previous approaches to product development were often change averse; detailed,well-documented plans were made before development began and were set instone regardless of new findings. Agile principles support observing changingmarkets, customer needs, and competitive threats and changing course whennecessary.HOW IT LOOKS IN PRACTICE:nP roduct teams are guided by high-level strategic goals and perhapseven themes below those goals. The product department’s success ismeasured against progress toward those strategic goals rather than bydelivery of a predefined featureset.nP roduct constantly has its ear to the ground monitoring the market,customer feedback, and other factors which could influence productdirection. When actionable insight is uncovered, plans are adjusted tobetter serve customer and business needs.nP roduct strategy and tactical plans are reviewed, adjusted, and sharedon a regular cadence to reflect changes and new findings. As such,product needs to manage the expectations of executive stakeholdersappropriately and ensure they understand the “why” behind changes.12
AGILE PRINCIPLE 3“DELIVER WORKING SOFTWARE FREQUENTLY, FROM A COUPLE OF WEEKS TO ACOUPLE OF MONTHS, WITH A PREFERENCE TO THE SHORTER TIMESCALE.”Agile philosophy favors breaking a product’s development into smallercomponents and “shipping” those components frequently. Using an agileapproach, therefore — and building in more frequent mini-releases of yourproduct— can speed the product’s overall development.This agile approach, with short-term development cycles of smaller portions ofthe product, results in less time spent drafting and poring over the large amountsof documentation that characterizes waterfall product development. Moreimportantly, this frequent-release approach creates more opportunities for youand your teams to validate your product ideas and strategies from the qualifiedconstituencies who see each new release.HOW IT LOOKS IN PRACTICE:nA gile development cycles, often called “sprints” or “iterations” breakdown product initiatives into smaller chunks that can be completed ina set timeframe. Often this timeframe is between 2 and 4 weeks whichtruly is a sprint if you consider the marathon-like development cycleswaterfall teams often follow.nA nother popular alternative to agile sprints is continuous deployment.This method of shipping software frequently works less in terms ofpredetermined time boxes and more in terms of simply deciding whatto do and doing it.13
AGILE PRINCIPLE 4“BUSINESS PEOPLE AND DEVELOPERS MUST WORK TOGETHER DAILYTHROUGHOUT THE PROJECT.”Communication is a critical component of any project or team’s success, and agileprinciples essentially mandate that it’s a daily event. It takes a village to raise achild they say, and that applies to product as well.A successful product requires insight from the business and technical sides of anorganization which can only happen if these two teams work together consistently.Regular communication between business people and developers helps improvealignment across the organization by building trust and transparency.HOW IT LOOKS IN PRACTICE:nC ross-functional agile product development teams include productpeople. This means that product is represented on the developmentteam and bridges the gap between technical and business aspects ofthe product.nD aily update meetings, or standups, are one technique many agileshops use to put this principle in practice and keep everyoneconnected.14
AGILE PRINCIPLE 5“BUILD PROJECTS AROUND MOTIVATED INDIVIDUALS. GIVE THEM THE ENVIRONMENTAND SUPPORT THEY NEED, AND TRUST THEM TO GET THE JOB DONE.”A key part of the agile philosophy is empowering individuals and teams throughtrust and autonomy. The agile team needs to be carefully built to include the rightpeople and skill sets to get the job done, and responsibilities need to be clearlydefined before the beginning of a project. Once the work has begun, however,there’s no place in agile for micromanagement or hand holding.HOW IT LOOKS IN PRACTICE:nP roduct must clearly ensure engineering understands strategy andrequirements before development starts. This means not only sharinguser stories with the cross-functional team but also the bigger pictureoutlined in the product roadmap.nP roduct is not responsible for explaining how something should bebuilt. They need to share what and why, but it’s the delivery team’sjob to determine the how. Furthermore, during sprints, product doesnot micromanage outcome, instead they make themselves available toanswer questions and provide support as needed.15
AGILE PRINCIPLE 6“THE MOST EFFICIENT AND EFFECTIVE METHOD OF CONVEYING INFORMATION TOAND WITHIN A DEVELOPMENT TEAM IS FACE-TO-FACE CONVERSATION.”With so many distributed or remote development teams these days, this principlegets a bit of critique. But at the root of it, effective communication with developersmeans getting these conversations out of Slack and email and favoring morehuman interaction (even if done by video conference calls). The overall objectivebehind this principle is to encourage product people and developers to trulycommunicate in real time about the product, requirements, and the high-levelstrategy driving those things.HOW IT LOOKS IN PRACTICE:nD aily standup meetingsnC ollaborative backlog grooming sessionsnS print planning meetingsnF requent demosnP air programming16
AGILE PRINCIPLE 7“WORKING SOFTWARE IS THE PRIMARY MEASURE OF PROGRESS.”Proponents of the agile philosophy are quick to remind us that we’re in thebusiness of building software, and that’s where our time should be spent. Perfect,detailed documentation is secondary to working software. This mentality pushesto get products to market quickly rather than let documentation or an “it’s notdone until it’s perfect” mentality become a bottleneck. The ultimate measure forsuccess is a working product that customers love.HOW IT LOOKS IN PRACTICE:nD esigning and releasing minimum viable features rather than fullydeveloped feature sets means thinking first and foremost about thesmallest things we can ship to start getting customer feedback andvalidate as we continue to build software.nA fail fast mentality means moving forward even in times of uncertaintyand testing ideas rapidly.nS hip software often: a useful product now is better than a perfect one later.17
AGILE PRINCIPLE 8“AGILE PROCESSES PROMOTE SUSTAINABLE DEVELOPMENT. THE SPONSORS, DEVELOPERS,AND USERS SHOULD BE ABLE TO MAINTAIN A CONSTANT PACE INDEFINITELY.”Keeping up with a demanding, rapid release schedule can be taxing on a team,especially if expectations are set too high. Agile principles encourage us to bemindful of this, and to set realistic, clear expectations. The idea is to keep moralehigh and improve work-life balance to prevent burnout and turnover amongmembers of cross-functional teams.HOW IT LOOKS IN PRACTICE:nB efore every sprint, careful consideration is given to the amount ofwork that can be committed to. Development teams don’t overpromiseon what they can deliver. Effort estimations are a common practice insetting output expectations for development teams.nE veryone agrees on what will get done during a sprint. Once a sprint hasbegun, no additional tasks are to be added except in rare cases.nP roduct managers should act as gatekeepers to reduce the noise fromother stakeholders and to avoid squeezing in additional unplanned workduring an ongoing sprint.nP roduct people should do their part in promoting a sense ofpsychological safety across the cross-functional team that encouragesopen communication and freely flowing feedback.18
AGILE PRINCIPLE 9“CONTINUOUS ATTENTION TO TECHNICAL EXCELLENCE ANDGOOD DESIGN ENHANCES AGILITY.”While the agile philosophy encourages shorter cycles and frequent releases, italso puts emphasis on the importance of keeping things neat and tidy so theydon’t cause problems in the future. Product managers often forget about thisaspect of development because they mostly don’t spend their days wadingthrough their products’ codebases, but it is still of the utmost importance to them.HOW IT LOOKS IN PRACTICE:nT he team needs to be cognizant of technical debt and the technicaldebt implications of any new features or initiatives added to the backlog.Developers and product need to work together to understand if andwhen technical debt is acceptable.nO n a regular basis, product will need to allocate development resourcesto refactoring efforts. Refactoring cannot be an afterthought. It needs tobe an ongoing consideration.19
AGILE PRINCIPLE 10“SIMPLICITY—THE ART OF MAXIMIZING THE AMOUNT OF WORK NOT DONE—IS ESSENTIAL.”You’ve probably heard of the 80/20 rule—the concept that you can usually get80% of your intended results with just 20% of the work. Agile principles encouragethinking this way; doing the things that can have the most impact. In a productmanagement context this means having a laser sharp focus on organizationalobjectives and making some cutthroat prioritization decisions. Agile principlesdiscourage building merely for the sake of building by emphasizing the importanceof being strategic and building with purpose.HOW IT LOOKS IN PRACTICE:nP roduct managers need to make very focused product decisions andclosely align product strategy with organizational goals while beingextremely picky about which user stories and features actually make thecut. Using prioritization techniques to prioritize initiatives by effort andpredicted impact is one way product teams can apply this agile principleto product development.nT he short sprints that agile is characterized by present manyopportunities for rapid testing and experimentation, which can helpreduce uncertainty around whether initiatives will truly have thepredicted impact. Using experiments to validate ideas before buildingthem up to spec is a great way to weed out bad ideas and identifygood ones.20
AGILE PRINCIPLE 11“THE BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGEFROM SELF-ORGANIZING TEAMS.”In traditional software development methodologies, you’ll often see pyramidshaped teams where management makes key decisions for contributors. Agileprinciples suggest the use of self-organizing teams which work with a more “flat”management style where decisions are made as a group rather than by a singularmanager or management team. The concept ties into agile’s value of teams andinteractions over processes and tools, and the intent behind the concept is toempower teams to work together as they need to.HOW IT LOOKS IN PRACTICE:nS elf-organizing teams are autonomous groups within the organizationwho take control and responsibility over their respective projects andhave ownership of those areas. Different organizations practice thisprinciple differently. Spotify, for example uses “product squads” topractice this.21
AGILE PRINCIPLE 12“AT REGULAR INTERVALS, THE TEAM REFLECTS ON HOW TO BECOME MOREEFFECTIVE, THEN TUNES AND ADJUSTS ITS BEHAVIOR ACCORDINGLY.”If you’re truly living by agile principles, there is no place for “we can’t changebecause we’ve always done it this way.” Just like we’re always learning newthings about our customers and markets, we’re also learning from the processeswe’re using to learn those things. Agile is not about following a strictly-definedprocess for every sprint and release, it’s about continuous improvement. And thatcontinuous improvement must also extend to processes and teams.HOW IT LOOKS IN PRACTICE:nE xperimentation and testing is not limited to the product only. Agileteams are encouraged to experiment with their processes. You may thinkyou’re already doing something well only to experiment with a revisedversion of the process and discover an even more effective method.Experimenting with your process and team is just as important asexperimenting with the software you’re building.nR egular retrospectives provide opportunities for the team to discusswhat went well, what didn’t go so well, and where the process canbe tweaked to improve things in the future. They’re an excellentplace for product managers and product owners to learn if they arecommunicating effectively with developers and giving them the supportthey need before, during, and after sprints.nA nother consideration to make regarding this principle is that, inorder to practice it effectively, you need to create a culture of trustand transparency that encourages openness and frequent sharing offeedback.22
AGILE IS A MENTALITYWhile we’re all for solving problems and giving structured, actionable advice,we’d like to point out one very important thing about agile before we delve intospecifics: Agile is not prescriptive.Notice how The Agile Manifesto doesn’t outline any specific processes,procedures, best practices, or must-have roles. That’s intentional. A rigidframework for following so-called “agile best practices” would be a directcontradiction of agile values and principles.AGILE VALUE 1Individuals and interactions over processes and tools.The creators of The Agile Manifesto didn’t set out to build a rigid frameworkor a methodology, they set out to build a philosophical mindset for softwaredevelopment. Over the years, countless adaptations of that mindset haveappeared. Several formally documented and widely publicized frameworks foragile processes are widely used today.23
POPULAR AGILE FRAMEWORKSneXtreme Programming (XP)nScrumnDynamic Systems Development Method (DDSM)nFeature Driven Development (FDD)nAdaptive Software Development (ASD)nCrystalnLean Software Development (LSD)nDisciplined Agile (DA)nScaled Agile Framework (SAFe)Despite the broad selection of formalized agile approaches out there, you shouldremember one thing: There is no one-size-fits-all approach to agile. It’s worthnoting that out of those teams who do choose to use one of the many formalizedagile frameworks, the majority of teams end up adapting it to their own needs.Just like the first version of your software rarely functions perfectly, don’t expectany formalized agile framework to work seamlessly right out of the box. You andyour team should be learning and adapting every day.Finally, it’s important for you, your team, and your organization as a whole tounderstand that adopting a framework for agile processes, such as Scrumor eXtreme programming (XP) is only part of your journey to agile productdevelopment.To truly be agile, you and your team must learn to think agile. Use the values andprinciples to guide your thinking. Fail fast. Embrace change. Never stop learning.And remember, you are never “done.”24
2THE AGILE PRODUCTDEVELOPMENT TEAM25
2THE AGILE PRODUCT DEVELOPMENT TEAMWHO BELONGS ON A CROSS-FUNCTIONAL AGILE TEAM?In agile development, your team is everything. For best results, clearly defineteams, roles, and responsibilities before work begins. But, be careful. Ensure youhave a balanced team. If you include too many team members, or include peoplewith the wrong skills, you risk slowing development or spinning off track. And ifyou exclude necessary team members, you’ll face different but equally seriousproblems.your cross-functional product team should includeonly those absolutely essential to each sprint.The ideal cross-functional team includes everyone deemed necessary to shepherdthe product through development, but no one else. This is worth underscoring.You may find that people from different parts of your company want to be part ofthe agile product development team. And they often have the best of intentions.But always remember: Intentions don’t matter. Results matter.The VP of sales might believe they should share guidance based on what salesis learning from prospects. A marketing executive may also think they couldcontribute valuable insight during development. You might even agree with theseexecutives. But they don’t belong on the agile product development team.26
Incorporating outside knowledge and perspective into your roadmap is alwaysadvised, especially under the agile philosophy. But, the last thing you want tocreate is a “too many cooks in the kitchen” situation on your agile team. Instead,part of your role as a product person is to be a liason for stakeholders not includedon the agile team.AGILE PRINCIPLE 5Build projects around motivated individuals.Give them the environment and support they need,and trust them to get the job done.As you know, there are several agile frameworks, and many of them call fordifferent team structures. Ultimately, you need to structure your agile team basedon your needs. Over time as you learn new things, your team structure can (andshould) evolve.To give you a starting point for what a cross-functional agile team may look like,here are a few key players we see in most agile product development teams:PRODUCT OWNERThe product owner bridges the gap betweenproduct ownerproduct strategy and development. They arenusually responsible for the product backlog,n s crummaster, teamleader or projectmanagerorganizing sprints, and are expected to beavailable to answer questions and guidance todevelopers as needed. We will further addressndelivery teamthe role and responsibilities of a product ownernqa resourcesor other “dedicated product people” in thecontext of an agile team in the next section.27
SCRUM MASTER, TEAM LEADER, OR PROJECT MANAGERThis point person is responsible for understanding the big development pictureof each sprint. They are responsible for delegating tasks appropriately to ensurethe right developers are working on the right tasks and that the team is alwaysfully deployed and not idle. The Scrum Master role often involves working with theproduct owner to translate epics, stories, and other items on the sprint list intoactionable tasks for developers.DELIVERY TEAMThe delivery team consists of the folks who are in charge of executing the plan.Typically your delivery team will include the engineers and designers needed tobuild out the items involved in each sprint.QA RESOURCESIt’s easy to forget to include QA resources on your agile team, but they playa critical role in the process. These folks are responsible for testing the itemsin development before they’re presented to the product owner in the sprintdemo. QA resources ensure new code is continuously tested as the product isdeveloped.SHOULD QA AND DEVELOPMENT BE SEPARATE ROLES?While some teams have separate development and QA staff, separating theseroles is not necessary.“ QA is a critical function for every team, but it does not needto be staffed by someone with QA in their title. The idea isthat the team, rather than the individual, owns quality.”— N ick KimSoftware Engineer at ProductPlan and Certified Scrum Master28
STAKEHOLDERS: HONORARY MEMBERS OF THE AGILE TEAMAs we briefly discussed earlier, it’s wise to keep cross-functional teams aslean as you can. This means executives and other stakeholders within yourorganization rarely belong on the team itself. Product serves as a liaison forvarious stakeholders including:nCustomersnProspectsnBoard membersnExecutivesnOther internal stakeholders29
THE ROLE OF PRODUCT
document built on 4 values and 12 principles for agile software development. It's important to note that agile in itself wasn't born then. Its creators, and many other software development practitioners, had long been applying various agile values and principles piecemeal. But The Agile Manifesto made concrete the
