Category Archives: Agile

Feasibility Sprint for Agile Scrum

Sprint, the iteration, is the basic unit of development in Agile cSrum. Scrum puts emphasis on working product at the end of the iteration that is really done (see here for more on done)  something which is fully integrated and ready to be shipped. However, in my initial days of Scum adoption, whenever we started working on a new product-line, we never achieved what we planned for a sprint in some form – let alone something ready to be shipped. Sprint retrospectives revealed that at the start of a new product line or a major feature, the developers made a lot of assumptions on technical feasibility (like third-party APIs, hardware availability) which also affects how the software architecture is shaped. Mid-way of the sprint, we used to discover that some user-stories would be impossible and a few others would take a lot more time that we expected them to. The user-stories were valuable and useful – but did make a lot of assumptions on feasibility. The assumptions remained unverified during sprint planning resulting in a lot of disappointment for all the stakeholders. That led to the birth of feasibility sprint.

What is a Feasibility Sprint? 

A sprint which is designed to uncover the assumptions and lay the foundations for the sprints ahead with a clear understanding of what is possible and time it takes for something that is possible. The common understanding for this sprint was:

  • Time boxed like any other sprint; usually a bit longer than the usual 2-week sprints. For complex product lines, even a 6-week long feasibility sprint is most often worth the time.
  • “User” Stories revolve around testing complex assumptions in order to understand what is feasible technically in the prescribed eco-system and effort involved in making it feasible. Insist on demonstrable proof-of-concept even if it runs from the developer’s IDE.
  • Acceptance criteria: The sprint is deemed to be “done” if each user story can be classified into one of these: (a) Possible to build (b) Not possible to build (c) Possible to build with workarounds (d) Partially possible.
  • Sprint Review: The team “demos” the proof of concept and understands what is feasible and what is not.
  • After-sprint: The Product Owner will have to assess the impact of the sprint on the user stories and backlog by: (a) Re-writing or splitting user stories (b) Re-prioritising the product backlog (c) Communicate to the stakeholders on the shape the product will take if there is considerable deviation in the product feature or if the timeline is way longer than expected.

 

Challenges 

Feasibility sprint is usually an afterthought as stakeholders are optimistic about their assumptions and timelines. Only after burning the fingers in a short sprint does one realize that an item of a sprint needed some feasibility study. Senior team members must have the experience and maturity to identify an item that cannot go into the regular sprint.

If you are not doing frequent Feasibility Sprints in your organization, it might be an indication that you are aiming only for things which you have complete clarity about and taking almost no risks.

Postscript

Feasibility sprint has a close resemblance to Sprint Zero – which is more to bootstrap a Sprint process for a new product.

Rasmus Skjoldan @ ‘The Three Questions for Product Manager’

Rasmus_webRasmus Skjoldan is the lead product manager of Magnolia, the CMS behind sites for the likes of Virgin America, Airbus, Al Arabiya and Atlassian. Before joining Magnolia, he was
the user experience lead of the open source content application framework,
Neos—a challenge that originated from his many years in the TYPO3 community. Besides his CMS work, he co-founded Cope, the first purely content strategy focused consultancy in Denmark. Continue reading

Michelle L. Harper @ ‘The Three Questions for Product Manager’

Michelle L. Harper

Michelle is a Senior product management and product marketing leader with a proven record of accomplishments in leading and implementing product management programs in diverse organizations to create, develop and position successful award winning products. Continue reading

Risk Management in an Agile world

With the craze of many companies and organizations, big and small to jump onto the Agile bandwagon, a few areas of traditional Software development get ignored or trivialized. More often than not, these come back to bite us late in the cycle. In true Agile fashion, teams then scramble to do the best they can to get the product over the line.

One such area of Software Development that sometimes gets overlooked is Risk Management. Traditional Risk management had projects following either the qualitative or the quantitative approach to Risk management. Detailed risk mitigation would be then put in place to ensure that the Risk was well handled. Many times, this placed a considerable overhead on the team.

