The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.

Contrast

Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.

Using Trigger Lists in Product Management

I’m a big fan of “trigger lists”. The exercise of building them and the value they bring to a Mind Mapping or Design process have proved beneficial to me over the years. One of my favorites is David Allen’s GTD Incompletion Trigger List.

Recently, I transitioned from obsessing over providing Developers with APIs that would help them build amazing things with AI to obsessing about Healthcare and how AI can provide better care while lowering costs.

I pounded a Doppio and spent an hour brainstorming this trigger list to help me empathize with Users and better understand Actors in the crazy ecosystem that is today’s Healthcare tech.

I am a…

Healthy person
Cancer survivor
Farmer
Factory Floor Worker
CRO Administrator
CIO
CFO
CEO
Developer
Product Manager
Auditor
Patient
Physician
Nurse
RN
PA
Administrator
Researcher
Daughter
Son
Parent
Community Oncology Clinic
Hospital CEO
CMS Employee
FDA Committee Member

And I have…

Outcome data
Clinical trials
Drug databases
Medical journals
App Store Reviews
Medical Devices
Demographics
Avatars
Full Contact API data
Clinical Trial Participants
Patient data
Lab results
Population data
Reimbursement data
Patent filings
Hunches
Students
Research and Health kit data
Hospital trends
Emails
Tweets
Blog posts
Survey results
Internet searches
Essays
Product reviews
X-rays
Photos
Instagram searches
A list of questions

And I want to…

Find Patterns
Organize my data
Filter my data
Search my data
Understand social media
Build an Android app
Surface correlations
Have access to information

So I can…

Comply with regulations
Stay up-to-date
Collaborate with a Physician
Track my progress
Get credit for a course
Be reminded of an appointment
Find cost savings
Sell an app
Make people healthier
Prove a point
Get reimbursed
Understand health trends
Track my Clinical Trial
Find a Hospital
Research and buy my medication
Predict outcomes
Make more money
Connect data together
Build a treatment plan
Find a Clinical Trial
Predict the Future
Support Meaningful Use
Make evidence-based clinical decisions
Analyze adverse events
Provide better treatment “in the field”

For those familiar with Agile, you’ll recognize the “As a User I want” format of this trigger list.

We all have so much stuck in our heads, try creating one of these trigger lists for something in your world and you’ll be surprised at how it can help.

How a pregnant wife helps with software development

My wife is pregnant with our second child, due in May.  For those of you who have never experienced this release cycle, it’s 9 months long and does not have an exact release date.  There’s a thing called “Nesting” that occurs during this time in which a couple works together to get every single detail perfect in preparation for the baby’s arrival.

As I shop for curtains, read updates on the latest in car seat technology and scour color palettes for that perfect shade of blue, I am reminded how “Nesting” plays a serious role in the day to day life of the Agile Product Owner.  As a Product Owner myself, I am not writing the amazing code that drives our application, I am focused on keeping everything in motion and getting all the pieces just right.  As I see our baby room come together in just the right way and our app taking shape so beautifully, I can’t help but feel like a proud papa.

Now, if only I could get my wife to use Kanban.

 

Building Software is Amazing

For the past 6 months I’ve had the opportunity to work on one of the best projects of my career.  This thing has all the buzzwords: big data, social media monitoring, semantic analysis, kanban, ruby on rails, github, distributed teams, expertsourcing, skype video, lean, pragmatic, platform, you name it.  The team is brilliant and highly skilled in their areas of expertise (rails programming, UI/UX development, architecture).  Each member cares deeply about their craft and is highly passionate about our project.  We argue, we collaborate on great ideas, and all stress the difference between opinions and facts.

This quick reflection just reminds me that building software is amazing.  It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product.  Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles.  I can’t wait to see what shows up in the next “git pull”.

Why GTD Projects and Agile User Stories are so similar

David Allen’s Getting Things Done (GTD) approach reiterates the challenges of breaking a Project down into Tasks.  He focuses on the psychologic barriers people have with the work in front of them.  A common example (I’m paraphrasing here) is a person adding “Mom” to their ToDo list.  When digging further, David discovers that “Mom” really means “Mom’s birthday is coming up” and there are no Tasks or “Next Actions” defined to move the Project closer to completion.  This avoidance is very stressful on the person and a very inefficient way to life a busy life.

