Data Privacy Policies

See our Privacy Policy page for details about the data we may collect from visitors and other users of this site. We do not necessarily collect all that data, but it is possible.

At this point in time, this site is not active and exists as an archive of information. So we actually collect less data now than we did in the past.

This is a WordPress site and WordPress uses cookies. We are not using any kind of Analytics, so we are not storing IP addresses or tracking visitors. At present no new accounts or comments can be created. If you use a form on the User Data Request page, then we will receive and use your email address as indicated on that page and only for the purpose indicated. Otherwise, you can browse anonymously – we will not even know you have been here!

If you created an account on this site in the past, your account information is still in our database. You can log in and change that information yourself, or ask us to do it through the User Data Request page. If you created posts, they are still in the database. You can edit them or remove them.

If you left comments on this site in the past, those comments were stored in our database with your name, email address, and IP address. If you want changes made to any of that data, use the User Data Request form to let us know what needs to be done.

Taking a Hiatus

Tom, Kyle, Mike, and I have been pursuing various projects lately and have not really had time to write on this blog. But there is a lot of great information here, so do feel free to browse around.

Tom is currently focused on his blog at Tom Meloche Blog

Geri is currently working on publishing a series of Agile books for Executives. See Geri Schneider Winters site for information on her books and how to contact her.

Mike is currently focused on his blog at Mike Russell Blog

I am not finding an Agile blog for Kyle – I think he has been busy with his employer’s Agile transformation and so is not posting externally right now 🙂

What is a Product Owner?

I see so much confusion around the role of Product Owner. A lot of the reason is that Scrum does not really specify anything except how a group of people will work together to achieve a purpose. All the roles are poorly defined. This was to provide maximum flexibility to allow Scrum to be applied to any kind of work. But it has led to a lot of confusion.

We can tease out what a Product Owner is by looking at the responsibilities of a Product Owner and compare them to other more well-defined roles.

Essentially, a Product Owner is responsible for the vision, goals, or direction of the team and the prioritizing of the work to achieve the vision, goals, or direction while maximizing value.

What does this look like in real life? Because of the Product Owner level of responsibility, a Product Owner looks most like a Product Manager.  Which will not help you figure out what a Product Owner does if you do not know what a Product Manager does! So let’s consider some scenarios.

Assume you have an idea for a product. This is something you are passionate about, so much so that you decide to create that product and get it to market. You do not know how to actually create the product, so you find a few people to come and work with you on the product. You all get together in your garage every day to work on the product.

You start by sharing your vision with the team. This is the problem you have seen, this is the product you envision, this is how the product will change the world. The team gets really excited. You have long conversations together about the product, how it might work, what it looks like.

You go off and do market research. What has already been done? What do people like about the other products, and what do they dislike? Meanwhile the team starts researching ideas for how to create this thing. You are in the garage together all day, talking with each other and sharing what you know. You tell the team what you are discovering about the product, the need, and the market. The team shares with you what they are finding out about potential solutions and what it will take technically to create this product.

Together you and the team come up with a list of things to work on. Some of the things are little tests of pieces of technology to see if they will do what is needed at a price that makes sense for your product. Some of the things are features you want to start showing to focus groups. The team gives you estimates of how much effort it will take to complete each work item. You take that information and what you know about the importance of each item and suggest to the team which items to work on first. They argue with you about a couple of them, but in the end, you all agree on the first work items that the team will implement.

Since you are in the garage with the team, they bring things for you to look at every day. This turned out really well, but this idea was a big mistake. What do you think of this design? You and the team talk all the time about what is working and what is not. You make adjustments to the list of work items based on what you are learning.

At some point, you have enough to share with some potential buyers of your product. You get feedback on what they like and what could be improved. You take that information back to the team and have great discussions about what you learned and how it will impact the design, implementation, or priorities of the product.

You are a Product Owner interacting with your team. It is your money funding the product, so you own the product vision, direction, and priorities. But you are always working with the team to shape that vision, direction, and priorities because they are the ones who know how to make your vision real.

Let’s take this a step further. You don’t have enough money to go to market, so you find some people to invest in your product. Now you have some additional responsibilities.