Agile teams following the Scrum or XP model inherently embed Risk Management. Risks would typically be identified when the team throws up impediments in the daily standup OR fails to meet its Sprint commitment (because of a story being more complicated or having a dependency that failed to fall in place). Whatever the reason may be, Agile teams are pretty good in throwing up Impediments quite early. These impediments could turn into significant risks, more so when they involve external stakeholders and other teams.

In view of keeping the processes light weight, Agile methodologies are not prescriptive about how the risks can be made visible or managed. From a management perspective, the PMO or Senior Management might see this as a flaw in the Agile methodology since they do not get enough visibility about the risks and hence unable to step in at the right time to clear the path.

In such a scenario, here are some tips that would help.

  • If using an electronic tool like Jira or Rally, raise a work item of type ‘Risk’, provide a severity rating to it and put a Blocked status onto it. Assign them to the right stakeholder and publish a weekly list of these risks to the management. Note: Make sure that the key stakeholders have access and are watchers to these risks.
  • If using a physical board, create a 3 x 3 Risk matrix (Probability(L,M,H) vs Impact(L,M,H)) on the physical board, put up the risk and assign the stakeholder’s avatar to it. Take a snapshot on a weekly basis and send it out to the management stakeholders.
  • Report your blocker in the Scrum of Scrums meeting, explain the potential consequences and nudge the management to take action (mitigate, avoid or accept).

In short, the key to an effective Risk management in an Agile world is to make it highly visible, accountable, time bound and easy to action upon.

Are there other light weight and effective Risk management practices that your Agile team follows ??
Do let us know..

Alicia Dixon @ ‘The Three Questions for Product Manager’

Alicia Dixon

twitter at @Li_Li_D

Alicia Dixon is a Product Manager with a specialization in mobile software. Her expertise includes product development, product strategy, and market research. Throughout Miss Dixon’s career she has successfully produced enterprise and consumers products through positions held at leading companies including Hilton Worldwide, UPS, Dell, Blackboard, Fruit of the Loom, Nike & Toys R Us. She holds a Bachelor’s degree from Howard University along with an MBA from Baruch College, CUNY and an MS in Marketing from the University of Alabama. She is an active member of technology  community and sits on the planning committee for ProductCamp DC.

We thank Alicia for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: What is the biggest challenge facing the discipline of Product Management?

Alicia Dixon: In the push for designers to learn to code, and developers to learn design, and everybody doing product, I feel that one of the biggest challenges for product management is staying relevant.  Lately there seems to be a trend that everybody feels that they can do product successfully.  My personal point of view is that this is because people assume that doing product is easy.  I attribute this to the fact that the core skills and talent needed to do product are so esoteric.

You learn product by doing it and you can’t really get it from a book or class.  And there’s no one-method-fits-all approach to building successful product.  Thus, there’s an assumption that since the skill set is so undefined that it’s an easy one to master.  Those of us doing the job know this couldn’t be further from the truth.  We know that creating product is an art form.  And like all good art, you know when it is good or bad, but you might not be able to define WHY it is good or bad.

Unfortunately, there is a growing trend to push product away from working with potential customers to formulate business strategy and into areas that should be handled by other disciplines.  In an effort to clearly define the product role, hard requirements for the job (such as being ScrumMasters, Design Thinking facilitators, and multivariate testing experts) have become commonplace.  These attempts to make the parameters of the role more concrete have actually had an adverse effect; making product roles irrelevant because there are already groups that do project management, design, and analytics.  As those groups claim the job functions that are rightfully theirs and there are no other defined components to the product role, I believe that the result is those disciplines start to question why product is needed.

Of course, product is needed!  Why, you ask?  My answer is to give direction as to what comes next.  Product is out canvassing the streets to uncover the customers’ problems and bring those back to the organization to say ‘here’s an unsolved problem that we have an opportunity to fix’. Understanding the challenges that target users are facing and why of those challenges have significance is the cornerstone of the product management function.  Achieving this requires listening and empathy — two soft skills that don’t translate well into a job description or RACI matrix.  All of this means that the onus is on Product Managers to prove their worth.  Doing that is really hard when we are off doing tasks that we shouldn’t be doing in the first place.

