Blog Post: How To Set Your Failure Up To Succeed


Failure is a scary word in our work today. While the startup culture has embraced failure as the best learning took in the market, the word still has chilling effects on today’s business leaders. An Amazon search reveals over 22,000 books include the word “failure” in some fashion. Another few thousand can be added on this list by changing the word to “fail”, as Ryan Babineaux does in his popular tome. Failure, as it seems, has become yet another cottage industry.

For the most part, we still do everything we can to avoid it. In my most disturbing Google search to date, I even found that certain project management circles are using something they call “best practices to avoid project failure”. I sat there wounded for a good five minutes.

Yet, the tide seems to be turning.

Continue reading

Blog Post: Coming Out Of Your Own Closet


While I’m not proud to admit it, I am a people pleaser by nature. I’m inclined to go an extra step if I think it will gain favor in someone’s eyes, and I’m hesitant to lovingly speak tough truth if I think it will cost me that relationship. It’s debilitating to picture myself in those situations, and downright paralyzing to actually go through it. I’ve gotten a little better over the years at facing the music, but part of me will always struggle.

What’s worse, I know I’m not alone.
Continue reading

Blog Post: How Owning A Useful Device Might Have Changed My Mind On Wearables


In the past 12 months, most of the conversation around wearable technology has related to how “useful” the devices are. When I say conversation, it’s not necessarily questioning if current the technology is useful. There’s no question of that, when you compare devices released by Pebble, Samsung, Nike and others. The only reason anyone is questioning how useful any of these devices are is because they aren’t really selling up to expectations.

That hasn’t stopped people from coming up with their reasoning why wearables aren’t useful yet. I’ve been on that same bandwagon, espousing the duplicitous nature of these gadgets. They promise more than what your smartphone is providing, yet when a blogger’s Fuelband or Fitbit has issues, more and more aren’t making the same effort to get them back into action.

I’m here to potentially backtrack that rhetoric, slightly.

Continue reading

Blog Post: Solving The, “Am I The Only One With This Problem?” Problem


Whether you are a team of one, or one hundred, we are presented with the daily opportunity to introduce positive change into our work environments. Asking tough questions is a challenge to say the least, but it is also imperative to foster growth in today’s climate. With teams somewhere in between those two numbers, my biggest challenge and thrill comes from championing this effort every day.

Lately, I’ve had the opportunity to widen my scope a bit from team-oriented change to company-wide. In an effort that has taken a few months to get going, I would like to share about my experience.

At your place of business, some of you have large projects. Having spent a few years consulting in the telecommunications industry, I can sympathize with gigantic road maps involving hours of work in the thousands. Product teams have work that seemingly never ends, because the product is always out there being improved. To introduce change, you simply take your steady team and perform regular retrospectives. Gather information, assess the cause of what ails, hypothesize change, and prioritize the most important at the top of your next backlog.

It doesn’t happen this way at Bottle Rocket.

Our projects have a short life. Some apps are shipped in as little as two months, and the average time a team has together is five to seven months. The project I currently run is tracking to last about 12 months, but we have staffed up and down to meet the client’s needs several times.

We don’t get to stay together for very long.

My call is to still lead with transparency and ask the team to inspect and adapt regularly. Regardless of the timeline, agile leaders can still demonstrate the principles we learned long ago. The question I kept getting asked was, what happens to all that change we shepherd on projects?

Once the project is over, the team is broken up and moved in several directions depending on the sales pipeline. The PM picks up a new client, and a new team. Most likely, they aren’t the same as their previous project. Often, we have to start over from scratch. To boot, when a colleague has an issue on their team, a recurring question is asked.

“Am I the only one with this problem?” From the CEO of our company, all the way down to the newest employee, we all ask that question.

The final problem to solve was how retrospectives are run. Project managers are given a tremendous amount of freedom in running our teams, including retrospectives. We are just asked to do them, regardless of the method. As a result, mine looks different than all the others. Tough to compare apples to apples in that sense.

With the help of our analytics expert, I tackled this problem and am now pilot testing a unified method of inspecting and adapting. The call on me was straightforward:

  1. Gather the same information company wide.
  2. Keep it anonymous.
  3. Still give PMs the freedom in executing their retros.
  4. Move the ceremony to be more solution-based instead of focusing on the problem.
  5. Organize information into a concise repository to allow full transparency to the company.