Most investors will not just give you money and walk away. You have frequent meetings with the investors, sharing with them what you are discovering about the market and what the team is learning about how to build the product. The investors talk with you about budget and what they see are important features of the product. While you are still responsible for the vision and the ultimate success of the product, you have to also take your investors concerns into account.

The important thing is YOU ARE STILL IN CHARGE! You are not a spokesperson for the investors, doing whatever they tell you to do, and passing that on to the team. But just as you had to modify your vision as you learned about implementation from the team, you also have to modify you vision to meet the realities of investors wanting a return on their investment. You just wanted a product; the investors also want to make money.

You have discussions with the team about costs. They may find a less expensive way to do something; you may rearrange the order of work to focus more on desirable but low-cost features, leaving expensive features for later after the product is making money.

Now you are probably thinking, this sounds really nice, but I work in a corporate environment. What does a Product Owner look like there?

It should be the same. Basically pick up that whole team I just described and put them in a corporate setting. Instead of investors, you have a VP with a budget they gave you to develop a product or service. If the company truly believes in the Product Owner role, then you should behave exactly as if you are that passionate person who believes so much in a product, that you spend your own money to develop it.

You sit with the team all the time.

You research the market, competitors, options, users, subject matter experts.

You talk with the team about how they would go about creating the solution. You ask the team for several ideas and the relative effort of implementing those ideas. You have conversations with your VP (investor) about the best way to spend the money. The VP leaves the final decision to you, knowing that you will spend the money in such a way as to get the most value.

You have the autonomy and the authority to make the decisions that lead to the highest value product that you can deliver within the budget allowed. You do this after having conversations and considering the needs of the VP, users, other stakeholders, and the team. Your VP/investor and your team trust you to identify the highest value items. You trust the team to implement the solution effectively, efficiently, and with high quality. You trust the VP/investor to give you the best information about corporate direction and priorities.

That is a real Agile Product Owner.

If you have your VP /investor telling you what to do, then you are in a command and control environment. You are essentially working as a Senior Business Analyst, passing commands from your stakeholder to the team. If an Enterprise Architecture team is telling the team how to create the solution (instead of having conversations with the team about possibilities), you are not in an Agile environment. If a committee of subject matter experts is evaluating solutions without involving you, then telling you what solution they picked for your team to implement, they are not treating you as a Product Owner. You are in a command and control environment.

Agile is about conversations. It is about empowering people to be part of the solution.  It is about trust.

Geri’s New Book available June 19! Free June 19, 20, 21 on Kindle

My newest book “Do We Need Managers?” has been published in print and on Kindle.

So many companies are experimenting with complete self-management. There are regular news reports of yet another company throwing out all the managers. While I have certainly seen plenty of bad managers in my career, I am not convinced that management is inherently bad. So I decided to take a balanced look at all management roles.

This small book is an exploration of the role of manager – line manager, middle manager, and executive. It answers a number of questions:

  • How and why did the various kinds of managers come about?
  • What was their purpose?
  • Does that purpose exist today?
  • Does it make sense to get rid of all the managers?
  • How many managers do we really need?
  • What do managers do that hurt the company?
  • What can managers do to be of real value to the company?

For the launch of this book, I am offering it free on Kindle on June 19, 20, and 21, 2018. I’ll update this post with a direct link to the book the morning of June 19.

Here is the link: http://bit.ly/needManagers

Be sure it shows $0.00 to buy. I have attached a screen shot that shows where they put the purchase price (Amazon promotes Kindle unlimited so much that the actual sales price is a bit hard to find).

If you do read it, I’d love it if you leave a review on Amazon.

Thanks!

Geri

Geri Schneider Winters

Launch of Geri’s Latest Book

Did you get your free Bonus Materials for my new book “Why Agile is Failing at Large Companies (and what you can do so it won’t fail at yours)”?

Visit the book website at http://agileisfailing.com and click the BONUS Materials link on the upper right of the page.

You can also add your email to my notification list. You will get notices when I post new bonus material, hold webinars, speak in public, or publish another book.

Thanks to everyone who is supporting the launch of my book. I am most grateful.

Scrum Roles – One Liners

Scrum Master – enable the scrum team to work as efficiently and effectively as possible

Product Owner – ensure there is a steady stream of well-defined valuable work available for the scrum team to work on

