Writing Requirements for innovative IoT Products - Part 1

Thanks to the growing interest in the Internet of Things (IoT), I was inspired to write this blog to show one way to manage these requirements in an agile fashion.  Being the good product owner's we are, we will have done due diligence on the technology being used and the steps to making a thing enabled for connectivity to the internet, (recommend lynda.com IoT) Then balance your business and product knowledge to craft valuable sized-right chunks of work.

I have always been a huge fan of connected car technology since I can remember so I am going to make this example exercise fun by writing requirements for the following product vision statement:

Improve the transporting experience for people with long commutes during high traffic volumes.  As a car manufacturer and technology company, we believe it is our responsibility to make the roads a safer place and while doing so, protecting your personal information.  

This is a big vision but all the market industry trends tell us this is where we have to innovate so where do we start without established customer feedback?  Lets assume our product marketing manager says the majority of our customers are parents with children, our sales manager says if we can offer more compelling safety features, we can take back the largest portion of lost revenue.  The architect is confident he can deliver any idea we come up with because we are using GE's predix platform and have the best electrical and software engineers on the planet.  So everyone has ideas but nothing to form a product release, so we hold brainstorming sessions with a bunch of smart relevant people in hopes of forming a backlog of features customers will love.

Thanks to excellent facilitation skills, group engagement and homemade cookies the session results in some great ideas.  I want to stress how important this brainstorming session is to the overall story writing creative process.  Record the conversations so you can capture all the everything so later if you want to document more details to your items you can.  Here are the top voted ideas, already prioritized by business opportunity:

• I want to know if any drivers near me are using their mobile phones while driving so I know to use caution near them 
• Ability to self-diagnose the most common maintenance issues leading to accidents or break downs
• Ability to use caution near someone with a poor driving history
• Ability to park in the safest place(s)
• I want to stay clear of anyone who just left a bar
• I want to know the safest route to work and the safest time to leave home
• If my husband and I are leaving work at certain times, we want to know who has the best route to pick up the kids and who should stop by the grocery store where the items on our smart refrigerator list have the lowest total cost.
• Ability to know who has a criminal history for violence or stealing cars so I can decide if I want to park there

Our architect takes a look and says a few of these can be done at the same time reusing the same sensors, connectors and fairly straight forward.  He says some of these require us to have our blockchain solution in place to decentralize the network, we decide to plan for dependent features in the next release.  He adds some enabler features that need to be done to help us prioritize the backlog and understand related costs.

• Ability to decentralize the network to control connectors in a meaningful way
• Use cryptonets to enable machine learning and make accurate predictions
• Implement framework for total security of all connected devices

Now that our product backlog has some big chunky prioritized items, we have a story writing workshop with the team and use techniques like user story mapping to identify a minimum happy path of functionality. Our product manager says our product management team can sell any grouping of features, the strategic goal is to choose the lowest risk items so we can demo a working product to our executive team.

Work with the delivery team to sketch out your vertical user story blueprint.  This might include technical layers suchas UI, sensors, connectors, etc.

Stay tuned for part 2 to read the rest.

What makes a good Agile Product Manager/Product Owner?

It depends on who you ask and where you ask it.  Over the past 8 years I have been exposed to a myriad of industries, coaching agile product managers/product owners (APM/PO) on their new role and influencing organizations to consider product model structuring. I want to share the most common success patterns I have seen so far.

The most common success patterns are surprisingly simple in theory yet hard to balance for some brilliant people. The following is my top 5 but certainly not conclusive list.

1. Entrepreneur Spirit.  The APM/PO is the team(s) leader.  She is acting CEO, protecting the company's product or services as if it were her own money being investing. 

2. Leadership. Takes responsibility and leads by example. Facilitates the best possible course of action and garners buy-in from the right people. Self-aware and able to make decisions.   

3. Inspirational.  She is the most excited person in the room and glimmers with passion for the product vision. Always ready to back up decisions with convincing evidence and respecting opinions when provided.

4. Customer centric. The APM/PO doesn't neccessarily need to be the expert in all things, but understands the need for experts in customer journey mapping, user experience design, market research, customer trials and feedback groups.

5. Organized. Understands the process and aligns herself to the best possible business outcome.  Coordination between large groups and getting results out of a large system requires skills and knowledge of the process.