Product Mantra: How best can a product management professional leverage upon the growing virtual community of product professional for his/ her personal development. Would you share some insights on this with our readers?

Alicia Dixon: Social media and online networking have made it so that Product Managers now have a thriving virtual community.  Through my own experience I can say that everyone I have met virtually who works on product has been very welcoming and friendly.  While it is tempting to seek out a relationship with the most popularly recognized product folks, I encourage you to connect with people who work on similar products or within your local area.

My advice for anyone wanting to acclimate oneself with this community is to start by consuming the popular blogs and following thought leaders on LinkedIn and Twitter.  Then start commenting on any post or article that you find compelling.  Share these within your network as well.  As you get more comfortable, create your own posts based on your specific experiences. Finally, don’t stop with the virtual community.  Make connections that you take into the real world.  Meet other product people for coffee, take them for drinks, and attend local meetups or ProductCamps.

Getting involved in this way will not only expand and improve your product knowledge it might just lead to your next opportunity. For example, a good online friend of mine is now slotted to be the keynote speaker at an international conference based on a referral I made. I spoke at the event last year and recommended her to the organizers. I knew that they were recruiting speakers for this year and that she would be great at it, so I was happy to connect them. Most of the product people that I know are eager to help foster the community in this way.

Product Mantra: Which is your most memorable experience from a startup and what do we learn from it?

Alicia Dixon: A key learning that I took away from working in a startup environment was that what is appealing at any given moment can quickly change.  My startup experience was actually at an internal startup at a 90 year-old company.  When I first joined the business, the product that I was working on was deemed the next generation evolution for the company.  It was to be the new and significant revenue stream for the business.  All of the executives were very excited about the new growth opportunity and trade publications spoke highly of the upcoming industry change.  At that time, the product was the core focus. So it was heavily funded.

However, the industry had a hard time moving forward with the adoption of a disruptive technology.  The need to continuously make iterative product improvements was a new paradigm which was not embraced by the company nor clients.  The one-and-done mentality (i.e. build it once, then sell until sold out) was so ingrained in the business that they just couldn’t get past it.  Over time, funding was gradually pulled from the initiative.

So the takeaway from a product sense is that one must continuously scan the marketplace to be aware of the receptiveness to what you are creating.  When you notice it begin to wane, it is time to move on, either to another product within your current role, or to a new position entirely.

Thanks Alicia.

Alicia Dixon on Social Media

  1. Follow Alicia on twitter at @Li_Li_D
  2. Get connected with her on Linkedin @ https://www.linkedin.com/in/dixonalicia
  3. Read her blog http://just1morething.com/

@mathurabhay

Matt Anderson @ ‘The Three Questions for Product Manager’

Matt Matt Andersonbroke into product management as a SME in library software, but has branched out into broader software categories. As a product manager, Matt has recent experience with B2B and B2G products, browser-based and mobile applications, and US and Canadian workforce regulations at several small companies in Salt Lake City. While working from Utah, Matt has worked extensively with offshore teams in India and Eastern Europe. Matt’s product management influences include Alicia Dixon, Rich Mironov, Roger Cauvin, Nils Davis, and the PM Dude. In his spare time, Matt tweets about product management best practices and broad technological trends.

We thank Matt for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: How do you see the role of product manager evolving in the world of Mobile Apps?

Matt Anderson: Mobile applications are often a new-ish product offering for companies that have established core products. In this sort of scenario, the mobile applications are often the most exciting area of development for the organization, while the core products are constantly focusing on the same things over the long-term: performance improvements, features, bug fixes, etc. Mobile products often have a shorter development cycle, a shorter testing process, and a smaller training and documentation effort. For someone who has been working as a product manager or engineer for non-mobile applications, it’s often a relief to move onto a mobile app project.

