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

Akrasia and new agile teams

Akrasia. Traditional command and controlism cultures can make people depressed. Knowing that you 'should' do something without necessarily deciding to do it. Like considering changing habits, the 'considering' feeling never goes away and imprints real estate on your brain.

Early adopting teams with poor leadership leads to depression.  Scrum will surface issues but it will not teach you how to fix them.  Sometimes ignorance is bliss...

SevenTablets First Happy Meter Results

As promised in my July post “Are Your People Happy?”,  I am sharing our own company wide happy survey experience with our trusted readers.  The happiness metric has always been maintained in product development but I received buy-in from leadership to administer to all members of our company community.   We followed all the guidelines in the July posting and ended up with an overall score of  4.4 out of a perfect 5.0  with an accuracy level of about 86% confidence.  In addition to the ratings, about 80% of the members that did participate in the survey results provided suggestions on what we should either ‘stop doing’ or ‘start doing’ in order to benefit the team and/or company overall.

User-Centered Design: Part 1 – New Software Development

The majority of our consumer market today expects software to be a service along with cloud access to data on any mobile device platform.  As software provider’s, we must extend our user-centered design approach to include mobile device views out the gate.  Most credible resources on interactive graphic design will use software providers LinkedIn, Google and Facebook as examples of great mobile user experiences.  I agree, but would these web leaders have made the same design decisions had they started out with a device-centric approach?

When Are Agile Requirements Ready For Development?

As a product owner on an agile development team, I am responsible for populating the product backlog with a list of user stories to communicate the product direction.  In layman’s terms, a traditional lengthy requirements document is broken down into small parts that are formatted into a simple story told by the end user in hopes that anyone should be able to comprehend.  For example, “As a product owner, I need to add an attachment to a user story so that mock-ups are available for team members to reference.”

Eliciting Honest Employee Feedback

In the office I spend part of my time researching the ROI on employee happiness.  One of the toughest parts to figure out before culture shocking your company is to establish the current situation as told by each employee, not the HR Director or the CEO.  The simple method of initial discovery is through a company wide survey or a couple of poll questions.

10 Heuristics of User-Centered Design

Lately the hot topic is UX (user experience) techniques and how to apply the best one to mobile.  This week I want to bring attention back to the ten timeless heuristics of user centered design as written by Jakob Nielsen.  In college we spent one full semester memorizing and applying them to our senior class project.  They are called “heuristics” because they are actually rules of thumb rather than specific usability guidelines as provided by iOS.  Please the following items as a checklist for any design you release.

Communicating the Product Vision

What are we supposed to build?

One of the most important responsibilities of a Product Owner is to communicate the product vision to all members of the organization. Not only is understanding the vision critical to product development and delivery, but it is also essential that everyone buys into the vision in order to contribute efficiently. For best results, spend time selecting appropriate modes of presentations per each audience type based on their needs and respective roles.

This week, I am sharing advice on techniques to present the vision and on how to maintain this information when you have adopted an agile methodology in which you are most competitive with a 'just in time' approach to planning.

Retain Talent Through Recognition

Most CEOs will tell you the most important asset is their employees.  Most human resource directors will tell you the most challenging problem facing them today is finding and retaining talent.  After diligent recruiting efforts and waiting longer than the market does, you build a great team of mixed individuals that have the potential to produce amazing things.  In addition to supporting an agile environment, companies must dedicate time and capital to implement recognition programs as part of the business model to retain their most valuable assets.  Not just key employees, but ALL employees should have the opportunity to earn public recognition from their peers, managers and executive team members. At the end of the day, we all like to feel appreciated.

Top 10 Mobile Release Considerations

Your initial release is going to be the one you have the least control over when it comes to planning which product features bring the most business value.  The reason you are constrained is because certain things must get done and decisions need to be made for the first mobile app release.   This weeks post is most useful to experienced teams that are new to mobile development and need a cheat sheet on what are the most important things to know when planning the initial release.  Since we are agile, the goal is to release an acceptable app early to market without sacrificing too much quality that you can not respond soon enough to market feedback.

Top 10 Considerations For Mobile App Release Planning

