Paul Sizemore

Tagged: Humana RSS Toggle Comment Threads | Keyboard Shortcuts

• 

  Paul Sizemore 9:25 am on March 27, 2012 Permalink | Reply
  Tags: Customer Care, Humana   

  Integrating Innovative Customer Care & the Enterprise 

  While at Humana I managed products through an entire lifecycle. What that meant from a customer care perspective was supporting products with a few users (they were new products), and then supporting that same product six months down the line when there were over 100,000 users. As the product grew, we utilized more company resources to provide adequate customer care.

  The customer care infrastructure was there, but not unlocked until needed.

  For many of the products we, the Humana Innovation Center, used Get Satisfaction for the early stages. This was linked to a Fogbugz account so that cases were automatically created when someone asked a question on Get Satisfaction. This allowed integration into a more robust bugtracking software. The Product Owner would then ‘triage’ the cases, and create a story in Version One for any cases that needed development resources, and pass the more difficult cases over to the Enterprise Customer Care team.

   

  

   

  Reply Cancel reply

  Required fields are marked *

  Name *

  Email *

  Website

  * Copy this password:

  * Type or paste password here:

  

  Notify me of follow-up comments by email.

  Notify me of new posts by email.

• 

  Paul Sizemore 9:51 am on March 7, 2012 Permalink | Reply
  Tags: Humana, PMM ( 8 ), Product Management ( 17 ), Requirements, SiriusXM ( 17 )   

  The Artifacts of Agile Development 

  Anything produced in business that is not used in the finished good or service is an artifact, and requirements are artifacts. Requirements are essential, too. Because of this it is important to create the minimum documentation needed to communicate the requirements. Many times the business solutions group, or a consulting firm, feels it is paid by the word.

  Large enterprises, such as Humana and SiriusXM, have traditionally excelled at creating excessive artifacts. Sometimes it’s needed, to help in an audit situation. But, often, it’s a byproduct of the culture, and doesn’t directly serve the product development process.

  

  This leads to enormous  Word requirement documents in excess of 100 pages, that the teams avoid. Instead of looking at requirements as documentation, it is important to look at them as communication. It’s also helpful to have it in a form that the teams enjoy going to, they can get in and out quickly. They can find the information they need.

  A switch to Jira, http://www.atlassian.com/software/jira/overview, can put the infrastructure and tools in place to make that organizational change.

   
• 

  Paul Sizemore 5:06 am on February 14, 2012 Permalink | Reply
  Tags: Humana, Pie ( 5 )   

  Humana’s Yuliua Throwing a Pie 

  Any day that involves pies is a great day, but pies at work, well
  that’s a super-awesome day. At Humana, in the IT Department, we had a
  pie throwing contest to raise money for charity. Yuliua has great form
  and lots of poise in her pie throwing efforts. 

   
• 

  Paul Sizemore 7:25 pm on February 3, 2012 Permalink | Reply
  Tags: Humana, Management ( 13 ), Pedometer ( 2 )   

  Thank You Humana Stakeholders 

  

  Sometimes it’s hard to get resources within large companies, and it’s important to keep channels open. A well timed thank you letter to business stakeholders can do wonders. I keep a pack inside my desk, and thank you notes have opened doors for me.

  A few key things to keep in mind while writing your note:

  • Express Sincerity: Be genuine in why you have gratitude toward your business partner.

  • Personalize It: Be sure the recipient knows why you have gratitude for what they did for you.

  • Keep It Short: Brevity rules. Keep the thank you note short.

   
• 

  Paul Sizemore 6:52 pm on January 10, 2012 Permalink | Reply
  Tags: Humana, PMM ( 8 ), Product Management ( 17 )   

  What does a Humana Product Owner Do? 

  At the Humana Innovation Center the Product Owner is responsible for representing the customer voice in the Scrum team, and is often the only voice of the customer. So, the stronger the Product Owner is, the more the product will be what aligns with the Stories, Epics, Themes and product Vision. All too often, with a weak product owner, the user experience is diluted in efforts made by the development team. Their goal is to couple stories, and maintain the greatest velocity they can. This presents a point of conflict between the product owner, and the rest of the Scrum Team.

  Acting as a mentor to the product owner, we were once told that it would take five story points to complete what was a basic php include, and it went unchallenged in the scrum, until the end when I spoke up. With challenge, it was quickly lowered to a one.
  I see the scrum as a fight, a fight between the product owner and dev, and being outnumbered, the product owner needs to be able to spot problems.

  The product owner takes the Key Feature & Epics, writes supporting stories, and presents them to the Scrum team.

  The product owner is responsibilities are:
  • To write stories, and make sure they tracked in the backlog
  • Prioritizes the backlog, according to the product strategy
  • Helps the Scrum Master & Team in Release & Sprint Planning
  • Although they live in the day-to-day product details, they advise on Themes and the Vision
  • Accepts or rejects the work presented by the development team
  • A stakeholder communication (in this aspect they protect the team)
  • They can terminate the sprint
  • They speak on behalf of the customer, and is the customer’s champion

  Most importantly, the Product Owner is ultimately responsible for the success of the product.