Product Owner

Side Stepping Landmines: Managing Risk With Sprint Futurespectives

| Jeremy Brien

Risks Are Landmines

Risk and project issues are one of the roots of poor project performance. There are three areas that we measure regarding the success or failure of a project; these three areas are what we call in project management, the triple constraint. The triple constraint consists of scope, budget, and time.

The interactions of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction. Was there a decision to increase the scope? You’ll likely need more time and money. Has there been a cut to the project’s budget? There most likely needs to be a cut to the scope. Has the schedule been crashed and we need to get to market in two months instead of the planned six? Better give me more money and be prepared to cut some of that scope down to a “minimal viable product.” I think you get the idea.

The triple constraint consists of scope, budget, and time. The interaction of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction.

This is why scrum is so effective. It allows for business agility via quick decision making from the Product Owner and iterative delivery of working software from the team. Scrum deals with actions effecting the triple constraint rather well. Project issues concerning the budget or schedule can quickly be addressed by everyone and the Product Owner can assess the business impact to make a decision that usually concerns scope.

However, when a team starts off on a new project that has a medium to high amount of risk and uncertainty, I recommend allowing teams the time to mull over possible risks and to perform some pre-planning. Otherwise, the project can blow up in their face or decisions will be made for them by the changed environment. We address this with risk planning — we don’t send our soldiers into a battlefield knowing land mines exist. So how can scrum teams plan for risk?

Risks are landmines. Some we know about. Some we don’t. Creating a plan to navigate and manage the consequences of a triggered mine is the only way to help us navigate a minefield responsibly.

Conduct A Futurespective

Thinking ahead and talking can help, but writing down potential risks and plans to address them is even better. This is the point of the “Futurespective;” To conduct risk planning at the start of a project or product enhancement and to give the team some time to do some planning before stepping on a potential minefield. It’s an activity outside of the typical scrum events and because of that, it should not be done before each iteration. Instead, it should be done provided select circumstances:

  • Just before beginning a new effort (i.e. Sprint Zero);
  • Just before a critical milestone (i.e. a new feature release to Production);
  • A significant change to a project constraint is anticipated (i.e. change to schedule, scope, budget, or quality). 

Just Before A New Effort – The Sprint Zero As A Futurespective

The Sprint Zero is an activity I’ve seen successful teams use when they conclude one effort and move to another. There is no such thing as multi-tasking and that is why we should frown upon teams who work on multiple projects at once. What they’re really doing is engaging in “task-switching” or inefficient “serial-tasking.” Instead, we encourage the team to wrap up a product feature and release it to production for general use before moving onto another product.

The Sprint Zero is the time between efforts that allows teams to assess what the new project or product enhancement is. If they’re cracking open the code for an existing product to add a new feature set, they should be allowed up to two weeks depending on the complexity of the code. For older, more monolithic applications, carrying large amounts of technical debt, I’d recommend no time-box on this activity. Let the team take their time getting familiar with the product, the code, and documentation (if it exists or is up to date). If there is no documentation, stress the importance to managers that they should not be rushed into starting the project until they are ready. Let the team decide when they’re ready to begin and use common sense.

If the team is about to spin up a new project and create a new product from the ground up, there should already be a product backlog and roadmap ready for them to review. The Sprint Zero is a great opportunity for the team to familiarize themselves with the backlog, Product Owner, Subject Matter Experts (SMEs), and stakeholders of the new product. The team should be conducting working sessions to create better acceptance criteria for user stories, sketching wireframes, and getting a better understanding of what they are going to build. Encourage them to seek continual feedback on their wireframes and designs. Make it an iterative activity. Teams may also take some time to engage in training if they will be developing in a newer development framework. Again, exercise common sense and decide on a reasonable time-box before kicking off the project.

Just Before A Critical Milestone – Release Planning As A Futurespective

Usually a sprint or two before releasing a larger feature, the team should have a handle on the stability of their product. Testers have been giving Developers feedback on the quality of their code via Integration & Performance Testing and of course, Bugs. The Product Owner is busy preparing, coordinating, or wrapping up User Acceptance Testing (UAT).  The Scrum Master is busy assisting everyone with Impediments and UAT. It can be chaotic or running smoothly… sometimes too smoothly…but, maybe I’m just naturally pessimistic?

I find this is a great opportunity to use the time normally allocated for a Retrospective as a way to plan for risk and get everyone together for the release plan. Of course, the need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment, however, I recognize that it can take a while to get to this point.

The need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment.

