Monthly Archives: June 2013

Sacredness of the Sprint

Here is another excerpt from our upcoming Agile textbook.  This is a topic that I am particularly passionate about!

No Changes to the Sprint

One of the most importance cultural changes related to Agile adoption is adhering to the sacredness of the sprint.  What does this mean?  It means that once a sprint goal is committed to, there should be no changes to that goal.  sprint_sacred.jpgThe group that has the hardest time adhering to this is upper management.  There is always some crises or customer request or great idea that an executive wants the team to investigate immediately and there is a tendency for executives to pull the team off of their sprint commitment to work on the latest critical task.  The companies that allow this type of distraction have the most difficult time adopting Agile.  The companies that stand firm and honor their sprint commitments tend to be more successful in their adoptions over all.  Truly, it is a sign of executive commitment to the process and the methodology if they honor this one aspect.

Mike Cohn, in his book Succeeding with Agile, is very firm on this issue. “Nothing is allowed to change within the sprint. The team commits to a set of work on the first day and then expects its priorities to remain unchanged for the length of the sprint. “ (2010, pg 279)

Agile Examples – The Scrum Team

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Scrum Teams.  Would love to hear your thoughts and comments.

Strong Scrum Teams

The green team has a team member who is wicked smart, so much so that the rest of the team has trouble keeping up with him when he gets going on an idea.  He is almost always right in his direction but he processes information in his brain so quickly that when he talks, it is a bit like gibberish to the rest of the team because he doesn’t clearly state how he got from problem to solution.  On some teams, this type of savant could be extremely frustrating because when he talks, the team rarely understands what he is saying.  But the green team is a highly effective team and they recognize and value the intelligence and ideas of their super-smart colleague.  So they brainstormed the right way to allow him to communicate his ideas and thought patterns.  They painted all of the walls in the area with whiteboard paint which allows you to write on the walls, from floor to ceiling, and then erase it when you are done.  They encouraged their team member to write down the train of thought that his brain was making in solving a particular problem.   This allows the rest of the team to slowly digest what their colleague is conveying and they have a written record to access when they are trying to recall a specific detail.  The green team rallied together and found a solution that would allow all of their team members to actively contribute and drive towards the best possible solution.

Not so Strong Scrum Teams

The blue team is not optimized.  They have a member who is equally talented but far more disruptive.  This individual is negative and not a team player. Every idea that isn’t his own is stupid and anyone who doesn’t like his ideas is stupid.  He is very intelligent and knows the system very well so his behavior is tolerated even though he is so negative.  The sense is that the team could not do without him because of his expertise.  His presence has created a work environment that is tense and unproductive.  His team members are reluctant to confront him because he is so aggressive in his negative demeanor.  The issue of his attitude has been raised with both the Scrum Master and the IT Manager but neither are willing to address the problem because they fear losing his expertise on the system.  So this team operates in a constant state of fear. They do not know how this individual will react in any situation so they all retreat and wait for his reaction before they express any opinions of their own.  The team is failing to meet any of its deliverables because no one can commit to certain tasks when the bully on the team is driving all of the discussions and undermining the whole Scrum practice.  This is an ineffective team who would be far better off if the dominant individual was removed from the team.  They might suffer a bit from the lost expertise but they would gain far more by being allowed to brainstorm and work together.

Want to read more?  We have examples for Product Owners and Scrum Masters too.

