Lessons from an Ironman

My husband completed his first Ironman in Panama City, Florida. Something remarkable happened during the race and it makes me ponder similar implications in the work place. My husband’s watch broke. Actually, his second watch broke. The first one was kicked off and now sits on the ocean floor of the Gulf of Mexico. The second watch went black 90 minutes into the bike ride. So here he is, doing his first Ironman and he has virtually no ability to pace himself. The only way that he can ‘tell time’ is to watch the path of the sun and the only way he knows his relative position is to pass a mile marker, gauge his approximate speed and use that information to make decisions about nutrition and his pace.ironman2

As I am sure you can imagine, Ironman races are incredibly difficult. It is a 2.4 mile swim followed by a 112 mile bike following by a 26.2 mile run (a full marathon). Many well-experienced athletes have made the mistake of going too hard in the swim or the bike, only to find that their body doesn’t have enough energy left to finish the run. This is a very real risk and one that should not be taken lightly. So how do you, as a first time Ironman, pace yourself on the bike when you have no timepiece? Well, you do your best. And you listen to your body. And guess. And maybe pray a bit.

5 Tips for a successful cross country move

I recently accepted a job in San Diego, CA.  Awesome, right?  That is 1,733 mile from my current home in Waukee, Iowa (a suburb of Des Moines).  This should be a piece of cake. The weather is better – beaches, oceans, the Zoo.  It is a great opportunity and I know that we will be happy here.  After all, we have done this before.  In 2010, we moved from Austin, TX to Waukee, Iowa which is a distance of 927 miles, for those keeping score.  So why is this so hard? Why do we have moments when we feel like the family is coming apart at the seams?  We have learned a few things along the way so here are our 5 tips for making a cross country move a success.

Source: Google Maps

Source: Google Maps

1. It’s about the family

The greatest job in the world cannot make up for an unhappy spouse and kids.  Make sure they are invested in and excited about the move.  Every city has very cool features – the corn mazes in Iowa are amazing!  Find out what is special about your new destination and celebrate it.

Also remember how important your spouse is.  Moves are often easier on the working spouse as they have an instant community at the office, and the kids will adapt to their new friends at school. It’s critically important that the “support” spouse has a support system of their own.  Neglect that piece of the puzzle and ‘successful’ may not be the word used to describe the move.

2. It’s about the message

When it comes to getting the family excited, choose your words carefully.  If you say to the kids ‘I know you have great friends here and I am sorry that you have to leave them,’ you are setting a tone.  If you say ‘This place is so cool.  You won’t believe all of the activities and awesome adventures we are going to have,’ then you are leading with positivity and this can make a huge difference in the perception of the kids – especially those in elementary school.

Sale on Agile Textbook

Happy Holidays!  Our Introduction to Agile Methods textbook is on sale at the InformIT website.

cover

 Through Saturday, 11/29

Please use this link and use discount code BF2014

Details: Buy 1 – Save 35%, Buy 2 + – Save 55% on Books, eBooks, Online Learning, Video Tutorials, & Software Sunday, November 23 – Saturday, November 29, 2014 (expires 11:59 p.m. EST on 11/29)

Sunday and Cyber Monday (12/1)

Please use this link and use discount code CM2014

Details: save 70% off featured video and 50% off all other eBooks and digital video training! Sunday, November 30 – Monday, December 1, 2014 (expires 11:59 p.m. EST on 12/1)

Prioritization – Part 3: The Kano Model

Being a Product Manager and an Agile enthusiast, I spend a lot of time and energy working on prioritization.  It is both an art and a science to make sure that you and your team are working on the most important thing.  The first in this blog series on prioritization answered the question “Should we do this at all?”  and the second shared different tools to help with prioritization, specifically MoSCoW and the Risk-Value Relationship.  In this blog, we will tackle the Kano model, which holds a special place in my Agile story.  I first learned about it when I was doing research for our Agile textbook.  It then found its way into Businessolver and was a part of the story regarding how we addressed our Product Roadmap.  Very cool.

Kano Model Explained

First introduced in the 1980s by Professor Noriaki Kano, it is a great tool for Product Managers to use when assessing different kinds of value.  The vertical axis represents satisfaction.  The higher you are, the more satisfied you are – one might say ‘delighted’ to put it into Businessolver terms.  The horizontal axis represents how well something is done.

