Category Archives: Agile

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