Thursday, April 10, 2014

Fallacy of a shippable product


The agile literature generally advocates a potentially shippable product at the end of each sprint.  I find this assertion problematic.  It is disconnected from the larger discipline of product development and somewhat naïve.

The fallacy lies in the fatal (and unstated) assumption that the product is programming, testing, and documentation.  It isn't.  While these are the basis for the end user experience, they do not represent the totality of the experience.

For example, the customer may need help and call support.  Or, the customer may need help implementing the software and require training and services.  You may not even have a customer, and therefore require someone to market and sell the software.  All the coding, testing, and documentation in the world isn't going to solve these challenges.

Here are some of the other groups needed to make a product shippable.

  • Sales requires knowledge of the problems the software solves in order to position it to the buyer.  They need assistance learning how to demonstrate it effectively.  They will also need to determine the price of the software.
  • Marketing must understand the features, what they do, the problems they solve, and the benefits they provide to the customer.  They may need testimonials or other endorsements. They also typically develop collateral, press releases, and other material that can be "left behind" by sales or used at trade shows.
  • Support must be trained on the use and troubleshooting of new features. They may also need to learn new issue escalation paths to development for issues that exceed their skills or knowledge.
  • Services will need to learn how to install, upgrade, and configure the software.  They may also be the group that trains users, as well as consults on best practices for using the software efficiently.  They will need to develop end user training and consulting guides.
  • Legal will need to draft contracts that can be used when the software is purchased or licensed.

This is a significant list of deliverables required to ship a product to an end user. Are you really going to have your organization do this in conjunction with the end of every sprint?   The cost associated with these type activities is best spent once, when the release is stabilizing towards the end of the remaining sprints.

Continue to strive for fully coded, tested, and documented software at the end of each sprint.  But let's mature our view of product development and recognize it is much more than just the ones and zeros.

Wednesday, April 2, 2014

Letting your team find their own path

I recently spent a week on the road.  As luck would have it, several key meetings were scheduled in the office for the same week.  I selected different members of my team to represent me at each.  They did a fantastic job representing themselves and our team.  They helped good decisions be made for our company and for our customers.

I'm proud of them, and in full disclosure, I also take pride in my role helping them be successful. But that is not the point of this post.  What I'd like to share are the lessons from a conversation prior to one of the meetings. For ease of reading, let me refer to the person with whom I talked as Chuck.
 
In preparation, Chuck and I talked about the intent of the meeting, who should attend from our team, how we thought the session would go, and our goals for the outcomes.  As we talked, I caught myself doing more dictating than coaching.  I was (not so) subtly guiding Chuck down a path of how I would have approached the meeting based on my role, my understanding of the background and attendees, and my knowledge of the situation.

Chuck stopped the conversations and said, "I need to do this my way.  I can't be you."  And Chuck was absolutely right.  We took a step back and looked at things from his perspective.  From there, Chuck led the approach with me in the better role of coach.  I challenged his assumptions when necessary and added context when needed.  In the end, we agreed that he would do much better as a confident Chuck than a pretend Neal.

Chuck went to the meeting and knocked it out of the park.  When asked how Chuck did, a peer executive texted me, "Very good.  [He] was strong."  I could end the story here, but there are two lessons I'd like to share.

First, without trust, Chuck wouldn't have advocated for himself.  I've written elsewhere about the need to build this culture.  This is a terrific example of why this matters.  If Chuck hadn't believed he could challenge anyone on the team - including me - he would have performed less effectively at the meeting.  Given the stakes, the results would have harmed the team and the business.

Second, it reminded me to let my leaders find their own way.  I try hard to not over manage, and yet it is easy to do so.  Only through constant self-awareness can I pull back and give my team the space to find their own solutions and style.  Each leader on my team has a unique way of approaching problems.  For them to grow, they need my guidance and trust.  And they need the confidence that comes from knowing that if they choose a path different than one I might have chosen, I will support them.

In the end, what matters is that we achieve good results.  To get good results, fall back to the basics of trust among the team and freedom to explore different paths to success.