Category archive

Product Management - page 2

Behaviors and Culture Can Impair Creating Good Product

in Agile/Agile Engineering/Product Management/Project Management by

When we think culture, we often think about nationality and or regional cultures. Culture is often a dinner discussion with my wife and friends, it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s engrained in us.

A few weeks ago, VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note, I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns about Adoption

  • Lack of Upfront Planning – 34%
  • Loss of Management Control – 31%
  • Management Opposition – 27%
  • Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

  • Failure to integrate people – 34%
  • Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

  • Controlled manFear of Losing Control. This is primarily an individual fear; however, it can also be engrained in the organization. I’ve heard, “if I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth, because we generally see everyone’s engagement raise up a notch or two. Thus, resulting in more people being involved in making the decisions at the proper levels — hence scaling the organization.
  • Gate Keeper Culture. Often a subset or product of Fear of Losing Control, this is the manager or director who acts the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder. Or, where in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
  • Measurement of Success is Based upon “On Budget and On Time”. Many organizations, especially IT organizations live in the world where they try only be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what — everyone is happier including the development teams.
  • “What’s My Role” Fear. This is the protectionist behavior where managers and or team members don’t see a fit for themselves or don’t find a fit for themselves as an agile transformation takes place. These team members or managers generally start start creating barriers to deflect blame while at the same time climbing to the roof-tops to shout out about the failures of the team and process. If others are looking at the right thing (e.g. product moving out successfully
  • Victim Mentality. Have you ever heard, “it’s always been that way and it’ll never change”? Well, this is the typical response for the person who either doesn’t want to deal with change — or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people, then I learned quickly — if you don’t ask, you don’t get. And, if it is something that could have really positive results — isn’t it worth the risk?
  • photodune-3820842-young-superhero-sSuper Hero Culture. Now don’t get me wrong, I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to overcommit constantly is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project that our Scrum Master isn’t supposed to know about. Again, hard work is great — but we have to respect the concepts of sustainable pace, transparency, and “The Team”. Remember we regularly deliver value.
  • Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad or no rapport between the teams. Role based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not been visible yet. And Ivory Tower silos are those “I’m a Director” or “I’m the Product Manager” and you just do what I say — this never results in team work, unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits”, then you might have some Ivory Tower silos and possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to here about those that not only impacted your agile implementation, but those that impacted delivery good product.

Getting Blood From a Turnip – Workshop Preview

in Agile/Product Management/Resources by

This is just a quick video that provides some insight into a workshop aimed at helping folks become better facilitators.  Please contact me (matt@agilebacon.com) if you are interested in me presenting this at one of your group meetings.

[inline_media]
[/inline_media]

Product Ownership – A Team Sport?

in Agile/Product Management by

How many of you have heard a Product Owner being described as a single-wring-able-neck, or read that the Product Owner is solely responsible for the “Return On Investment” of a product or project? Are you aware that the Product Owner is responsible to work with stakeholders to define the product or project, and they are also required to be available to the team to answer questions, give feedback, and accept the deliverables produced by the team? If you are doing Scrum, you’ve likely heard all of this.

As defined by ScrumAlliance.org, the role of Product Owner is responsible for the business value of the project. To take this a step further, Roman Pichlar inked a solid blog called Being an Effective Product Owner. In this blog, he better explains the expectations and or responsibilities of an effective Product Owner including close collaboration with team to guide and direct the team, active management of the backlog (ranking, grooming, etc.), proactively manages stakeholders [expectations], has a thorough understanding of customer needs, and has some knowledge as to how good software is developed. These responsibilities closely resemble the four aspects that Robert Galen outlines in his book, Scrum Product Ownership — Balancing Value from the Inside Out. These four aspects include part Product Manager, part Project Manager, part Leader, and part Business Analyst.

As pointed out by many in the Product Management space, the role of Product Owner is fairly broad and, although many folks like Roman and Robert have done a good job helping to better define the Product Owner, the role itself is often viewed as ambiguous. Let’s face it, in order to be a good Product Owner you are asked to know your customer, have an in-depth knowledge of how the product or project should satisfy the needs of the product, you must represent the product to both internal and external stakeholders, price and support the product/project to ensure profitability, define requirements, answer questions to the team, be a part of elaboration and planning discussions, facilitate discussions between customers and developers, work with industry analysts, plan and schedule, define what is the most important thing, … ok this is getting ridiculous. This is a lot to ask of any one person.

In years past, when organizations made the transition to Agile (specifically Scrum), the Product Owner role typically defaulted to the Product Manager or the Director responsible for a specific service area (e.g. Customer Service Director). This often meant that in addition to your current job, we are going to ask you to make yourself more available to the development team that is building your product or project. In some cases, this worked out fine — but in most, you’ll see that either the stakeholders are not happy or the development team is not happy. This is simply because there is not enough time in the day, not to mention the expectations and requirements are so broad.

Today, it is common place to see the Product Manager or Director be paired up with a Product Owner. The Product Owner role is given to a Business Analyst or Project Manager that has strong subject matter expertise. In some cases, you’ll see titles stay the same and in others, team members actually given the title of Product Owner. These two (maybe more) team members pair up to become the Product Ownership Team. The Product Manager works the external stakeholder needs while the tactical Product Owner works the internal stakeholder needs — specifically working closely with the delivery team. Arlen Bankston of Lithespeed talks about the roles of Strategic Product Owner and Tactical Product Owner in this blog.

productownershipteamThe Product Ownership Team approach helps reduce the time burdens and constraints, while still fulfilling the need of having a role focus on business value. The advantages of this approach are:

  • More brainpower up front to help understand customer needs and align to solutions,
  • Time afforded to thoroughly understand the marketplace,
  • Capacity to satisfy the “on-demand” need to work with the team, and
  • The ability to avoid unnecessary waste due to bottlenecks that result from a poorly maintained backlog.

The possible pitfalls to look out for with this approach are:

  • When the tactical Product Owner is not empowered to make decisions — you will likely end up conversations being conducted through heavy documentation and sign-off processes,
  • A proxy-type relationship that can keep the delivery team from making a connection with the end-customer,
  • The lack of clear vision since the tactical Product Owner my be too far down in the weeds and not able to clearly articulate the big picture, and
  • Without the Product Manager (or Strategic Product Owner) interacting frequently with the team members — trust and a positive rapport does not develop between the business and the delivery team. This can lead to poor morale and underperforming teams and products.

What approach does your organization employ? Do you have a single Product Owner? Or, is Product Ownership comprised of a Team? If it is a team, are there multiple players or just two?

Another Video – Steven Johnson’s Where Good Ideas Come From

in Product Management/Resources by

As a quick follow up to the earlier post about Dan Pink’s Drive, I also like the following video put together for Steven Johnson’s book, Where Good Ideas Come From. I haven’t read this book; however, I’ve stumbled upon more than one post online that references the ideas from this book on ideas.

Some folks don’t agree with the concepts presented; however, I find it to be a fascinating take on how ideas formed in the past and how they might be developed in today’s integrated information society. Let me know what you think.

You can pick up the book here:

Come to the Science Fair

in Product Management by

Remember that thing we folks that practice Agile call the Agile Manifesto.  You know the thing that where 17 smart folks got together and came up with a set of four values and twelve principles to help guide and shape the behaviors of those involved in software development.  Everyone might not be able to rattle off the principles, but most of us understand and appreciate the common sense of the four values.  At the core of all the Agile Manifesto values is a well maintained relationship between the delivery team and the customer (or Product Owner).  And this is where challenges have emerged and often things start falling down.  Here’s a common scenario that often plays out:

An organization starts making a shift to use an agile related process, let’s say Scrum.  They train the delivery team and the product owner, then kick it off with a team or two.  Everyone starts to work and they start seeing productivity gains right away.  And the teams are seeing vast improvements in communications and building products that customers like.  The organization then says — let’s have a few more teams start drinking from the Agile fountain.  Things are going well, but what starts happening is that during this scaling process — people start competing for meeting rooms during the sprint planning and review cycles, and the product owner’s time quickly becomes a constraint. Thus, teams start alternating their sprint schedules to deal with the room/resource issue and the product owner spends less time with all teams and seems to only focus on those teams that work on things that are not doing well or they like.

Now you are asking, what’s the problem?  Well, one of the best things that you’ll find when you start working in small incremental delivery cycles is that the teams form a rhythm (or cadence).  This helps for predictability that helps the organization in planning and more importantly, helps the team members in planning their lives.  Most people like repetitiveness and everyone is habitual (or at least most folks involved in software development), so by having multiple teams on different rhythms — organizations lose the natural state of “steadiness” that comes with shared cadence.

The other big problem with the scenario above is that the face time and feedback with the customer (or product owner) is critical to having success with all four of the agile values.  When teams start realizing that time with the product owner is being a challenge, they tend to simply give the product owner a pass on attending any of the iteration planning and or review — and they just ask for his or her time for stories and acceptance criteria.  This means that they lose out on the critical feedback that comes out during the reviews and demos.

Does this sound similar?  If so, here are some ways to help overcome these common time constraints that appear when you start scaling out agile.

  • Introduce a Gap.  If you are using an iterative approach, introduce a gap between your iterations.  The idea is to get everyone on the same iteration schedule and rhythm and by adding the gap, you’ll give time for folks to juggle room schedules and stakeholder time to ensure participation.  During the gap, the team will have time to properly plan the  upcoming iteration, work on a design/research spike, and or work on an item from the team’s technical wish list backlog.  The gap also can afford the team a quick breath and might also be an easy period to squeeze in some personal business time.
  • Go Short.  This may seem to be non-sense; however, if you are using an iterative process then trying working in shorter cycles.  Although it takes some adjustment, shorter cycles reduce the time it takes to iteration plan and review.  The end result is a tighter focus and that focus is generally on what is needed next.  Similarly, move to a lean or continuous flow process (give this a read to learn more).
  • Lunch-and-Collaborate.  Schedule meetings around lunch and, of course, have food.  Lunch is generally less formal and can be perfect for brainstorming, story workshops, demos, and team building.  Although team members some times need a break from work, most team members don’t mind meeting when food is involved 🙂
  • Record Your Demos.  A meeting that you don’t want to miss out on getting feedback is the demo; however, this is a meeting that for some reason the product owner and other key stakeholders will often miss.  This meeting is not only about showing off and having the team get some positive feedback — it is more about just getting feedback.  Try recording the demo.  Make the video less than 10 minutes, don’t worry about it being Oscar quality, just get it done and sent out to all those that can give input.  Solicit feedback within 24-hours of sending out the video, re-enforce the need for the feedback and participation.   In addition to the value of getting feedback from the stakeholders, the recorded demos are great timeline artifacts that can be used for retrospectives.
  • sciencefairConduct a Science Fair.  Often when scaling agile, there will be a product owner that works with multiple teams and making time for reviews and demos for all teams around the same time is near impossible.  So to get around this, conduct a science fair — have teams assemble in a meeting room and demonstrate their latest accomplishments.  This is not only a fair for the product owner, but this is a great time for teams to get together and see what the other teams are up to.  This is an event that the whole organization can be a part of and it is a great way to get an organization excited about capabilities forth coming.

So if your teams have had some challenges with face-time with the customer, difficulty establishing a cadence, or you are just not getting valuable feedback — try one or all of the approaches above.  These approaches can not only improve the collaboration, but they can be fun and challenging which will show up in improved team morale.

Go to Top