Source: Businessolver

Source: Businessolver

Looking at the grey line first, these are basic needs – the ‘must haves.’  Thinking in terms of a hotel experience, we expect there to be hot water.  Hot water is table stakes for a hotel experience.  If you don’t have hot water, meaning the establishment didn’t do it well, then you are highly dissatisfied.  However, if the hotel did have hot water, meaning they performed that function very well, it does not delight you.  It is expected, so when done well, it doesn’t even register in your mind.

The blue line represents performance needs.  This could be the check-in process at the hotel.  It has the opportunity to dissatisfy – if the lines were long, the desk clerk inefficient or your room wasn’t ready – those circumstances could be very disappointing.  Conversely if they recognize you when you walk in and you are greeted with speed and efficiency, then you might be pleasantly surprised, heading towards delighted.

Prioritization – Part 2: MoSCoW and Risk-Value

As introduced in the first blog, prioritization is difficult.  The first and most important question is “should we do this at all?”  Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue.  There are a number of tools that we can use in this effort.

MoSCoW

The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could moscow_blog2have, Want.  The technical definition for each category is as follows:

Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

Should have: features of this priority are important but can be omitted if time or resources constraints appear.

Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

To put MoSCoW  in action, we pull a reference from our book, Introduction to Agile Methods.  In this example, we are looking at the payment methods that could be offered on a new eCommerce site.

Must have: ability to accept Mastercard and Visa

Should have: add American Express and Discover

Could have: add ACH payments for transactions directly through banking institutions

Want to have: add gift cards

By understanding where each feature falls relative to the MoSCoW parameters, the prioritization is much easier.

Prioritization – Part 1: Should we do this?

As a Product Manager and an Agile Enthusiast, I have lots of conversations about prioritization.  It is really tricky.  Well, that’s not always true.  If you really only have one thing to work on, then I guess it’s easy.  For the rest of us that live in the real world, we have to balance multiple number one initiatives in a way that will deliver the most value to the business.  This is a first in a blog series about Prioritization.

The First Question

The very first question that should always be asked when considering something for prioritization is – Should we do this at all?  People are too often moving too fast and trying to be responsive to the point that sometimes we stop thinking.  One of my mentors had a saying:  “This is top of mind, not top of list.”  I love that.  I first heard this when he called me after just having talked to an important client about a feature they wanted.most_imp  He was excited and it was a good idea.  I asked him if he felt like we should reshuffle our priorities and execute on this newly introduced concept.  He paused and took a moment to really think through my question.  And then he responded with the now often quoted “Top of mind, not top of list.”  That is a fantastic barometer to keep in mind when you have a flash of brillance.  It might just be a flash and you need to stick to your existing priority list.  Bright, shiny objects can come into view, but they do not always warranted our immediate attention.

Hiring a Product Manager

Image source: http://www.rochester.edu/working/hr/employment/

Image source: http://www.rochester.edu /working /hr/employment/

Having moved from Austin, TX to Des Moines, IA to San Diego, CA, I have had to learn a few things about hiring product managers.  In Austin, Product Management is a well-known profession and many talented people who are either natural product managers or trained ones are available for hire.  Des Moines, like many areas in the country, is not a product management town.  It is full of wonderful, hard working people but with industries centered around insurance and agriculture, there has not be high demand for product management, as a discipline.  This is changing, both with the enthusiasm around Agile as a software development methodology and the increasing number of start-ups in the “Silicon Prairie.” The need for product managers is, therefore, on the rise.  If you are tasked with hiring Product Managers, here are three tips to help.

Comfortable withOUT a job description

For nearly every job that I have had, I have lacked a job description.  Not only am I comfortable with that, I actually prefer it.  And I think most natural Product Managers feel the same.  Of course, we all want to know the rough boundaries around our job but we tend to be very comfortable with ambiguity.  A product manager’s job may range from strategic product visioning to market research to customer interviews to tactical prioritization to sales training to process documentation and much more.  What you intend to get done when you arrive at the office may differ completely from your accomplishments at the end of the day.  As one of my colleagues so eloquently stated, “A product manager is the CEO of that product” and just like company CEOs, you have to roll with the punches and respond to the needs that are presented that day.

Agile 2014 Recap