Team Member – work together to deliver high-quality production ready results at a steady, sustainable pace

Business Transformation Digest: December 11, 2015

As I create these digests, I keep seeing business transformation basically being described as a move to the cloud and mobile. I like that this article from Gulf News Technology reminds us that moving to cloud is just replacing one technology with another. True business transformation has to include people and business process changes to reap the full benefits.  A lightweight article but a good reminder:

Driving Business Transformation Through Cloud Services

Don Tennant at IT Business Edge discusses the need for reducing legacy investment and starting to spend money “stepping up” to modern technologies with João Baptista, president of Eastern, Central, and Southern Europe operations at CGI, Montreal, Canada.

Saving IT Budgets from the Legacy Quagmire

CGI’s research and whitepaper “Keeping Up versus Stepping Up” can be found here:  Keeping Up versus Stepping Up

BuiltIn Austin offers ten bold predictions for what digital transformation will mean over the next five years.

Leading Digital Business Transformation in 2016

An article in this week’s Harvard Business Review about how to help people open up when talking to you really caught my eye. If part of your business transformation is to encourage honest, transparent communication, an important part of that is how to influence people to want to do that. Non-verbal cues can help the people you are talking with open up or shut down.

Nonverbal Cues

My offering this week addresses the tendency to jump in and just do it. While a lot of up-front planning may be counter-productive (no plan survives contact with reality), some up-front planning can save you a lot of grief. I address specifically Agile transformations, but the same mindset applies to any business transformation.

http://www.tomandgeriscrum.com/2015/12/07/why-starting-an-agile-transformation-by-hiring-coaches-is-bad-idea/

Why Starting an Agile Transformation by Hiring Coaches is Bad Idea

I see so many Agile transformations go like this.

“We want to be Agile. Put out an ad for Scrum coaches (or XP coaches)!”

The next thing is that a bunch of coaches are brought in from many different places, each with their own ideas, and they start working with teams. The result is generally chaos, confusion, fear, uncertainty, and doubt.

As time goes on, issues get worked out, teams show they are doing Scrum (or XP), and the coaches move on to the next engagement. Then the teams start backsliding, returning to how they worked before the Agile coaches arrived.

Why?

To bring about lasting change in an organization requires far more than coaching individuals and teams. While needing to know a new skill is important, it is only one factor in bringing about change, and it is the weakest way to influence change.  This is not where a business transformation should start.

To enact real change requires you to start with a clear, measurable, compelling goal. Without this, there is no purpose to coaching since we do not know what we are coaching toward. Note that “We are implementing Agile” is not clear, measurable, or compelling.

Consider WHY you want to make a change. What do you expect becoming Agile will do for your company? How will employees’ lives be better after the change? Why will this be better for your customers?  Good marketers know that the most powerful question to answer is WIIFM (What’s In It For Me). Everyone impacted by your change needs to know what is in it for them personally. This is how you make your goal compelling.

Now that you have your goal, what are the things today that are preventing you from being where you want to be?  To answer this question, it can be helpful to consider an influencer framework.

There are many influencers of behavior at any company. The team at VitalSmarts described 6 categories of influencers in their book “Influencer” by Grenny, Patterson, Maxfield, McMillan, and Switzler. Start with the 6 categories and find what things in each category are preventing you from achieving your goal.

These categories are:

  • Personal motivation – what is motivating individuals to not make change.
  • Personal ability – what skills are they lacking that they need in order to make change
  • Social motivation – what is their community saying that opposes the change
  • Social ability – what assistance is lacking in the community that someone needs in order to change
  • Structural motivation – how are we rewarding people for staying with the old way of doing things (metrics, money, praise, promotions)
  • Structural ability – how are the physical space, business structures, and business processes preventing people from making change

I think there is another category to consider as well, and that is what behaviors are the managers and executives modeling? People watch successful people and copy them. If the managers and executives are acting opposite to the new way of being, it will be hard to get anyone to change. People will do what you do much more than they will do what you say. Actions do speak louder than words.

Social influence is by far the strongest influencer and should be addressed long before coaching of individuals and teams is considered. Who are the people that others look up to? How can you convince them to champion the change to Agile? Besides talking, what programs can you set up, set as peer mentoring, an Agile community, or a Scrum Master guild that will show people that their social community supports the change?