1. What device(s) and operating system(s) is your app compatible with?
You should keep track of the OS version and build number of the devices being used by the QA teams in conjunction with the code updates released by the development team.  Even if you are using a cross platform mobile development framework, it may not make the most sense to worry about all mobile devices this early on.  Shave time by choosing Android platform and indicate the compatible devices and software version. iOS will take a lot more time to get the first app submitted and approved by Apple, this does not include the timely process of activating an iOS developer account.

Is Your Team Happy?

Studies have proven that happiness is the key to success and longevity.  Many companies will use incentives or rewards as a means to increase productivity but there are challenges to keeping employee’s motivated for a consistent period of time.  Employers can only do so much to keep their people happy, people need to figure out how to make themselves happy.  How awesome would it be to start tracking the happiness of your employees to increase productivity in the workplace?

The key to measuring happiness is through continuous iterative cycles of inspection and honest feedback from employees.  I attended Jeff Sutherland’s latest webinar on the ‘Happiness Metric’ and I wanted to share some of the ways you can measure the happiness of your employees. The simplest way is to ask them using a short survey of questions and quantify the results.  Each culture is different so you may adjust the questions a couple of times before you can make correlations to the P&L.  Here is a sample set Jeff’s COO suggested I use on my last project.  I administered this exact survey to 5 different feature teams (6 members each), keep reading…

Number 1 and 2 are the only questions quantified for the metric:

1. On a scale of 1-5 (with 5 being extremely happy) How happy are you feeling about your role? (Indicate Role)
2. On a scale of 1-5 (with 5 being extremely happy) how happy are you feeling about the company overall?
3. What were the leading factors that increased your happiness since the last survey? (Give example)
4. What factors reduced your happiness since the last survey? (Give example)
5. Do you feel like you understand the product vision? (Team)
6. What is the one thing the team could do differently next sprint that would most increase your happiness? (Improvements)

Discipline is another key ingredient to creating hyper-productive teams.  Having your employees tell you how they feel and then doing nothing about it is counter-productive.  So here is the warning label for this article: WARNING: DO NOT TRY THIS AT WORK IF YOU ARE NOT SERIOUS ENOUGH TO IMPLEMENT CHANGE.

We will use metric again here at Seven Tablets and reformat it to suit the whole company, not just the product development teams.   The culture at our company is all about success through creativity and happiness.  Keep posted on my blogs and I will share the results in a couple months including  how to get everyone to adopt the survey.

Timeless Usability Principles that every professional UX/UI designer should know

These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

MetaScrum - Maintaining Product Priority Order in the Company

The MetaScrum is the meeting where all decisions product are made and/or heard by representative decision makers from all areas of the company.  Typically this is a weekly meeting run by the Master Product Owner and supported by the CEO.  The agenda includes a charter of meeting rules, objective, current sprint status update and upcoming sprint plan. Depending on the company culture, more items may be included that impact the product release cycles.  One of the most important rules to enforce is that all priority order changes must be made in the meeting and supported until the next meeting. These meetings can be critical to helping the product management and development teams focus on getting things.

I will be posting links to sample formats and documentation.

Implementing new user experience design

When it comes to agile requirements, user experience and creative design implementation often becomes a challenge especially for large organizations.  I have many different approaches to recommend but I will share one way that was wild successful for me.

Assume the user experience flow will require refinement after the screens have been developed and after real end users have used the system in their physical environment.  The key is to partner closely with your customers at any given time in your planning, development and release lifecycles.  

Below is a phased approached. Make sure you have thoughtfully identified minimum task completion, don't try to solve the experience for everything in your roadmap. If you listen to your market, they will adopt new feature flows and experience changes if you always do the right thing.

Phase1 (Mockup, Design, style guide and slices)

-------------------------

- Basic look and feel design and core user conventions. Conduct story mapping and identify only what tasks are necessary.

- Usability testing and feedback sessions with clients, user groups and CMIO panel

- Upload designs to central repository for review by all SMEs and front end architect. Time box feedback and move on.

- Work with product analysts or BAs to finalize user stories

- Requirements ready for development

Phase 2 ( In Development)

-------------------------

- Implement Design using artifacts provided by Creative

- Creative available for questions

Phase 3 (Beta Feedback and Refinements)

-------------------------

- Review implementation by development, make recommendations and refinements

- Beta Test Case feedback from client and product owner