Here is another guest blog from my co-author on the Introduction to Agile Methods textbook, Dr. Sondra Ashmore (@sondra1130).  This is her recap of the Agile 2014 Conference in Orlando, Florida.

Agile 2014 Recap

Sondra Ashmore participating in 3D Pair Programming Session.

Sondra Ashmore participating in 3D Pair Programming Session.

I think I have finally recovered from the excitement of Agile 2014 that took place in the fun and sun of Orlando, Florida this year.  I found it very invigorating to spend the week with nearly 2000 fellow Agile enthusiasts from around the world.

When I initially signed up for the conference, I decided to fill my schedule with a variety of different sessions from the wacky (Agile Karaoke) to the more traditional (Agile Enterprise – Are You Ready?) and finally some research sessions to satisfy my academic side.  I was glad I did because it helped me get a general feel for the current trends in Agile and forced me to look at my world in a new way.

 

Lessons from an Author

The fact that I can title this blog “Lessons from an Author” is both amazing and surreal.  You see, my first book was just published so I guess I can officially say that I am an author.  (Buy it here!) Holding the book in my hands led me to reflect on the last 18 months and the journey that my co-author, Sondra Ashmore, and I have been on.  For what they are worth, here are the lessons that I have learned along the way.cover

Persistence Required

When writing a book, or doing any meaningful and challenging undertaking, you must have persistence.  This is obvious, I know, but let me share the backstory.  There were two chapter in our Agile textbook that were particularly difficult – the chapter on roles and the one on culture.  Not that we didn’t have plenty of content, that was never the problem.  It was trying to figure out a way to convey the information in a logical and cohesive fashion.  Each chapter was re-written nearly from scratch three times.  By the time you are writing a chapter for the third time, it is easy to get frustrated, depressed, aggravated, annoyed (can you tell that the memories are still fresh??) and a whole host of other emotions.  This is when you need someone to pull you back to the surface.  In my case, I was lucky to have Sondra.  In my time of doubt, Sondra reminded me that this is the time and circumstances that separates published authors from those with unpublished work sitting in a drawer.  It is persistence.  Pure and simple.  There are lots of great writers out there.  But persistence is the distinguishing trait for true authors.

Agile Book – Culture

For the final blog post in our series about our upcoming book, Introduction to Agile Methods, we are going tackle the cultural impacts of an Agile implementation.  Agile is a simple set of concepts to understand (once you read the book, of course) but that doesn’t mean it is easy to implement.  It can be challenging for organizations to adopt principles like self-organizing teams, continuous improvement and frequent delivery.  This chapter examines creating an Agile culture from the perspectives of a team member, manager and an executive.

Learning Objectives

  • Understand organizational culture and why it matters in an Agile implementation
  • Dive into ways things might be different in an Agile organization from a developer, manager, and executive viewpoint
  • Look at successes and failures in behaviors to see the cultural impacts
  • Understand how the Agile principles drive different behaviors in an organization
  • Investigate the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective seating arrangements, incorporating virtual resources, and adapting to the changing environment
  • Explore how an Agile workplace differs for managers and the ways that they must change with regard to teamwork, trust, and transparency
  • Review the role of executives and how their behavior can position an Agile transformation for success with executive alignment, respecting priorities, creating supportive environments for the teams, and driving the right behaviors with metrics

There is so much great content in this chapter, it is hard to pick one excerpt to spotlight.  We chose the executive viewpoint and how important it is for the executive sponsor to embrace the change and provide consistent leadership.

Staying the Course

Image source: http://blog.lifestyleforhealth.com/stay-the-course-guest-blog-by-anna-townsley/

Image source: http://blog.lifestyleforhealth.com/stay-the-course-guest-blog-by-anna-townsley/

An Agile transformation is challenging for most organizations. Some command and control managers will fight the change, offering dire predictions of failed projects as examples of why this is a bad idea. Developers may not embrace the increased accountability and transparency, and some may choose to leave the organization. There are new expenses in the form of seating arrangements, training, and Agile tools that may stress the budget. Agile transformations also have a history of bringing chronic issues that the organization has ignored for years to the surface where they must be confronted. All of these are reasons why an executive might abandon the effort and simply revert to what is comfortable (but ineffective). Any change worth making is going to require effort, and Agile is no different. The strong Agile executive will work through these issues without wavering on the commitment to Agile.