The learning curve, however, can be steep when you begin to work on mobile applications. Product managers working with mobile should look at and use applications regularly. They should look at mobile design patterns across the software industry. I’ve found it beneficial to carry multiple devices, with multiple brands, sizes, carriers, operating systems, etc. I’ve carried devices that were cheap or old when I thought the users may not use the latest and greatest. A product manager will have trouble balancing all of these conflicting concerns, so I’ve found it is good to rely on short release cycles, consistent beta releases, and constant feedback loops with users to release successful mobile products.

If I were to hire a product manager to work on a mobile application, I would look for a high-performer who was actively trying to understand (1) industry standards of UX design, (2) best practices for customer interviews, and (3) best practices for Agile. I’ve found that a solid background in product management and UX is a primary qualification for a mobile product management role, while experience in the mobile application space is a secondary qualification.

Product Mantra: How often do you conduct competitive analysis, and are there any methods that you can share with us?

Matt Anderson: I crawl the web daily for competitive insight in my industry by using Paper.li and Talkwalker Alerts. I think that establishing a constant flow of competitive data by using these tools is a great way to keep a constant dialog with your product management, marketing, and development teams. If I hear that my competitor’s Mobile App X is integrating with an API Y, I want to share that info with my team right away. That’s a daily competitive analysis, which may not be for everyone, but daily crawling is definitely my style. And if you use this strategy, don’t forget to pay attention also to your competitors’ major customers, because they drive your competitors’ strategy.

While I gather far more competitive insight from the web than from other means, the most valuable data is not always available on the web. I received one of the best pieces of competitive data in my career by attending an industry event and hearing that a government agency had worked with my competitors A, B, and C to draft legislation for my industry. Not all information is published to websites, Twitter, and LinkedIn. You need to be where your industry influences are, be where your customer base is, and be where your partners are. Visit your customers regularly, attend industry events, and you’ll work your way to the center of your industry.

I always find that the data that you gather from the competition over time needs to work its way into a higher-level analysis that compares your product offering with the competition. It could be a spreadsheet that shows feature quality for you and four competitors, or a spreadsheet with predictions of what each competitor’s feature offering will be in 2 years, or a pricing analysis in a spreadsheet that recommends dropping your price by 10% to improve your win-loss ratio. Take your competitive analysis and make it consumable by your executive team.

Product Mantra: What would be your suggestion for 3 Do’s and 3 Don’ts for Product Managers?

Matt Anderson:

Don’t just tell people what they want to hear; tell them what is going to happen. Don’t just say “yes” or “that’s a great idea” if you aren’t going to do it now. Tell them the real plan, and you’ll promote openness and trust.

Do work for your organization; not your department. As much as you can, be the best value to your organization. That means breaking down unnecessary interdepartmental silos and establishing a cooperative environment.

Don’t be the primary tester for your product. Sure, there are reasons why it can be a good thing. First and foremost, it is a great way for a product manager to understand the product and how it is used. However, a few of the consequences that arise from having product managers as the primary testers are impacts on the development process, conflicts of interest, and impacts on the performance of the product manager.

Do put your executive hat on. It’s not only the dev team and the user that matters…make sure that your product strategy is in line with your executive team’s expectations. Do it on a monthly basis, if possible.

Don’t gather the stakeholders and let them duke it out over what the priorities for the product are. You are being paid to make decisions about the product, not facilitate others to do so.

Do participate in the #prodmgmt community. I’ve learned so much from my colleagues in the product management community. I’ve met dozens of product management folks through my use of Twitter who have made my career and my life more fulfilling.

Thanks Matt.

Matt Anderson on web:

  1. Matt Anderson blog www.mattanderson.org/blog
  2. Twitter http://twitter.com/MattAndersonUT
  3. Linkedin http://www.linkedin.com/pub/matt-anderson/23/888/879

@mathurabhay

Rich Mironov @ ‘The Three Questions for Product Manager’

Rich RichMironovMironov needs no introduction. He is veteran in product management and has provided full-time and short-term product management consulting to more than 75 tech companies. We thank Rich for taking out time from his busy schedule to be part of ‘Three Question’ series for product managers.

Product Mantra: Which experience is more valuable for a product manager, sales, marketing or engineering? This considering that most professionals make their way into product management from one of these three functional roles.