Agile Examples – Scrum Masters

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Scrum Master. (Names are made-up so don’t think you know them  🙂

Would love to hear your thoughts and comments.

Scrum Master

Let’s look at examples of good and bad Scrum Masters.  Everyone has their strengths and sometimes the role of being a Scrum Master is not assigned to the best person and other times, it is a natural fit.ScrumMaster

Consider Steve.  He was brought in from another team to be the Scrum Master of a team that was really struggling.  Steve started by getting to know all of the developers on his team. He met with each person individually to learn what their impressions of the problems were.  Then Steve began actively advocating for the team. When decisions were not being made in a timely fashion, Steve escalated the issue so his team could get the answers they needed to write the best code.  When the team had a disagreement, Steve jumped right in and facilitated a healthy but heated discussion about how to best solve the problem.  And when required to make decisions, Steve gathered the best information available at the time, consulted with people internal and external to the team to check his facts and then he chose a path, informed all parties and stood behind his decision when it was questioned.  His leadership allowed the team to focus on the code that they were designing, writing and testing so that they could make their commitments and feel a real sense of accomplishment.  Steve is a great Scrum Master.

Steve’s team sits very near Ray’s team who is not sharing in their success.  Ray is the Scrum Master and he has a rather timid personality.  When conflicts on Ray’s team arise, he watches nervously and encourages everyone to be nice but he doesn’t help them resolve it.  He acts more like a disengaged referee.  On Ray’s team, he has two very strong, dominant personalities and two very introverted and quiet people.  Ray doesn’t like confrontation so when the two strong personalities dominate the conversation, Ray allows it to happen.  Therefore, the weaker, more timid people don’t say anything and just go along because they don’t want to rock the boat.  This is very unfortunate, because the two quiet developers are quite knowledgeable about the system and they have noticed flaws in the design of the code but the strong personalities don’t seem to understand or care about the risks in the way that they are proceeding so the quiet people just sit back and hope that their in-depth understanding is somehow wrong and the path they are on will work out fine, despite their gut feeling that the design is flawed.  Because Ray allows this dominance on the team, he is part of the problem instead of being part of the solution.  For a Scrum Master, avoiding confrontation is not healthy or helpful.   Confrontation does not have to be negative, it can be respectful and it can often lead to the best deliverable.  Ray is not an effective Scrum Master and he is jeopardizing the success of his team.

Want to read more?  We have examples for Product Owners and Teams too.

 

Agile Examples – Product Owners

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Product Owner.  (Names are made-up so don’t think you know them  🙂

Would love to hear your thoughts and comments.

Product Owner

There are many examples of good and bad Product Owners in the workplace.  These are challenging jobs with a number of conflicting inputs with regards to prioritization so it takes a strong personality with a collaborative work behavior to be successful.

Let’s look at Keith.  He was assigned as the Product Owner to an application that had several high profile and demanding clients.  Keith researched all of the necessary competitive and market information so he could ascertain the best prioritization for the development work that needed to be done.  One Account Manager who handles one of the high profile clients didn’t like Keith’s prioritization because something that their client wanted was not at the top of the list. Keith was very deliberate in his analysis and he felt that the requested feature would not be adopted by others in the marketplace – it would really just apply to this one client almost as if it was custom code.  Therefore, Keith put other features that he felt would drive more business value before the requested client feature.  But that didn’t satisfy the Account Manager as she felt like her client’s request was vitally important. So she pleaded with Keith again and again.  She called him and sent him e-mails and held meetings and just pestered Keith relentlessly to try and get him to change the prioritization.  Finally, in a moment of frustration, Keith said “Fine. You go talk to the IT manager of the Development team.  If she thinks they can get it done, then so be it.”

Is that an example of a good product owner or a bad one?productowner

Keith was having a bad day and in that moment, was a very bad product owner.  The Product Owner sets the priority for the work of the IT team based on their knowledge and research of the marketplace and what will drive the highest business value.  Further, the Product Owner must collaborate with all of the constituents to “sell” the prioritization.  The product owner must be collaborative and must hear input from a number of sources, including account management.  So it was Keith’s decision as to whether or not the client request would be prioritized high on the list.  His decision and his alone. By deferring to the IT Manager, he was shirking his responsibilities.  He should have either convinced the account manager that his backlog was prioritized correctly by articulating the business value of the high priority items and clearly explaining to the account manager why their desired task did not have the same business value – or, if he couldn’t do that – then he should have reprioritized the backlog to move up the client’s task, based on the information learned from the account manager.  Being a Product Owner is a difficult balancing act but the role is critical and must be performed well for Scrum to be effective.

By contrast, Sam is a great product owner.  He actually moved his desk to sit with the Scrum team so he could be immediately available to answer questions of the team.  Sam spent a portion of his time with the account managers, salespeople and actual customers so he could stay on top of how customers were using the product and what problems they were having.  He also learned from the salespeople what objections they were hearing from prospective clients.  He was able to distill all of that feedback into the user stories that he created and he understood which features would drive the most business value so he could effectively prioritize. Sam also listened to his Scrum team and understood enough about the technology to contribute to the discussion around various choices that could be made to solve a particular problem.  The best product owners have enough technical expertise to be able to follow a technical conversation and contribute salient points to the discussion.  Product Owners do not have to be developers by any means but they should demonstrate a technical aptitude.

Want to read more?  We have examples for Scrum Masters and Teams too.

 

How to Launch a Product

Product Management roles are challenging and fun and I am a self-professed Product Management geek.  One of the critical responsibilities for a product manager is to successfully launch new products that are built in concert with the IT and Operations teams.Shuttle_launch  In my experience, there are several key steps in the launch process that must be considered.  Here are five posts that walk through these steps.

What does it take to launch a product?

Product Definition

Pricing

Sales Enablement

Making Hard Choices

Developing a Communication Plan

I hope you find this information helpful and interesting.  If there is anything that was missed, please let me know. Happy Launching!

Lessons from my Mom’s Amputation

This week’s blog is a bit more personal, just because it is what I am experiencing right now. My mom is having her leg amputated.  That is a big deal.  Fortunately, I am here with her and I will be able to see her through the surgery and rehab. But as I have spent more time with her in the days leading up to the loss of her leg, I know with great certainty that she will come through this surgery fine because she possesses several key assets.happy_sun

1. Positive Attitude – my mother has always been a ‘glass half full person.’  She will often comment on the blessings of a sunny day, warm cup of coffee, hummingbirds at the feeder, a roof over her head, and a phone that rings with calls from loved ones.  Things that some of us take for granted, she treasures. Mom is a genuinely positive person and that grateful outlook is going to serve her well as she will undoubtedly face some interesting challenges in the weeks and months to come.

2. Friends and a Support Network – Over the course of my mom’s life, she has invested in her friendships. She takes the time to make calls and send cards. With each friend, she celebrates the joys and mourns the losses.  Being a good friend isn’t always easy, but it has always been a priority for Mom. She has friendships that have lasted over 60 years and since we found out about this latest surgery, her phone has been ringing off the wall. She has worked hard to cultivate these relationships.  She has given away so much love and support and now it is coming back to her tenfold.

3. Sense of Humor – We laugh a lot in my family. Last week in the hospital, one of her more serious doctors came in to convey the very serious news that, despite reviewing all possible alternatives, we were going to have to amputate. My mother immediately responded with “well, at least I will get half-off on my pedicures.”  The doctor was truly speechless so we launched into a whole series of amputation jokes – “you are so lucky that you will only have to shave one leg.” “Should you change your name to Eileen?” “No more of that ugly bunion!”  And on and on… Approaching life’s hiccups with a sense of humor and laughter always seems to lighten the load.

As we approach this huge event in my mom’s life that will truly change everything, I know that she will be fine. She has the right attitude, an amazing support group and a wonderful sense of humor.  If we could all be so lucky to possess those traits in our trials, we would surely be a leg up.  Ha, ha!

 

 

 

What Disney World taught me about Product Management

We just returned from a week in Orlando where we spent three glorious days in Walt Disney World and three spectacular days at Universal Studios Orlando. It was a great vacation and one we will remember for a lifetime!Mickey-Mouse-magic-kingdom

Since I am a Product Management geek (and proud of it), I couldn’t help pondering what the Disney experience can teach us about Product Management and I came up with three key take-aways.

Wait times/Roadmaps

The Disney parks are very transparent about their wait times. They are clearly posted at the entrance to each ride and they are even available on the Apps so you can access the wait times for a particular ride when you are sitting across the park, enjoying a beverage or waiting for a different ride.  This transparency allows you to plan to make the most of your time in the park.  If there is a ride you are only mildly interested in and it has a 45 minute wait, you might decide to pass on it.  If there is a must-do ride and the wait drops to 15 minutes, you might run over there to take advantage of the lull.  I liken the posted wait times to a Product Management Roadmap.  Our customers want to know when a specific enhancement or feature will be available.  The timing doesn’t have to be extremely precise, just as the Disney wait time cannot be calculated to the exact minute, but it does need to provide an idea on when something can be expected so your customers can make informed decisions about what they are going to do.  If a critical feature for a certain customer is on the roadmap in the next quarter then they can plan how best to take advantage of that feature and perhaps even plan coding on their side if integration is required.  Being provided with time-frames helps us to organize our agendas and maximize our resources and time.

Marketing Speak

Sometimes our efforts to speak in glossy marketing terms can go to far – to the point that no one knows what you are talking about anymore.  Let me provide two examples:

  1. Mad Tea Party – spinning ’round in a cup.
  2. Storm Force Accelatron – help the X-Men’s superhero Storm in her battle against the evil Magneto.

The first example is from Disney’s Magic Kingdom – a bit light on words, but pretty descriptive.  The second comes from Universal’s Islands of Adventure.  The ride sounds wicked and I totally want to help Storm defeat evil forces, but I have no idea what the ride actually does.  Would you believe that is the same ride?!  Disney’s spinning apparatus is a tea cup, Universal’s is some sort of electron, but the essence of the ride is the exact same.

The lesson for us Product Managers – don’t get so caught up in being cool that you lose sight of the information that you need to convey.

Cost vs. Value

Perhaps the most valuable lesson that Disney has taught us is that people – millions of them, in fact – are willing to pay premium prices for a great service. The amount of money that we spent for our one week vacation is painful to think about.  But we were willing to pay it and we have no regrets because the service was differentiated, reliable and we valued it. There is no place in the world like Disney Parks with their characters and perky cast members and unbridled enthusiasm for creating a Magical Experience.  What they do is differentiated – it sets them apart from the local Six Flags. The service is also reliable. Whether you go in December or June, in rain or heat, on a Tuesday or a Saturday, the Disney crew is going to greet you with the same energy and joy. You can tell your friends and neighbors about it and feel very confident that they will have the same experience. And finally, the service is valued.  When my ten year old daughter looked up at me and said, “Mom, there is no place in the world that I would rather be,” that is valuable. And I am willing to pay for that kind of value.

As product managers, we shouldn’t shy away from premium pricing if (and it’s a big IF), we are delivering a service that is differentiated, reliable and valued. People will pay for great experiences.

In conclusion, we product managers can learn a thing or two from Disney – or perhaps just reinforce what we already know. Roadmaps with “wait times” help people plan, marketing messages that are too clever could fail to provide the necessary information and premium pricing is warranted for great service.  Thanks, Mickey, for a great week and memories that will last a lifetime.