Ever had a horrific customer experience just trying to obtain service from a company, for example, a DSL provider? I did recently and it was unbelievably heinous, the net of which was that after 8 days, 6+ hours of my time on the phone, and interacting with all of the following people and systems in the “service” providers’ organization, I was worse off than when I started:
- Chris in Sales
- A service machine that sent three emails
- Beth in Order Processing
- David in Sales
- A service machine that sent two texts
- Website: provider.com.myorderstatus
- Andrea, then John, then Abe in Customer Care
- Chris in Winbacks
- Corey – installer
- Amanda in DSL tech support
None of the systems in use had consistent or shared information. My order was lost. My order was scheduled for delivery by 8pm. Not there? Can’t find it; you will have to start over . . . I provided my name, address, phone number three different order numbers at least 20 times. It was maddening!
So how do bad solutions impact well-intending teams in large organizations with huge system development staff?
Team interaction design focuses outside-in, looking at the scenarios of interaction between people in different roles and using different systems. As Amy Silberbauer discusses in her blog entry, being business-driven means flying up at a higher altitude than a specific system or role and a “big-ole-bucket-o-features” view point. The solution-level scenario provides context for the "lower altitude" interactions of a single persona and her interactions with capabilities in a single product.
Here’s a simple sketch of a team interaction flow (click for larger image):
Beyond the user research on the individual personas, we need to reason about these kinds of team questions:
- How many Project Managers does a Program Manager normally interact with? Are they in the same organization? Same geography?
- Is there a 1:1 correlation of Project Managers to Dev Leads?
- What role knows about the operations work related to the proposed Features? What roles in development interact with operations?
In the absence of this kind of analysis, we fall into the trap of building systems that are fit-for-purpose of a single role, but significantly impede the progress of the team.
In addition to flows, we craft team interaction narratives that we then implement in our products to understand and validate (or flag a correction needed) the team effectiveness with a solution.
Here’s an example, detailed from the flow above:
Act 1: An Idea from Business Gets to Development
Goal: An urgent business need comes in and must be prioritized and allocated to work that will be done by the teams involved.
Dennis - Business Owner (Exec)
Lonnie - Business Stakeholder
Phil - Program Manager
Bob - Product Owner
Pete - Project Manager
Marco - Dev Lead
- Lonnie has an idea to offer a lower rate to Gold Star customers on the Holiday Loan special that is to start soon so he submits a new Business Requirement describing his request.
- Phil is notified of new Business Requirement, so he reviews it and determines it fits within the existing Holiday Loans initiative.
- Phil creates a new Feature for the JKE Foundation development area
- Bob and Pete are notified of new Feature
- Bob, Pete and Marco discuss the scope and risk to understand rough sizing, impacted components, etc. in order to prioritize in the current Release.
- Marco works with development team (and optionally, enterprise architect) to determine what work must be performed by what teams. The work will be represented as User Stories that are Plan Items for the agile teams and Tasks that are Plan Items for the waterfall teams.
- Marco opens plan items in Mobile and Core Project Areas, links each to the Feature, and allocates them to the respective Plans for current sprint/release
- Pete accepts the Feature, and adds it to the current JKE Foundation Release Plan
And another act in the same narrative:
Act 5: Feature is Delivered into Production
Goal: Development teams deliver their parts of the solution independently and business is notified of the availability of the feature.
Mobile development team
Phil - program manager
Mainframe services team
Lonnie - Business Stakeholder
- The mobile team completes their development and testing and deploys their application with the required feature into production.
- As a subscriber of the mobile user story, Phil is notified of the delivery.
- The mainframe services team completes their service, tests with the mobile front end virtual service, and deploys the service into production.
- As a subscriber of the mainframe services task, Phil is notified of the delivery.
- He sees that all the children of the Feature are delivered, so he marks the Feature as delivered. As a result, Lonnie is notified.
We socialize our flows and narratives with our development teams, of course, and they also become a rallying point for other stakeholders:
- Sponsor users and customers to validate and refine
- User assistance developers to leverage in delivering help files, tutorials, videos and other user aids
- Proof of Technology engineers for defining the scripts for hands-on workshops
- Business partners for identifying where their solutions are used to extend our capabilities
- System verification testers to capture solution-focused test cases
- Services teams who help customers transform their organizations using our solutions
- User Experience and Visual Designers working at the product level
Do you do something similar for your solutions? If so, please share. Do you find the flow diagram easily understood?
Are there other roles in your organization who leverage flows and narratives?
I am happy to share more details and examples in additional blog entries. If you are interested, please comment on this entry to that effect.