Enterprise MVP - Made in Captives and ODCs

The 5 steps listed below are from the session: Design MVPs (Minimum Viable Product) for Enterprise Customers by Owen Rogers from Pulse Energy. This talk was given at the Management track of the Agile India 2013 conference that was held in Bangalore, India on Feb 27, 2013 and Feb 28, 2013.

To build Enterprise MVP

Step 1: Start with fixed known constraints

Step 2: Defer commitment on everything else

Step 3: Leverage external products and services as much as possible

Step 4: Start simple and iterate quickly

Step 5: Tell a compelling story - user journey - focus on workflow not features

So can Agile teams in captive centers and in outsourced product development centers (ODCs) truly contribute to building MVPs?
For the large part, this ask may be a challenge since in captive centers the product manager is located onshore or in the parent company and in ODCs teams may be far removed from the real users of the solution when the real users are the customers of the client.

I recommend these three initiatives to enable Agile teams in captive centers and ODCs to contribute effectively to the whole process of building enterprise MVPs:
1. Build domain expertise
2. Create opportunities for customer contact
3. Have the product manager travel to the Agile team locations at significant milestones

Building domain expertise leads towards:
- building a knowledge base from which requirements can be validated
- ideating based on the knowledge gained about the painpoints and customer workflows
- increasing confidence in the solution
- actively contributing in the release planning phase

The organization should make allowance for teams to engage with customers face-to-face in user group meetings and product conferences. When the big picture of why they do what they do becomes clearer to teams I believe that Agile teams will be able to create realistic acceptance criteria,  simulate the right deployment environments, and identify customer candidates and/or scenarios for usability tests.

For every sprint 0, the Product manager can travel to the location of the Agile team which would help in:
- face-to-face communication which trumps the greatest advancement in telepresence
- providing an opportunity for Agile team members to directly contribute to the product backlog by making their suggestion, backed by research, to the Product manager
- optimizing the time taken for initial product backlog refinement
- building an Agile team that includes the Product Manager as the Product Owner

These recommendations are drawn from my experience as a Product Owner for Pivotal CRM at CDC Software (now Aptean).

Got 'em on the Same Roadmap

Sharing an account of a product release strategy in response to a situation that triggered the release. This is a first person account as a Product Owner.   

Scenario: 

A B2B CRM company, with a common platform on which were built add-ons for Financial Services, Marketing, Service/Support, and Homebuilding acquired a marketing product, (called MP for simplicity). MP had a loyal customer base renewing maintenance contracts annually and demanding new features to support their business.

Problem: 

• MP and the flagship CRM had independent roadmaps which brought challenges when aligning Sales and Marketing with the release pitches. 
• Features on MP were overlapping marketing features already available on the flagship CRM product. 
• Customer sentiment was that with the acquisition MP did not get as much attention as required to cater to their needs 
• New customers preferred the flagship CRM product 
• Share of the revenue that MP brought in was declining 
• MP had a dated technology base
• MP's user interface left much to be desired
• Cost of deploying MP on a hosted environment was high
• MP's support for mobile was text-based

Goal:

Bring the zing back to the marketing vertical

Time constraint:

Deliver in 3 months

Strategy:

To build a marketing automation add-on to the flagship CRM that included the most valued features from MP and the existing features on the flagship CRM.

Roadmapping activities in this approach:

1. Reviewed the features of the flagship CRM so that the marketing add-on includes an enhanced version of MP's unique features, and removes duplicate features
2. Worked with the Gartner analyst for Marketing to understand the industry trends and marketing automation vendor selection criteria
3. Reviewed support incidents of MP to understand the painpoints
4. Included the migration and feature integration plan in a common roadmap

Customer retention activities in this approach:

1. Offered the flagship CRM product with its hosting capabilities, mobile support, and improved user experience to MP customers
2. Drew up a migration plan with tools so that customers can confidently migrate their data to the flagship CRM with the marketing automation add-on
3. Presented the common roadmap

Post the roadmapping activities, worked with architects, user experience specialists, and the development team to design and deliver the first release of the marketing automation add-on in 3 months. The first release included the most important features of marketing automation that could be delivered in 3 months by 1 development team.

Results:

The Marketing Automation add-on:

• Was well-received by existing and new customers
• Moved back into a top revenue earner on the flagship product as well
• Received rave reviews from market analysts

The Product Manager and the Agile Testing Strategy

On an Agile project, the application is being built incrementally with every sprint adding to the functionality. As a result of this approach, Developers are constantly adding to the codebase impacting the existing functionality. While Agile software development ensures faster time to market and greater transparency for the stakeholders, it also stands for finding defects earlier in the cycle and raises the bar for quality. Agile testing requires QA engineers on the Agile teams to test quickly, incrementally, and contextually while staying within acceptable defect limits. In this scenario, an Agile QA engineer employs "smart" testing strategies and tactics to meet the demands of an Agile project.

