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.
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.
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.
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.
Happy Holidays! Our Introduction to Agile Methods textbook is on sale at the InformIT website.
Through Saturday, 11/29
Please use this link and use discount code BF2014
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)
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.
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.
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.
The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could have, 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.
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. 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.
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
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.
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.
- 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
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.