There are multiple ways to conduct a Futurespective and each one could use their own article. However, it’s a good idea to invite the Product Owner and SMEs to this event. To be concise, I’ll give you the meat and potatoes of what makes a good Futurespective.

  1. Identification of plausible risks regarding the release
  2. Statement of assumptions about the release
  3. Statement of the issues currently occurring (problems & challenges the team is experiencing).
  4. Identification of dependencies effecting the release (technical or cross-team dependencies the team or organization has). 
  5. Written mitigation plans that is developed by the team and Product Owner.
  6. Assignments/Owners for each plan (“if risk 2 is realized, who is the person responsible for leading the plan?”). 

A Significant Change To A Project Constraint

When a business priority changes and the project’s budget, schedule, or scope, is effected, the Product Owner may decide to stop the iteration and cancel the sprint. The Product Owner should call the team together and appraise them of the situation and call on the team for advice. Ultimately, the Product Owner will likely make some tough decision about cuts to the product scope. The Product Owner should use her Subject Matter Experts, stakeholders, and Delivery Team to make the most informed decision possible. It’s a great opportunity for everyone to brainstorm with the Product Owner about the best way to continue moving forward and exercise business agility.

Prioritizing the Product Backlog and refining user stories that were in the “freezer” takes a lot of effort and planning. Schedule as many backlog grooming sessions as needed and run a Futurespective before proceeding.

Thanks for taking the time to read and I hope you found it useful. I’d love to hear your thoughts on risk management or any experience you’ve had with Futurespectives. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

Related Posts

The Scrum Product Owner Chooses Business Value

The Product Owner Steers The Ship

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, And Jaded Sage

Talking About Communication: A Fun Game For Your Next PMO Meeting

| Jeremy Brien

Telestrations – A Game For Communication

Today I was cleaning out my school bag and came across some old index cards that I had used in my Advanced Project Management class. We used it during our lecture on communication management and the instructor had us play a quick game of Telestrations

Why It’s Important

One of the greatest threats to the success of any project is the failure to communicate. Our goal, as Project Managers and Product Owners is to ensure the timely and appropriate generation, collection, dissemination, and disposition of information. Communication is the oil that keeps a project running smoothly. 

This game is easy, fun, and provides some laughs. Additionally, it’s a great opportunity for everyone in the Project Management Office to be reminded of the basic principles of communication. I can’t tell you how many times I’ve sat in a PMO meeting and was either bored to death by power point (death by power point… ugh…) or the group wasted an hour and a half reviewing project status reports (couldn’t I have just sent an email?!?… double ugh…).

The game I describe below takes about 2 minutes of set-up and about 5-10 minutes to execute depending on how many participants are involved. It’s a great ice-breaker and will keep everyone focused if you’re one of those evil managers with a habit of scheduling the PMO meeting after lunch.

Supplies – What You’ll Need

  1. Pink (or any color) note cards x4
  2. White note cards x16
  3. Sharpies x4
  4. Stop watch x1
  5. 1 person to facilitate and keep time
  6. 4 or more people to participate

Setup

Write 4 different project management topics on your pink notecard (in the examples below, my team used: integration, program management, execution, and procurement)

Place 4 of the blank note cards (or more if there are more than 4 people in a group) under a pink card with the project management term written on it.

Write the following instructions on a whiteboard for everyone to read:

  1. Please get into a group of 4 people.
  2. Each person will be given a group of note cards (keep them together at all times).
  3. The 1st note card will have a Project Management term on it (Do not share this word with anyone in your group until we are done with the game).
  4. Every 1 minute, we will rotate through the note cards as follows (The facilitator will keep time and ensure the note cards pass to each person):
    1. First Person, read the term on the pink card, then place that card behind the stack of cards and draw the term on the first blank note card. Pass all of your note cards to the next person with your drawing on top.
    2. Second Person, Based on the drawing the first person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on the top.
    3. Third Person, Read the term the second person wrote and place it behind the stack of cards. Draw the term the second person wrote on a blank note card. Pass all of your note cards to the next person with your drawing on top.
    4. Fourth Person, Based off of the drawing the third person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on top.
    5. Assuming a group of 4, the first person should have the original project management term they started with — the pink card they first read to start the game. Starting with the pink card, each person read the original term and share the pictures and terms in the order they were drawn. 
    6. Facilitator should allow each person to describe their pictures and encourage a few minutes of conversation.
  5. Final Note: Drawings can not have any written words or prompts on them. Pictures only!

Below is an example of the final results our group had:

Topic: Integration

As you can see, the first three people were able to communicate “integration” pretty well. The fourth person wrote “tools & techniques.” When we discussed this as a group, the pot in the third picture reminded the fourth person of tools and cooking techniques used in the kitchen.

Topic: Execution