I’m not the first agile coach to suggest a survey in advance of the ceremony, nor am I the first to acknowledge that retros are sometimes glorified “gripe sessions”. What I did try to do, though, was carefully curate what kind of information would help my company gain insight and incorporate a rating with each question (value-stream mapping style). The questions may evolve over time, but I wanted to share the first iteration of the survey to get your feedback:

  1. How satisfied were you with this sprint?
  2. How productive was the team during this sprint?
  3. How effective was the communication among the team?
  4. Rate the quality of the deliverable/brand experience the team created during this sprint.
  5. How effective were you in fulfilling your role on the project?
  6. What recommendations do you have for future sprints or projects?

The first five questions have a rating of 1-10 associated, as well as a follow up question of why the responder felt that way. It allows for some metrics to be gathered as well as help people identify their feelings better and assess the team’s progress.

Looking forward to getting some results and get feedback from the pilot teams. Thanks to my fellow PMs for allowing me to execute the desires of many and get smarter information towards improvement. The point isn’t to be more organized, although that can be a benefit. The point isn’t to insert “one more thing” for our teams to do as part of our process. It isn’t even to more closely watch from above what’s going on.

The point is to measure better to grow stronger.


Blog Post: “Improve Yours, Or Help Someone Else Improve Theirs.”


Loved the hashtag #BRMakeIt

While it’s one thing to set the pace of creativity in your workplace, it’s completely different to be swimming in a sea of creativity pushing you to create your very best. In my first year at Bottle Rocket, I have been challenged harder than ever before to be at the apex of what is possible. We say every day that we “embrace the impossible”, and that was manifested recently with our annual Rocket Science event.

If you have ever participated in a company hackathon before, just picture that effort on caffeine and steroids and you are getting close to it’s description.

Continue reading

Blog Post: What Analytics Are Teaching Me About Retrospectives


Having prided myself on being well read on industry information, I thought I knew how to have an intelligent conversation on analytics. I’ve pitched A/B testing in previous jobs, explained value-stream mapping, and collected more than my fair share of metrics on team success. With all of the sites devoted to gathering and analyzing feedback, you can fool yourself to thinking you know enough.

Then I met a real analytics expert.

Our agency hired one shortly after I started, and I made it my mission to understand how she thinks. Why something should be measured and why it shouldn’t. What should the real value in a particular question or the numbers associated with it be. LB was a life saver, because she taught me the value in asking the right question.

Over lunch, one day, we discussed gathering data on Agile teams. Having sat in on a few project teams, she saw a retrospective up close and personal. My frustration was that we gather all this useful information on how to improve our work, and because projects are short lived at Bottle Rocket the data from retrospectives sort of disappear into the ether with the close of a project. I sought to institutionalize the lessons learned, but I didn’t know how to get my fellow PMs on board.

I took her through ideas like Jeff Sutherland’s happiness metric, Deming’s performance appraiser formula, and the various ways we currently gather feedback in Scrum retrospectives. It was a sea of isolated information, without a way to contextualize it for senior leadership. Her face then lit up as she explained how she runs usability testing for our apps.

“By itself, a number is simply that…a number,” she told me. “Value-stream mapping holds value only if you point the survey to the right follow up question.” 

She guided me to the conclusion that asking open ended questions is great for mature, self-aware team members who can easily pinpoint what’s happening with each sprint. Paring it with a scale of 1-10, however, can prime Agile teams to understand how exactly they feel in the moment. Once they establish how they feel about something, it’s that much easier to put an explanation with it.

For example, if you ask me to rate my personal performance in the last sprint from 1 to 10, I could say that I was a 7. When I’m asked to follow up with why I would rate myself thusly, I could point to me meeting my sprint goals and all the associated tasks. What I wasn’t great at was communicating with my strategist because I was really heads down on other work. If I can’t communicate better, then the team will silo off.

That, my friends, is valuable information that leads to immediate action items to be gathered.

To boot, if I can get questions like this answered in advance of the retrospective, we can be more solution-based in our discussion and focus on what the right action items are to address in the next sprint. Imagine how productive your time together as a team could be if the agenda is that clear. Trust is established. Performance gaps are identified, griping is minimized and improvements are maximized.

Thanks, LB, for helping me realize that the time I devote trying to understand the team is not something to keep to myself. If your work is like mine, and resources tend to move around a lot, wouldn’t it be an amazing thing to standardize retrospectives and collect the improvements for all to share? It establishes that you aren’t the only one to experience a particular struggle, and helps the company keep from making the same mistake 20 times. 

Now, I can sell to leadership that we can settle for making a mistake only once.