Smart Testing

Smart testing requires the application to be tested incrementally - meaning while the user story is being coded, the QA engineer plans for the test cases and scenarios in the immediate vicinity of the story and tests the application as soon as the developer is done coding. Individual user stories are tested in this manner and when the build is created for the sprint scope then QA accepts the build, regresses the system, and skims over the user stories of the sprint with greater focus on the impact on the surrounding areas of the functionality delivered in the sprint.

As you can well extrapolate, this approach can add to the quantum of build level testing that is done in successive sprints. To optimize on the testing scope vs effort, another facet of smart testing, which is testing prioritized system workflows is undertaken. Testing in this prioritized order while optimizing the effort does introduce some risk which can be handled to some extent by doing adhoc testing around the major workflows.

Product Manager's Contribution

The Product Manager's contribution to the smart testing approach is to validate the workflows that are being tested and ensure that the tests cover features that are indeed the major workflows at the customer end. This validation begins with the review of the Test Plan that QA comes up with at the end of the release planning or sprint 0. The validation continues on during the iteration while reviewing the scope of coverage of the test cases at the user story level. The validation concludes when looking through the prioritized list of major workflows that QA plans to test as the functionality scope increases. 

Additionally, during acceptance testing, the Product Manager can take into cognizance the scope of QA testing and review the product against the acceptance criteria. 

The Product Manager is able to collaborate with QA on the testing strategy by drawing on his/her knowledge of: how customers use the product, features that pre-Sales demo to prospects, the features that are obligatory requirements, and those user stories that effectively out-pitch the competition and find favor with analysts.

In case of a complex product, it may not be possible for a Product Manager to be involved with the Agile teams everyday. In this scenario, the Product Manager's contribution can be scaled by taking the help of a proxy Product Owner who works closely with the Agile teams.

In this way, a Product Manager can ensure that the Product is being built right by having a stake, albeit minor, in the testing strategy of Agile teams.

Challenges in conducting Agile Assessments

Some challenges that the Agile Center of Excellence could encounter when conducting Agile Assessments, including suggestions to move past the challenges.

1. When teams look at the assessment as an audit, there could be cover-up and manipulation. An Agile CoE can counter this by stressing on the role of the assessor as a Coach and not as an auditor. For his/her part the assessor should work with the team towards implementing the identified Agile areas of improvement so the assessment is a measure of collaborative effort on the part of the assessor-Coach and Agile team.

2. When a single Agile coach has to cater to the assessments of several teams, it spreads the coach too thin. I dont have a golden number which limits the team-coach ratio, but íf there is a situation where one coach has to work with over 4 teams, then the coach could have the Scrum Masters intervene on their behalf. This approach can help mentor Scrum Masters who can mature into coaches. The flip side would be the added delay and loss in transmission through the Scrum Master to the Agile teams.

3. Continuing on handling the coach-team bandwidth challenge and coupled with coach succession challenges, another approach could be to have a team of Agile assessors essentially members of CoE who are Scrum Masters do the assessments. This approach could help ease a single Coach's onus and build assessment abilities in other scrum masters or coaches.

The Assessor-Scrum Masters begin by observing the team in their work environment and ceremonies, followed by an assessment, and concluding with an action plan as agreed with the Scrum Master of the team being assessed.

The Assessor-Coach should stay with the team for at least 3 to 5 assessments so that they get an opportunity to implement Agile ideas and report to the CoE about the plans ahead for each team so that the expectations from the organization are met.

Agile CoE - Getting Started

In my role as a Program Manager I have played the role of a Change Agent at roll-out and post roll-out stages of Agile practice in an organization. I hope to share my experience in multiple posts on various aspects of setting up and managing Agile programs. This post talks about setting up a team of agilists who will sustain Agile, called CoE in common parlance.

After organizations have crossed executive buy-ins and Agile roll-outs across teams, sustaining and enhancing the Agile practice is the next milestone in an organization's journey. A team of agilists who are passionate about implementing agility and look for ways to sustain agility in a demanding work environment can step in to sustain and enhance the Agile practice.

One approach is to invite volunteers from across the organization who are passionate about Agile and don’t need an external push to take on this role of developing the Agile competency. I say developing the competency because there is a constant demand to derive an Agile approach to situations and issues that the Agile teams encounter. Failing to have a go-to forum for Agile queries could lead to teams slipping back to pre-Agile ways. Besides Agile may be blamed for the current issue and a general suspicion towards adopting Agile practices may ensue.

The disadvantage with a volunteer group of agilists is the fact that they are a virtual team moonlighting for Agile. When pressures from their primary role mount then they may not be able to sustain their energy towards the voluntary Agile evangelist role. Another reason could be the “whats-in-it-for-me” – when the entire Agile evangelism is considered pro bono by the organization. Third could be recognition and acceptance of intervention in Agile teams – which could be low in the absence of an organizational recognition of the team of volunteers.