This one was pretty funny. I started off this iteration and chose to draw a stick figure getting decapitated at a guillotine. I felt this was a an obvious example of “execution.” Unfortunately, the second person didn’t pick up on this and guessed “penalty.” Naturally, the third person figured this was a “penalty” and related that to budget and drew a picture that led the fourth person to assume “over budget.” We were way off the mark with this and shared some laughs.

Topic: Procurement

On my opinion, this was the hardest topic. During our discussion, the first person stated they had a tough time trying to draw a picture for “procurement” in 1 minute or less (heck yes! I still don’t know what I could draw). The closest thing they could draw looked like communication management and that was what we all guessed at. Again, we weren’t even close!

Topic: Program Management

I think the first person did a great job with their picture. A program is a group of similar projects or activities. The use of a the box plot diagram was straight out of the PMBOK. Unfortunately, as we discovered, the artist chose to use 5 circles to represent the projects inside of the program. The second person focused on this fact and guess “the 5 phases of a project.” The third picture, which is mine, has a stick figure using a phaser on a column of 5 (pretty creative if you ask me). The final person guessed “5 knowledge areas.” I guess my picture wasn’t as good as I thought it was.

Take Aways – Common Mistakes With Communication

There’s plenty of material about the basic communication model. I’ll try not to rehash something we all know, so I’ve just highlighted a few of the key takeaways from our lecture and subsequent discussions.

Confirm communication is actually received and understood.

Research says that in a face-to-face interaction:

  1. 58% of communication is through body language
  2. 35% of communication is through how the words are said
  3. 7% of communication is through the content or words that are spoken
  • Pay attention to more than just the actual words someone is saying.
  • A person’s tone of voice and body language say a lot about how they really feel.
  • Ask people what information they need and when.
  • Plan communications to all stakeholders and project team members and a way that fits their needs.
  • Customize communication standards within your organization to the needs of the project. Don’t stick with a template if it’s not effective!
  • Use multiple methods of communication.
  • Realize that communication is two-sided, to and from a stakeholder or project team member.

Share your thoughts on communication or using the Telestrations game in your next meeting in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The Quick And Dirty On Stakeholders

Scrum Product Owners Part 2

Scrum Product Owners Part 1

The Quick And Dirty On Stakeholders

| Jeremy Brien

A Scrum Product Owner’s Quick And Dirty Guide To Stakeholder Management

Identify Stakeholders

One of the core responsibilities of a Product Owner is managing stakeholders. Successfully managing Stakeholder expectations, decisions, and time are all signs of effective stakeholder management. There are many tools and techniques to help you identify your stakeholders, however, below is a list of ideas to help you wrangle in those stakeholders and identify who they are:

  1. Follow the money – find out who’s got some skin in the game
  2. Resources – find out who’s giving your their people to assist with development
  3. Deliverables – find out who you are delivering the product to
  4. Decision-Makers – find out who will make decisions before you can deliver the goods
  5. Related Programs/Products/Projects – find out who acts as a supporting function to your product
  6. Organizational Charts – find the organizational chart and make sure it is up to date
  7. Team members – if you’re new, ask your team members
  8. Find Influencers – Unofficial People of Influence who yield power through influence and not their position

Know What Motivates Your Stakeholders

Understanding what motivates the stakeholders is just as important as knowing the organizational goals. Of course, we like to think that everyone thinks, “yes! go team and go us! let’s move towards our goal.” Unfortunately, politics also play a part in the Product Development game. Some stakeholders have their own interests in mind or put their own department needs first. They lose focus on the over-arching strategy of the organization. Effective Product Owners need to be aware of:

  1. The Organizational Strategy
  2. Budget Positioning
  3. Personal Agendas
  4. Stakeholder “Pet Peeves,” “Pet Projects,” and their “Pet People.”

Problem Children

Some stakeholders bring their “baggage with them.” Sometimes they lose trust in a Project Manager, Scrum Master, organizational leadership, the delivery team, or have no faith in the product itself. Some stakeholders might have been recently burned by a project. They can have some sort of “baggage” they carry with them. No one is perfect, and sometimes, as a Product Owner, you just have to own those past issues to keep development moving forward. Saying, “I’m sorry” is free and owning those issues and sharing how you intend to do it better (sharing the lesson’s learned with the stakeholder) is the first step in gaining the confidence of any “problem children.” Below is a list of reasons why your stakeholders may be “acting out.”

Lack of trust in

  1. Project Manager/Product Owner/Scrum Master
  2. The Project/The Product/Product Delivery Team
  3. Product/Project/Program goals not articulated or defined in accordance with the organizational strategy
  4. “Bad Project Experiences”
  5. Your Own Past Mistakes

