Archives for Jun,2015

I recently was visiting with a potential client about the need for a Product Owner.They asked: “How much time will the person assigned as Product Owner need to dedicate to this project?”

This is a very common question that we get from clients. The answer I give is always the same: “How important is this project to your organization?”

The response is almost always the same: “This project is part of our strategic objectives and it is crucial to the company’s success, but we can’t spare a Product Owner for that much time.”

This is where things get interesting.

If a project is critical to your organization in any way, you must provide a dedicatedProduct Owner.

If you can not provide a Product Owner, your project is doomed for failure.

How can you not dedicate someone to work with the team to ensure that it delivers that highest values features, to inspect and adapt during the course of delivery? Why would you not want someone working with the team to help them understand each piece of functionality from the perspective of the users?

Why would you not want a Product Owner to learn about the new technology, to learn the advantages, disadvantages, and conceptually how all the pieces work together? Why would you not want a Product Owner to learn to communicate with the team as well as outside stakeholders?

Why would you not want the project to be a success?

Let’s state this in another way:

You would never plan a wedding by contacting a wedding planner, provide a few requirements, and then just show up on the big day.

You would never build a house by just approving architectural diagrams without doing continuous walk-thrus during the building process.

You would never trust a financial adviser to ‘get you to your retirement’ without constant planning sessions to review your needs, goals, and priorities.

No matter how much effort you take in creating a top notch, high performing, self-organized team, they will only be as successful as the quality of the Product Owner. Even the best teams need to understand the value stream of an organization. They need someone to help keep them on the right path. If left to their own devises, the team will build what they THINK is important rather than building something they KNOW is important. This will most certainly not provide items of the highest value. Priorities shift, requirements change, objectives change, customers change – the team needs someone to help them understand all of this.

My first experience with Agile occurred due to my quest to write better User Stories. As a new software development manager, I realized that the team’s biggest problem was estimating. I found the book Agile Estimating and Planning and it changed everything. It set us down the path of creating User Stories instead of using the CRD (Customer Requirements Document) that we had previously been using.

Over the next decade, I focused on writing good User Stories. I became an expert on INVEST, using it to determine if a User Story was well written.

One of the most critical aspects of a User Story is it’s role as a place holder for a conversation. As a reminder, a User Story is made up of a Card, Conversation, and Confirmation.

Somewhere along the way, teams have forgotten about the Conversation. Teams almost exclusively focus on the mechanics of User Stories. Why? I’m not sure. Maybe it’s because the mechanics are what everyone is worried about. Mechanics are concrete and familiar. They are closer to the old way of doing things.

The risk when focusing on only mechanics is that your User Story becomes a contract. You are leaving Customer Collaboration over Contract Negotiation from the Agile Manifesto in the dust.

While watching some YouTube videos on Story Mapping, I stumbled across an interview with Jeff Patton. Here, he gives a brief history of how User Stories started:

.

Watching this reminded me of what User Stories are supposed to be, not what they’ve become: contracts. It’s easy to ignore the Negotiable part of INVEST.

Here is how to write good user stories:

Focus on the value to the customer: why they want to perform some task, not just what they need to do.

Don’t strive to define every possible scenario in a User Story in the planning session. If you do this, you are eliminating conversation that needs to be occurring for the rest of the iteration.

Don’t assign the responsibility of writing User Stories to one person. Writing User Stories is a collaborative effort. It’s best to include the whole team.

Don’t be a slave to a User Story format, i.e. “As a …. I want … so that“. It’s a great place to start, but if there is a way that works better for you, go for it. A User Story is just a placeholder for a conversation.

Do not treat a User Story as a contract. It will change throughout the iteration as the team gets feedback from the Product Owner, SMEs, Stakeholders, etc. This is Agile.

Run every User Story through the INVEST litmus test. It works. It may be hard at first, but it gets easier over time.

There are a lot of articles out there about writing better User Stories with great information about mechanics. However, many imply that the only conversation required occurs during the iteration planning session.

Let’s set this straight: The conversation is over when the User Story is done.

If your team could use help writing User Stories, contact One80 Services. Our existing course, Agile Requirements & User Stories might be something you find helpful. We’re also available for customized training and coaching – just drop us a line.