Some folks might be thinking I forgot to include knowledge about the product.  I think this is important but I think a great APM/PO leverages the expertise of those that are closest to the subject.  One cannot be an expert at all things but one should have the wherewithal to make smart decisions immediately and when to facilitate feedback for riskier decisions.  After all, shouldn't we all be listening to the market and other reliable sources of intelligence?  Shouldn't we never stop learning?

So what makes a good agile product manager/product owner? Someone who can balance their act between the 5 patterns listed above.  Some organizations are not mature enough for the highly evolved APM/PO, so organizational skills are valued more than inspirational.  Some organizations are trying to disrupt the market so the entrepreneur mindset is more attractive than someone who follows process.

The Product Owner role in SAFe

The Product Owner role in SAFe.  Many organizations that have experienced the benefits of implementing scrum at the ‘team level’ do not realize that Scrum scales too and that most well practiced Scrum teams would scale appropriately over time.  These organizations prefer to implement a prescriptive approach that allows an organization to map their current structure to something tangible with structure.  Personally, I think any movement toward agile is a good move so long as the organization keeps trying to do what is right for the business and the people.  This blog is about how to implement SAFe’s content authority roles when organizations have already scaled scrum.

Why did I decide to write this?  After years of being a very effective Product Owner and Agile Coach, I paid top dollar to get SPC certified by Dean Leffingwell in Boulder, CO on SAFe v3.0.  I learned that the product owner group was represented quite a bit different in SAFe.  Product Management and other management level roles own most of the content authority, which means they assign value and prioritize all work.  Product owners do not write features and they do not decide what features are developed.  Product owners take direction from Product Managers whom of which are part of product management.  The team gets to interact directly with the Product Managers and Business Owners every Program Increment.  The Product Managers interact and coordinate higher level decision makers consistently.   In short, the SAFe product owner does not need to have the technical, marketing or sales wherewithal to prioritize the team backlogs.

How does Scrum scale? In simple terms, scrum scales the product owner role and the product backlog enforces There is one roadmap and one product backlog.  (SAFe would call this the portfolio backlog).  Alignment and prioritization via a bi-weekly MetaScrum meeting with all stakeholders and management.  The product owner hierarchy may include feature or application product owners all the way up to the Chief Product Owner whom is an executive with fiduciary decision making capability.  This person is responsible for understanding the total cost of ownership and financial impacts.  All levels of product ownership team utilizes product management members as advisors to prioritizing the backlog.  The product ownership team interfaces with customers and stakeholders but must be available to the teams.

Let’s assume that all the content authority roles in SAFe need solving for the advanced Scrum practitioner.  The Content authority roles in SAFe include

•         Program Portfolio Management and Epic Owners
•         Product Management
•         Product Owner

      Scrum to SAFe content authority roles

•         Program Portfolio Management and Epic Owners > Chief Product Owner
•         Product Management > Product Ownership team + Agile Product Management
1. -  Product Ownership team (Includes the entire hierarchy from Chief to feature product owner)
2. - Agile Product Management (Includes Product Marketer + Product Strategist + Product Technologist)
•        Product Owner > Feature or Component Product Owner

New Year Resolutions

As a product owner, I have specific New Year resolutions to make me a better leader to my team(s) and contributor to my company's success. 

To be a better leader to my team, I will schedule recurring chucks of time to groom the backlog and hold all invitees accountable to show up. No more excuses.  I will reflect on retrospectives that surfaced blockers I failed to resolve and action plan for the highest valued items. I may even learn something new about the team along the way.   

To be a better contributor to my company's success, I will look for simple solutions to gain sizable wins and ensure a competitive product vision is in place that aligns with the strategic overall goals.  I will forge relationships with end-users and/or customers.  

To all you new product owners or product owners surviving in transitioning organizations, keep learning and be energized this year.  The single greatest value you can offer anyone is energy. When change is underway and most are feeling sluggish, you be the one that keeps spirits high.  How does one keep themselves energized?  Get good rest, exercise, healthy diet and positive thoughts.  Read about taking good care of yourself and the recipe for energizing yourself in order to energize others comes naturally.

Happy New Year my esteemed Product Owners and fellow agilists!

The Role of a Product Owner in Transitioning Organizations