We use Rally’s ALM product and the Kanban custom tab to manage our User Story development.  I have worked with 2 teams over the past few years and both I consider quite amazing and talented.  Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved.  Our teams crank out great software, but always within a stressful environment.

As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”.  Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?”  I realized how similar GTD Projects and Agile User Stories really are.

  • A GTD Project clarifies the outcome you want.
  • An Agile User Story describes what the User wants to achieve.

Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion.  In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource.  Also in both, if Tasks can be defined it signals a complete understanding of the work to be done.  Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.

My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time.  We joke a lot about a common Task name we use in Rally simply titled “do it”.  Again, the GTD project similarities are strong here.  The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work.  Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.

By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!

What Brad Feld and Mark Suster think about Product Managers

I was watching This week in Venture Capital #18 with Brad Feld hosted by Mark Suster and was pleasantly surprised to hear “Product Manager” pop up as a topic. At minute 47 of the interview, Mark asks about the “lack of experienced Product Managers”.

Brad says “One of the hardest roles to fill in a startup is that of an experienced Product Manager.” He goes on to say that one can be trained to be a good Product Manager but that person needs to have a certain personality type. Brad cites a quote from Mark Pincus “Be CEO of your job” and goes on to say “If you are a Product Manager for a specific thing, you have to deal with it just like a CEO has to deal with the whole company.”

Some personality traits that do not help the Product Manager are:

  • too process driven
  • not a good mixture of leadership and management
  • not willing to be uncomfortable creatively with it then button down to drive to the goal line

The conversation wraps up with comments on the changing approach to Product Management as the role has become very formalized in big companies. Brad and Mark talk about the older Product Manager/Project Manager setup at Microsoft and the how today’s “Google style” Product Manager is a very different personality type in a very different role. Mark argues this type of personality (product, engineering driven) is not focused enough on the economics of the business and then Brad counters by saying that he would take a call from any Product Manager for a product at Google in a heartbeat. Brad concludes the conversation by reiterating the notion of owning the whole function and knowing how to allocate resources is a powerful skillset and a “very hard role to find”.

Creating Project Rhythm by following TechStars and Y Combinator’s lead

I admire TechStars (wearing my TechStars t-shirt proudly) and have been a reader of Paul Graham’s blog for years.  Both programs have created a vibe and atmosphere that churn out great work and provide endless motivation and contributions to their surrounding tech communities.

Reading the latest post from Paul Graham titled “What happens at Y Combinator” highlighted the relationship between schedule and rhythm and the role this plays in projects.  Both the Y Combinator and TechStars programs are roughly 3 months long, similar to the quarterly Agile Release schedule that we use.  The rigid schedule both programs use inspires and creates massive pressure for teams to work hard and deliver.

Because teams in TechStars and Y Combinator live and breathe their projects they are able to devote almost all of their time to it.  The rhythm these programs develop include dinners, hackathons, presenting at local tech meetups and renting out conference spaces to host big demos.  While a typical team can’t take things to that level, there are lessons to be learned.

Here’s the schedule I am using for our new project:

Product Summit – beginning of Quarter
A 2-3 day onsite working session full of multiple topics (business and technical) with a tight agenda and after work dinners.  The goal of this effort is to have a general gameplan for the upcoming quarter for the whole project, not just development.  In a distributed team like ours, it’s a rare chance for the entire team to spend time together.

9 Weeks

Monday
9a – Project Management conference call – a weekly update of anything to do with the project including budgets, contracts, etc
9:30a – Daily Standup

Tuesday
9:30a – Daily Standup
10a – Weekly dev team meeting – a weekly meeting to discuss technical details of upcoming work, review Kanban Board and Release Burndown

Wednesday
9:30a – Daily Standup

Thursday
9:30a – Daily Standup
Noon – Weekly demo to Stakeholders
1p – Weekly call with a Customer

Release retrospective – end of Quarter
A 2 hour retrospective answering questions like “What did we accomplish?”, “What was our Velocity” and “What can we change in the next Release?”

Summary
The rhythm I am trying to build for this project begins with a big kick off because lots of things need to be figured out up front and agreed on, then a strict weekly schedule to pull everyone along when things start to fall off the rails, then a decompression and review to let the dust settle. The schedule I have designed is nowhere near as cool as TechStars or Y Combinator but it’s a step in the right direction (I hope).

Related Articles:

The Rhythms of Life on Feld.com

Being more Productive on ktinboulder.com

TechStars