Problem Children exhibit the following behaviors:

  1. Meddlers: Always inserting themselves into decisions, processes, or meetings where they are not required
  2. The Forever SME (Subject Matter Experts): Usually a high performer who was promoted but hasn’t let go of the responsibilities of their old position
  3. Indecisiveness: Can never make decisions in a timely manner
  4. Lack of Budget: They ask for everything but don’t want to help pay for it

Golden Unicorns

The ideal stakeholder exhibits the below traits. Our “golden unicorns.” As a Product Owner, we want to make sure we keep the trust of our golden unicorns all the way to the finish line.

  1. Belief in the Product/Program/Project
  2. Don’t revel in the past — even if they had a bad project experience
  3. Communicate their needs well
  4. Availability
  5. Team Player
  6. Excellent Manager and Employee
  7. Positive self-esteem
  8. Helps motivate team members and other stakeholders
  9. Accountable & Responsible
  10. Can make timely decisions

Share your thoughts on stakeholder management in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Scrum Product Owners Part 1

Scrum Product Owners Part 2

Urban Legends In Our Organizations. Listening To Our Naysayers, Seers, And Jaded Sage

Scrum Product Owners Part 2

| Jeremy Brien

The Product Owner Chooses Business Value

As the “single wring-able neck,” the Product Owner is tasked with maximizing business value and setting the direction for a new or existing product. She shares the guiding view into the future and collaborates with customers, stakeholders, technical teams, and supporting roles to steer the product to the desired end-state. In this article, I would like to share my favorite two value areas that effective Product Owners understand.

  1. Customer Service
  2. Operational Efficiency

1. Customer Service

An organization is nothing without it’s customers — they are either external or internal customers. Customers are the people who use the product to fulfill a specific need. A product that is easy to use and accurately fulfills a customer’s needs is valuable to the organization. Design considerations like User Interface and User Experience need to be considered when crafting user stories, however, the main consideration is, “how are we best serving our customer with this feature?” 

External Customers look to “exploit artefacts[sic] produced by the organization with specific requirements and specifications” (Hobbs, 2016). External customers are essential to the success of the organization as it operates to produce the artifacts specified by external customers.

Internal customers are all members of the organization who rely on assistance from each other to fulfill their duties in the production of artifacts specified by the external customers.

“If you build a great experience customers tell each other about that. Word of mouth is very powerful.”

— Jeff Bezos, Amazon

2. Operational Efficiency

An organization is unable to best serve it’s customers if it’s inefficient. While running the air conditioning in the middle of winter is wasteful, Product Owners go beyond the obvious to make operations more efficient. Below is a list of operational efficiencies in a ‘lean’ context that Product Owners should consider in their user stories. Product Owners should start with, “how does this feature improve our operations or reduce waste?”

  1. Reducing defects – features aimed at reducing defects strive to reduce errors, mistakes, rework, and preserve data integrity of internal and external customers.
  2. Reducing motion – features directed at reducing motion strive to automate a formerly paper-driven process. This helps improve efficiency and standardizes the quality of those processes. Additionally, frees up resource capacity so internal customers can engage in more technical work.
  3. Creating a common language – features sighted on centralizing information in a common place creates a lexicon synonymous with the organization. It simplifies the way information is shared and understood throughout the organization. Internal customers are all speaking and sharing the same meanings and when extended to client-facing applications, external customers speak the language too.
  4. Improving decision making – features trained on increasing transparency allow internal customer to make decisions quickly — ultimately helping organizations exercise business agility and ‘pivot’ when the internal or external environment prompts for it. 

Leave your thoughts on Product Ownership or Business Value in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Sources

Hobbs, B. &. (2016). Projects with internal vs. external customers: An empirical investigation of variation in practice. International Journal of Project Management Volume 34, Issue 4, 675 – 687.

Related Posts

Scrum Product Owners Part 1: The Product Owner Steers The Ship

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Six Elements Of An Effective Strategy

Agile Leaders Understand Customer Service and Culture 

 

 

 

Scrum Product Owners Part 1

| Jeremy Brien

The Product Owner Steers The Ship

The Product Owner can be described as the “single wring-able neck” in Scrum. They are responsible for maximizing value and setting the direction for a new or existing product. They work with development teams, stakeholders, groom & prioritize their backlog, and share a guiding view into the future. The Product Owner is the most important role in the organization and only a special kind of person volunteers for it. The rest are usually ‘volun-told.’

Intention and style shape the effectiveness of a Product Owner. Like all of us, Product Owners come from different backgrounds or roles. Angela Druckman, of the Druckman Company has a wonderful series on Product Ownership and I have personally worked with her and attended her Certified Scrum Master and Certified Scrum Product Owner courses during our Agile Transformation at the Nevada Department of Transportation.