Structural influence is also much stronger than individual skill or motivation. Many in the Agile community are aware of the importance of physical space to Agile adoption. But if the business processes, metrics, and rewards are for behavior counter to Agile, then coaching individuals and teams in Scrum and XP practices is a waste of time and money. Change of the cultural and physical environment must come before considering bringing in coaches for the teams.

Executives have tremendous power to influence change and so helping executives model the desired behavioral changes will have a strong impact on an individual’s willingness to change.

Now executives are not going to be doing XP practices, and probably not most of the Scrum practices. But what they can do is model fundamental behaviors that Agile depends on such as honest and transparent communication, using failure to learn (instead of punish), working collaboratively with their peers, and recognizing that they do not have to be right all the time, they need to know how to quickly correct their course when wrong.

Modeling these behaviors sends a powerful message to the organization that everyone should behave the same.  While training is good, reinforcement with executive coaching on these leadership skills will help executives maintain the new behaviors.

With all that in place, most individuals and teams will quickly pick up the basics of Scrum, XP, or other Agile practices. You can send them to outside classes or offer training inside your company.  There will likely be a need for some team coaching for a month or so to support the team as they begin applying the new practices.

As more teams take the training and adopt the practices, the need for Scrum or XP coaches goes away. What you need after that are not generic Scrum or XP coaches but rather experts in the specific areas where teams are struggling.

Are teams having trouble forming? You need an expert on team formation to come in for a short engagement to find out what they are missing and point them on the right path. Teams do not understand pairing? Find someone with extensive experience using pairing in their work and bring them in for a short engagement to find out the problem and help the teams overcome it. Having trouble with retrospectives (this is common over time)? Bring in someone who has many years experience perfecting the art of the retrospective to help the teams learn new and better ways to conduct them.

You do not need long term “Agile” coaches. You need to use the 6+1 areas of influence to create a culture where behaving in an Agile manner is the most natural thing to do. You need people to be good at coaching each other.  Then, as teams grow in knowledge and experience with Agile, you may need targeted coaching by experts to help teams with specific issues.

If you are finding a need for a lot of Scrum or XP coaches over many years, look at the 6+1 areas of influence and find out what you are putting in the way that is preventing your teams from maintaining the Agile practices they learned.

Business Transformation Digest: December 5, 2015

Telling your story in your marketplace is really important for finding and engaging with your customers. The ideas in this article apply just as much to telling a story internally about your business transformation. A compelling story will get people excited and motivated about the changes you bring to your company.  Read this article and think about how you could use the ideas to market inside your own company to promote your initiatives:

Storytelling in Business: Lessons for Brands of All Sizes

This article from Knowledge Path reminds us that we have to look inside our own company to find opportunities for improvement. Instead of just maintaining the status quo, we should have processes in place for continuous improvement.

Business Transformation: Questioning the Status Quo for Positive Change

Another little gem from IT Pro Portal summarizes a recent survey of IT frontline workers around the world conducted by BPI Network. It points out the problems with business transformations and offers some tips for a successful process. The article includes a link to the original paper.

What’s Holding up the Transformation?

An article at Enterprise Irregulars summarizes a variety of research done by other companies that paints a pretty dismal picture of what business leaders think of the CIO and IT.  It clearly shows that CIOs (in general) have done a poor job building trusting relationships with their business counterparts and a poor job delivering business value. Food for thought:

What do Business People Think of their CIO?

My own offering this week concerns what makes a great leader of an empowered organization.

http://www.tomandgeriscrum.com/2015/11/30/if-it-is-not-command-and-control-what-does-the-executive-do/

Finally, some papers you can review in your “spare time”.  Cisco and IMD released the “Digital Vortex” report earlier this year, investigating “How Digital Disruption Is Redefining Industries”. If you have not looked through it yet, pick up a copy here:

Digital Vortex

After reading that, you might peruse the other 3 related documents they released in November:

Disruptor and Disrupted Strategy in the Digital Vortex

Competing in the Digital Vortex: Value Vampires and Value Vacancies

New Paths to Customer Value: Disruptive Business Models in the Digital Vortex