Today we went to the Scott Conference Center at UNO Peter Kiewit Campus to talk with the PMI Heartland NE/IA Chapter about the science (Emergenetics) involved in creating and running a successful Agile team.

We all know that Agile is all about self-organized and empowered teams delivering value to the customer. How do you know that you have assembled the right team?

In this workshop, we learned how to us Emergenetics to motivate and design teams that align to a project’s objectives, environment, and organization.

We discussed factors that influence team dynamics and how they can be harnessed to make teams and projects successful.

It was a fun and worthwhile event. Kudos to Nick Kramer, Managing Partner of One80, for a great presentation and workshop!

Thanks go to PMI Heartland for hosting this event, and Mutual of Omaha for sponsorship.

If you would like to learn how Emergenetics can help your teams, or you would like One80 to speak at an upcoming event, talk to us today!

A huge form of waste (leading to Agile failures) many people don’t talk about are those features we build “just in case” we might need them some day.

I think that those involved with building a product often forget that everything we build costs something. Nothing is free. Who’s paying for it? The customer.

Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.

There are certain phrases that I listen for such as, “it would be cool if…”, “someday we might want to…”, “what if a client requests …” etc. Some Product Owners want to build to accommodate edge cases that are often so ridiculous that they would never happen.

What gets really tricky is when there is only one SME in the product group, and no one else really knows that domain. In those cases, that SME acts as the Product Owner and has the power to create work that may actually be of little value and may lead to the snowplow trap.

The only way to get around this is to fearlessly and relentlessly ask “why?”. In these situations, there is typically a touch of fear that compels the team to simply accept directives rather than asking probing questions.

A good way to think of this is to envision a funnel. Only so many widgets can fit into the funnel at a time. If you need for a specific item to go through the funnel, something else is not going to get to pass. This is very much like building a Product.

Only so many pieces of functionality can be built. Eventually the project ends or funding is eliminated and you are left with features that did not get built, while ‘never to be used’ functionality was completed. Some of the functionality that was not built may have had business value and\or high ROI. This is waste and is often perceived as an Agile Failure when in-fact it is a Product Owner prioritization issue..

There are some ScrumMasters (and Project Managers) that typically stay out of those kinds of details. Yes, the team is self-organizing. Yes, the team has to learn by making mistakes. However, the ScrumMaster has to be involved enough to not allow the “just in case”methodology take hold. If it’s allowed to happen, you will find that what you have delivered in the end is not of the highest value.

Learning to be a good Scrum Master is hard, but how does a new Scrum Master learn the the mastery of Scrum?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome-again, open and engaged. The thing they all had in common was that they wanted to be better and they wanted to learn Scrum. I was one of group that introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my teammates were the ones that really knew what to do anyway…so why not give them the tools and empower them and help them to focus on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After those first (great) experiences, I became an agile coach. Now it was my turn to help teams transition to Scrum by educating the team, Product Owner, and Scrum Masters. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

There are three options/approaches to helping others become Scrum Masters.

The Coach Leads

With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and assists. Then, after a while (depending on the Scrum Masters comfort level), there is a switch, and the coach becomes the observer/helper.

The Coach Observes

Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

The Coach Advises

In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise and hear situations from a third party perspective. The new Scrum Master and coach meet regularly to go over gotchas, smells, and issues, etc. This approach works well for Scrum Master who just need to bounce ideas off of a Coach or validate their approach.

Coach? What Coach?

This is how I learned. We didn’t have a coach. But, we were completely empowered to do what we needed to do to be successful. And, there was buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. It is rare to work in this kind of environment and going down this road can lead to great success or bigger failure. Choose wisely!

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option? It depends on the experience of the new Scrum Master and the team. It also depends on who the coach is in the organization. If you are introducing Scrum and have hired an independent consultant (coach), #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if the organization is backsliding, then #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 fits the bill.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So if you do decide to do it on your own get some formal training from experts or start reading. Read, read, read, and read some more.Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Many people post awesome information and articles that are thought provoking and free.

If you are looking for Agile or Scrum Master training check out this link for amazing Agile Training

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?