As a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles.

“An anti-pattern is something that looks like a good idea, but which backfires badly when applied.”

-Jim Coplien

Never assume that an ex-project manager uses “command and control” with their teams or that ex-business analyst will struggle with emotional intelligence. Leave all judgement to Judge Judy. Your job as a coach isn’t to fix anti-patterns. It’s to tap into people’s potential. Anti-patterns will extinguish as each person’s potential is unlocked and the agile mindset becomes a part of who they are. 

Captain & First Mate: Product Owner & Scrum Master

The first thing I want to stress is the relationship between a Product Owner and Scrum Master. These two roles, when combined with the Delivery Team, are a lot like a Project Manager and Delivery Team. Let’s take a 30,000ft view of the 10 Knowledge Areas of Project Management and see where the Product Owner and Scrum Master have responsibility in regards to traditional project management and its’ relation to iterative product development.

  • Integration Management
    • Traditional: This responsibility falls onto the Project Manager via a Work Breakdown Structure (WBS) and Gantt Charts.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master via collaboration and iterative development.
  • Scope Management 
    • Traditional: This responsibility falls onto the Project Manager and Change Control Board via the Scope Baseline and Change Management Process.
    • Scrum: This responsibility is the Product Owner’s via collaboration with stakeholders, prioritizing business objectives, and the product backlog.
  • Cost Management
    • Traditional: This responsibility falls onto the Project Manager via the Cost Baseline, budget, and Change Management Process
    • Scrum: This responsibility is the Product Owner’s via iterative delivery, business objectives, and budget.
  • Time Management (formerly Schedule Management)
    • Traditional: This responsibility fall onto the Project Manager via the Schedule Baseline, critical path, and Gantt Chart.
    • Scrum: This responsibility is shared among the Delivery Team and Product Owner via iterative releases.
  • Quality Management
    • Traditional: This responsibility falls onto the Project Manager and delivery team via Quality Assurance (QA), Quality Control (QC), and User Acceptance Testing (UAT).
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner via Quality Assurance (QA), Quality Control (QC), Sprint Reviews with stakeholders & Product Owner, Scrum Master resolving impediments during the daily stand-up, and Agile Retrospectives.
  • Procurement Management
    • Traditional: This responsibility falls onto the Project Manager and stakeholders via the organization’s Project Management Office procurement Policies, Processes, and Procedures
    • Scrum: This responsibility is not defined in Scrum, however, the organization’s Policies, Processes, and Procedures should be followed. A Scrum Master or  Product Owner should work closely with the Project Management Office.
  • Stakeholder Management
    • Traditional: This responsibility falls onto the Project Manager via the stakeholder management plan.
    • Scrum: This responsibility is shared among by the Product Owner and Scrum Master. The Product Owner elicits requirements from stakeholders and the Scrum Master insulates the Delivery Team so they can focus on the product.
  • Communication Management
    • Traditional: This responsibility falls onto the Project Manager via the communication plan.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master. The Delivery Team meets daily and communicates progress and impediments. The Product Owner manages stakeholder expectations. The Scrum Master can assist with managing stakeholder expectations, facilitates the Daily Stand-up, Sprint Planning, The Sprint Review, The Sprint Retrospective, and coaches the principles of Agile to everyone in the organization.
  • Resource Management (formerly Human Resource Management)
    • Traditional: This responsibility falls onto the Project Manager via the Resource Management Plan.
    • Scrum: This responsibility falls onto the Delivery Team and Scrum Master via iterative planning sessions, capacity planning for each iteration, and relative estimation and using past performance to forecast velocity.
  • Risk Management
    • Traditional: This responsibility falls onto the Project Manager via the Risk Register, Risk Management Plan, and Contingency Reserves.
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner. The Delivery Team and Scrum Master use retrospectives to address risk and improve how they work. The Product Owner sets the guiding view into the future, sets the priorities for each iteration via the backlog, and makes informed decisions based on the technical expertise of the team and the strategy of the organization.

While the above is a high-level, “vanilla,” list of the shared responsibilities and activities, it illustrates my point. The Product Owner and Scrum Master are a lot like a Project Manager split into two roles. This allows them to share responsibilities and specialize in select areas — making them more effective and increasing the chances of success. As a coach, we need to make sure these two stand as a united front. The Product Owner steers the ship and the Scrum Master is the first-mate.

Leave your thoughts on Product Ownership, Scrum, or Project Management in a comment below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Improving Agile Retrospectives with SMART Goals