The second approach is to put together a formal team of Agilists who are tasked with sustaining and developing the Agile practice. This team could come up with a creative moniker to move away from any negative connotations of Center of Excellence or Capability Center or Competency Center. Again a frivolous name in a formal culture could water down the effort of the formal team. So depending on the approach that would give greater acceptance, the formal team could choose its name.

For the purpose of this post and others related to the same topic I’d like to stick with CoE since this term seems to be commonly recognized.

Who comprises the Agile CoE?

At least one full-time member, Scrum Masters, and Product Owners

What should the CoE work on?

• Self-driven approach
• Engage in a visioning exercise that results in goals and roadmap for the CoE
• Inspect and adapt

What activities does a CoE undertake?

• Sharing learning and success stories
• Training or co-ordinating sessions on processes and tools
• Connecting with the Agile Community
• Evangelizing through active blogging and creative meetups
• Hands on coaching
• Measuring the value added by the CoE

How long should the CoE exist?

Until the organization believes that there is more to be done in the course of Agility, which I think is a continuous journey of incremental improvements

Getting Agile to Middle Managers

Middle managers are an essential layer in an organization; this layer comprises of leads, and managers who have greater proximity to the development teams and are responsible for project delivery. The middle management layer provides an incubation ground for senior management equipping managers with essential leadership skills for greater responsibilities. The Agile transition should include in its ambit, the ambitions and insecurities of middle managers  to ensure that the Agile rollout is successful, sustained, and enhanced to higher levels of productivity. Following are four areas which require an Agile flavor to win the support of middle management.

• Career progression – With Agile being an equalizer and tilting the balance in favor of the “doers” the key performance criteria of Lead and above, across disciplines has to be re-evaluated since tracking and assignment are no longer in the purview of managers. Managers and Leads may be threatened by the perceived power of Product Owners and the importance of Scrum Masters. Their responsibilities need to be recast into that of a coach and mentor, they could be encouraged to get back in touch with a hands-on approach, or perhaps take on a strategic role that determines the course of the development team.

• Clarity of role - Traditional responsibilities may overlap with the new SCRUM roles, Scrum Master and Product Owner. Some managers may fall back to the traditional way of managing teams and this could led to conflicts with the persons donning the Scrum Master and Product Owner roles. As part of the Agile practice, managers should have a forum to discuss the areas of conflict and resolve it in a manner that promotes Agile. Development teams may also require clarity on the roles so they can approach the right roles for support.

• Grooming development teams - Middle managers are also vested with the responsibility of reviewing and guiding the career progression of development teams. With Agile, Managers must remove extra status meetings and stay tuned to the team and individual's progress through daily standup, and information radiators. This being an indirect method could be a challenge for managers to assess and guide development teams. As part of the Agile Transition, middle managers should discuss with the Agile evangelists ways of evaluating individuals without jeopardizing the team collaboration.

• Frame of mind - Agile calls for middle managers, among other agilists, to adopt servant leadership which involves selfless service to build the development team. The middle management team needs to be coached and supported along their servant leadership journey.

Career progression, clarity of role, grooming development teams, and frame of mind are by no means an exhaustive list of areas that would require intervention during Agile Transformation. However these four areas are the bulk of the Agile Transformation plan for middle managers.

My Top 3 Areas that Product Managers Adapt with Agile

In a product development organization, product managers are placed at the center of the productizing process. In this capacity a product manager strategizes the product's path to development culminating in bringing value to customers and profitability to stakeholders and business owners. When development teams adopt Agile, the Product Management team should also be brought under the influence of Agile values and principles because the Agile team is dependent on Product Managers for direction with respect to "what to build."

Here are my top three areas which Product Managers must adapt to flourish in an Agile environment:

Roadmaps – Product Managers own roadmaps and this artifact in a Agile environment needs to be reviewed with the Agile team at the end of every cadence (release) so the team can align itself with the next prioritized item and at the beginning of every cadence in order to set priorities. For their part, Product Managers need to be aware of the release cycles of Agile teams and ensure  that the market research and other activities leading to executive buy-in and budget approvals are in time for the Agile team to start working on the release.

Increased Transparency -  User stories are based on the value that it brings to the user. This value is explicitly captured in every user story after the Product Manager talks with customers and analysts, and researches the market factors. Every person on the Agile team is encouraged to question the value of the user story which requires the Product Manager to have a granular understanding of the impact of a user story on customers and the market. 

Sales and Marketing Interactions – A Product Manager needs to train marketing and sales teams through demos, documents, and conversations on the products and its features so that there is effective messaging and lead conversion. In an Agile world, the Product Manager can prep the sales and marketing teams with confidence since he is aware of the nearly releasable features that are being churned out by the team sprint on sprint. 

Presented this topic at Agile Tour 2012, Chennai, India