So you are a product owner in an organization that wants to be agile but doesn't have the organizational infrastructure to enable and empower you.   The primary role of a product owner is to ensure product is delivered with the highest business value first within the shortest release horizon with the highest quality code.  To do this, the product owner must have the ability to negotiate with customers and stakeholders while continuously prioritizing the work consumed by product delivery teams.  If you have practiced 'real' agile, you understand that the role of the product owner is the most challenging to adopt in an organization undergoing an agile transformation.

The roadmap to a mature product owner role can be correlated with the agile adoption transitional stages learning, improving, sharing and innovating.

Learning Stage

In this stage, teams are barely forming, receiving training and coaching.  If teams can't demonstrate that they can execute agile practices, the transformation will fail.  The role of the product owner will not scale past the project level and this person maybe formerly have been a project manager, product manager or business analyst.   Simply prioritize the team's work and limit work in progress. Stop starting and start finishing tasks.

Improving

In this stage, teams are practicing all the fundamental agile ceremonies.  The role of the product owner might reach the program level and you can influence all functional areas by keeping everyone aware of the product vision and the roadmap to get there.  You still may not get to influence the priority of work intake but you can make business value goals visible to all. Talk about it hang up posters about it, your job is to simply make aware and elaborate.

Sharing
In this stage, many agile teams are stoodup and the pilot teams are sharing templates, meeting logistics, process documentation, tool configurations and other lessons learned.  Typically this means leadership members are convinced for at least one business unit and are more willing to provide for environments and cultures that agile practices thrive in.  The role of the product owner may even be at a director, VP or even C Level depending on the size of your organization.  This product owner may be able to control the portfolio of work and investment models. 

Innovating
In this stage, agile roles are scaled from the team to leadership levels, thus providing alignment from top to bottom by default.  The role of the product owner is setup to reach maximum potential by delivering products that can change the world, wipe out the competition and attract the best talent.

So you see, the role of the product owner has a place in every organization we just need to be patient with immature organizations and coach anyone that presents teaching moments.  

When vertical user stories become not so vertical anymore

Vertical user stories imply that all necessary work in the database, service and UI layers will be testable and verified by the user.  In fact, any story written by an end-user is typically a perfect vertical story that will result in business value delivery.  So what is the big deal?  Most agile teams break their stories down into horizontal slices that independently provide no business value.  Vertical stories are keystone to reducing time market while tracing financial impact end to end, which is kind of the whole business case for investing in agile adoption in the first place.

So when do vertical stories become not so vertical anymore?  Top reasons include:
1. Organizational structures that have separated groups by each horizontal layer in their vertical story.
2. System architectures that are so complex and distributed, it takes months to get information from the right people and to coordinate an end to end testing effort.
3. Poor portfolio management where priorities are not aligned across groups and highly specialized skills are spread thin
4. When teams are unwilling or unable to change their mindset from big bang delivery to iterative delivery.

Example 1:
A financial services company has three separate business units that either support back office, middle office or front office.  The teams working in middle office never interact or have knowledge of the customer.  The business units only interact at the senior vice president and above levels.

Example 2:
The system architecture of a telecom company has not been able to automate their transactional processes.  Many different functional groups try to automate and the data gets stuck in one of the many third party applications without ever synchronize to a single customer record.  Manual processes must fill in the system gaps and the end user is not able to see the data.  Synchronization would require coordination with all internal and external partners.

Example 3:
A program of teams is working in a vertically structured organization, non-legacy systems, and the solutions technology portfolio is complimentary.  The only problem is leadership's inability to limit work in progress and spreading the talent too thin across initiatives.  Too many projects in a program eventually will cause their own impediments.  Teams get impeded, stories are put on hold and they start something new until an older story is unblocked.  No stories ever get done in a given timebox.

Example 4:
A team practicing waterfall is forced to adopt agile iterative delivery but they can't seem to get over the incremental development mindset.  They may not even have the skillset or information available to do anything but complete one of the layers.  The idea of re-work is a negative outcome so they work from their own task list without ever really working from the user stories.

If you relate to reasons 1-3 and you are not a decision making stakeholder, simply get as vertical as you can possible get for your business and system context; otherwise, you have the power to directly impact time to market.   If you fit into reason 4, identify what you think your constraints and limitations are and simply validate them as logical. Better yet, if your mindset is the problem, reach out to other previous non-believers and find some rationale to change that resonates with you.

Scaling the Agile Enterprise - Seriously folks, it is really just ONE backlog we all plan from

Add caption