How do you share information with your team? There are so many different things to communicate:
- Bob is out sick today.
- The TPS reports are functional and deployed.
- The utilization metrics have been spec’d.
- Visual design is complete for the login screen.
- We’re still seeing errors from that federated login package.
- We’re all out of beer.
All of those things matter. But they matter differently, to different people.
One of the causes of friction (both within and without the team) can come from using the wrong tools to communicate.
I frequently see projects that want to run everything through Rally. Or Pivotal. Or JIRA. Or whatever. Trying to force everything through the same process is problematic because we cross different levels of abstraction. For example:
- Customer: I want a TPS report. With pie charts. Soooo many pie charts.
- Developer: Create the page, set the title, take the localization data from the translations form, commit it to a feature branch, and get it approved.
Both of those consumers represents a different level of abstraction. Trying to force everything into the shape of square pegs is bound to disappoint someone. Each group is going to think about it differently.
Different Groups, Different Needs
Suppose we need some TPS reports:
Developers
Your dev team needs something actionable and well-specified. Not necessarily a pixel-perfect mock up, but something like “create form X with fields Y and validation rules Z.” It’s a task: discrete, easy to tell when you’re done, and well-defined. I can estimate this with reasonable levels of assurance.
I’d probably break down our TPS reports to something like:
- Provide visual design for TPS report
- Create sample data generator to validate TPSs
- Create TPS report in SSRS
- Provide authorization for TPS report access
- Plan a nightly job to cull out-of-range TPS report cached data
Most nontrivial features (i.e. almost every single thing a customer ever asks for) are going to get broken down into multiple actionable, interdependent, bite-sized tasks. It’s possible that it might not make sense to demo or deploy these tasks individually until several of the associated tasks are complete, but by thinking through the discrete breakdown, I can estimate it better, track progress better, and plan better.
I know that my customer “just wants some TPS reports”—but it’s really hard to build a complete picture in my head that covers how the report will look, how my scheduling system runs it, where it’s stored, how it’s backed up, how it’s secured, how it looks, how it fits with existing style rules, how it’s deployed, and so on, ad infinitum.
Any normal-sized feature is too much to fully understand from top to bottom. That’s why I break it down into bite-sized pieces which I tackle one at a time. Individually, these do not provide value to my customer, but this approach lets me lay out a path with the team, parallelize work, and estimate it.
Customers
As I touched on above, my customer really doesn’t want to be bogged down in pixel dimensions, algorithms, or tasks. This persona really wants a high-level view: Is the project on track? Do I have functioning features?
You’re not going to have success trying to force a non-technical customer representative to look at the very decomposed stories that a developer wants. So when you communicate or radiate information to your customers or stakeholders, make it high-level. This customer is just thinking “Q2’s budget is going towards making the analyst reports.”
They can help make budget and scope decisions—but that can’t be done effectively at a detail level.
Communicating Across the Divide
Imagine this conversation:
Developer: Yeah, our velocity numbers project us being two sprints late.
Customer: ?
Developer: So you need to pick 20 points of stories to drop, or authorize extra expenditures.
Customer: ?!
Developer: Just log in to StoryMagick and drag stories around until you’re happy.
Customer: ?!?!
Developer: Sigh. Here, click this password reset link.
Customers are not project managers or developers, so this is probably not too far from the mark for most of them. If we operate in the level of abstraction our customer lives in, this works better:
Developer: We’re projecting that we’re going to deliver late. Can we prioritize a user class to make sure we get the important parts?
Customer: We’re focusing on the analyst reports. We absolutely must get them accurate and complete numbers before the fiscal year turns over.
Developer: OK, if numbers are critical and our customer is internal, can we flex a bit on visual design?
Customer: Yes. It doesn’t matter how it looks, as long as the department gets up-to-date info.
Developer: I’ll identify 20 points worth of stories that match your priorities, and we can review them at tomorrow’s standup.
Different Conversations, Different Tools
Most teams understand why one conversation is better. But our tool choice often makes it hard to have one type of conversation. The type we fail at typically depends on how we use the tool. Here are some typical things that different types of people might want:
- Customers want to know which features are in this release, currently being worked on, or now complete.
- Project managers want concrete acceptance criteria, a detailed priority ordering, and estimates on which they can base projections.
- Testers need to know how to validate and exercise a feature.
- Developers just want a damned list of things to work on.
Don’t handicap your team by acting like these are equivalent. If you try to make a one-size-fits-all solution, you’ll end up with unhappy customers who can’t see the forest for the trees, and/or you’ll get developers working on the same “user story” for two months. Those are both terrible outcomes.
Instead, pick tools that let you radiate the important things. For example, here are appropriate ways to use a few tools:
- Customers write their wish list in Excel.
- Visual designers use a prototyping tool to get everyone on the same page.
- Developers break down stories and enter them into Pivotal.
- A project manager reconciles the three to communicate a 10,000-foot view of the project status.
- Customer or PM feedback on stories in development is entered in the story in Pivotal, or as a new story.
- Defects in completed or deployed work go into JIRA.
When people try to use Pivotal or Rally to handle all of those, inevitably, someone is disappointed. To fix that problem, first recognize that there is more than one job. Then use the right tools for the right jobs.