Rich Mironov: Product managers need a balance of experience. For PMs who were previously developers/technologists, their engineering backgrounds are already solid. But They typically have little marketing/sales experience. They need to shore that up by sitting in on sales calls, digging into lead gen statistics, scouting competitor products, working out customer ROI models, trying (and failing) as a copywriter, listening in on tech support calls, etc. An ex-developer’s most likely failure mode is to assume that customers care about the finer details of features and interface, and that the buying process is rational.

Likewise, ex-marketers already understand messaging and channels, but will need a lot of technical street cred to work successfully with development teams. They should learn about software architecture, code-and-test processes, technical debt, and how much harder it to BUILD stuff than TALK ABOUT building stuff. An ex-marketer’s likely failure mode is wildly underestimating the effort to add (even small!) features, and to make customer commitments without agreement from development.

Etc. None of us comes to product management with a balanced experience base. We have to get out of our individual comfort zones to fill in the gaps.

Product Mantra: Thousands of products are being developed worldwide every year. Unfortunately most of them fail in their purpose. What are three most common blunders committed by product managers in early stage of the product development?

Rich Mironov: IMO, most products fail because their target buyers aren’t sufficiently interesting in the new product. We talk ourselves into believing that prospects are much more excited than our objective evidence indicates. Three common forms of this overall blunder:

  • Willingness to build just what we’re told to build, as described by executives or salespeople or developers. Over and over, I see products in development that “our CEO said that people wanted,” or that make sense on paper, or that only one customer demanded. Every product manager should gather first-hand input from a few dozen potential buyers in the actual target segment – and confirm that the specific product has a paying audience. (As Steve Blank says, “Get the heck out of the building.”) Our job is to validate other people’s seemingly good ideas.
  • Not having a back-of-napkin revenue model: vaguely how many units do we need to sell in the first couple of years, at what price, to justify our expensive development team? Does Sales or Marketing agree that these projections are reasonable? Has any player in this market ever achieved similar sales results? Too often, I see companies spend $M’s in development without running the basic financials.
  • Assuming that product management is the best source of good ideas. Our job is to make sure that good products are build and good decisions are made, not to be the smartest folks in the room. Some terrific ideas (and a lot of bone-headed ones) come from developers, from channel partners, from customer suggestion boxes, from executives, from competitors, from analysts. We need to filter the incoming stream, discard the obviously useless 95%, and have the best thinkers in our organization give the interesting 5% a thoughtful review. And then validate-validate-validate the proposed mix of features/fixes/new products. We leave our egos at the door.

I see fewer products fail because development is hard (which it is) or because most releases are late (which they are). No matter how great our engineering teams are, they can’t save us from mediocre or stupid product plans. So the most wasteful thing we can do is excellently build a market-failing product.

Product Mantra: How soon should a start-up hire a product manager or for how long a founder(s) should continue playing the role of a product manager.

Rich Mironov: I usually recommend that a start-up hire its first professional full-time product manager when it hits 12-20 people.   That’s when the informal communication overhead of a 6-person company (everyone sitting around one table) breaks down, and everyone is suddenly having trouble staying current on customer commitments, priority priorities and development capacity. Someone (a product manager) has to provide just enough process so that the development team can stay productive. See a recent 45-minute talk of mine on this: http://www.mironov.com/startuppm/ .

This can be a very touchy discussion, since founders SAY they want to give up day-to-day control over product details, but rarely ACT that way.   They’ve been making every single feature/UI/architecture decision early on, as the company sailed past a series of potential disasters, and that worked well when things were small. Changing their management style and operating model is VERY difficult. Newly arrived product managers at small start-ups have to earn the trust of the founders by handling increasingly important decisions in full view – so that founders can slowly relax their grip on every button placement and color choice.

About Rich Mironov: Rich coaches product executives, product management teams and agile development organizations. He is a seasoned tech executive and serial entrepreneur: the “product guy” at six start-ups including as CEO and VP Products/Marketing. Read more.

@mathurabhay