8 Domains Executives should Plan and Coordinate

Planning and Coordinating use Agile PPM tools

Executives are responsible for maintaining the structure of the organization and supporting the mechanisms that enable the flow of value across many teams. To that, executives should plan and coordinate across major organizational domains. Though I believe there are eight domains which executives should be planning and coordinating in, I'm not prepared to say Sales & CRM or Marketing Management should be included in an Agile PPM tool (at this time). Beyond that, a single PPM tool should cover the remaining six domains.

Often, the first tools purchased are to help the delivery teams manage their daily work. As the organization evolves or grows, more tools are purchased to cover the gaps left by the team-level tools. The tools then become entrenched. At some point, organizations have a collection of tools they are trying to maintain and they lose sight of the original reasons for purchasing and implementing them.

Organizations then turn to PPM tools. There is a wide variety of motivations for using agile project portfolio management (PPM) tools. One key reason can simply be the desire for their teams to collaboratively plan. Other key reasons include the desire to prioritize and track work on a synchronized cadence, while providing visibility of the portfolio to the executive stakeholders. To meet organizational needs, the number of tools being used to satisfy these desires expand over time.

Before you choose an Agile PPM tool, remember that your company operations should influence how that tool is implemented across your organization, not the other way around.

What types of problems are Agile PPM tools good at solving?

Six Organizational Domains of Planning and Coordinating

Portfolio Management

The art and science of making decisions about investment mix and policy, matching investments to objectives and key results (OKRs), asset allocation for individuals and institutions, and balancing risk against performance. Your Agile PPM tool needs to provide a sufficient level of visibility of the roadmap and investment themes, through the lens of a portfolio team.

Program Management

The process of managing several related projects or products that are part of an investment portfolio. Your Agile PPM tool must provide a sufficient level of visibility of the release backlog and to allow for necessary elaboration for release targeting, all through the lens of a program or capability team.

Capacity Management

Deals with the organizations ability to create or develop new product. Capacity constraints in any process or resource can be a major bottleneck for a company. Your Agile PPM tool should make it easy to know what the organization and teams have historically delivered, in order to understand where the bottlenecks exist, and what to commit to in the future.

Human Capital Management

Related to people resource management. In order to deliver product predictably, it is necessary to have stable teams, providing specific competencies. Your organization needs the right people in place to deliver on commitments in the portfolio. Do you need to hire or replace people? Your Agile PPM tool should help facilitate a conversation around who are the right people, what teams they should be on, and when we need them on a team.

Dependency Management

The ability to either encapsulate or orchestrate around “dependent” organizational, structural, or technical activities. Dependencies tend to be a major productivity killer for organizations. They slow and sometimes stop the ability to deliver value. It is critical that your Agile PPM tool provides indications of dependencies across the organization. Having the first indication of a dependency discovered after a delivery team has already made a commitment against its impacted deliverable is too late.

Budget Management

Refers to a financial plan for a defined period of time. It may also include planned revenues, resource quantities, costs and expenses, assets, liabilities and cash flows. Your Agile PPM tool must provide the necessary information to shift conversations from just scope and schedule to budget.

Summary

Use the above list as a guide to catalog tools your organization is using (or considering) for planning and coordinating. Are there gaps or are there overlaps and duplications? If you have overlaps and duplications, there is an opportunity for you to consolidate some of those tools. Begin consolidating tools, and you may reclaim some budget next year you didn't think you had.

Want to know how you are covering the six or eight domains? Schedule an assessment with me.

Time to Replace Backlog Grooming

The Problem

Over the last few years, I've worked with numerous teams. One thing they all struggle with is backlog grooming.  They all know they need to do it.  Unfortunately, they all seem to struggle with when to do it or who should do it.  The most interesting struggle with backlog grooming happened two years ago.  The "story time" meetings took place at the beginning of a month-long sprint. The manager stated, the work to be completed and delivered during that sprint had to be refined within the same sprint.  This helped explain why the team thought they needed month-long sprints.  When I asked why they would try to refine work the first two weeks of the sprint and then complete that work the second two weeks, you know what their answer was?  "It said to do it like that in the Scrum Guide!" After I clarified their misunderstanding, we established a cadence to continuously mature the backlog.  A rotating selection of people would participate in the scheduled meetings.  We would reserve capacity from each sprint to get that work ready for future sprints.  The team was able to shorten their sprints to 2 weeks.  They more than doubled their delivery rate without increasing defect rates.  With that as an example, over the last few years, I have evolved my practice of backlog grooming.  Let’s look at some key dates in the evolution of backlog grooming.

Evolution of Backlog Grooming

2005: "grooming the product backlog" is mentioned by Mike Cohn on what is now the Scrum Users Yahoo Group;

I always have teams allot some amount of time to “grooming the product backlog” to make sure it’s ready for the next sprint.

2008: A formal description of "backlog grooming" is given by Kane Mar, under the name Story Time, and recommending it as a regular meeting

I call these meetings “Story Time” meetings....Although they are not a formal part of Scrum, I’ve found that Story Time greatly improves project planning and reduces confrontational planning meetings, which are all too common for many teams.  A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work.

2011: The practice of "backlog grooming" is called "backlog refinement" and promoted to an "official" element of Scrum with its inclusion in the Scrum Guide

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

2014: Derek Huether from LeadingAgile evolved the practice of backlog grooming with one of his clients, to allow the practice to work better at scale, calling it a "Progression" workshop.

When operating at scale, my client deals with different problems than a standard Scrum team.  They're dealing with separate lines of business. They're dealing with multiple delivery teams for each line of business, to include external vendors. They're dealing with a portfolio roadmap that has annual plan items and budgets. Our strategy encapsulated the entire product delivery value stream, while ensuring we had enough architectural runway. We progressed work to be consumed by delivery teams, via a series of workshops.

Progression Workshops

Our progression workshops differ slightly from the story time meeting detailed by Kane Mar and the refinement meeting mentioned in the Scrum Guide.  Counter to Story Time, we don't invite the entire team. Instead, we have elevated the workshop to a group some have come to know as a Product Owner (PO) team.  The group of people within the PO team will vary, depending on the line of business.  Yes, there will be a Product Owner (Product Lead) and facilitator, but from there we'll include the development lead, testing lead, and an architect.  We've found two key challenges when operating at scale. First, is there a well defined backlog that is ready enough to be consumed by different delivery teams?  Second, is the work being queued up to the delivery teams free and clear of other teams.  That is, have we decomposed it in such a way that we've minimized dependencies on other teams? Beyond that, in order to achieve some degree of architectural runway, we continually refactor existing platforms. Architectural changes are not only made incrementally but we require an architect to be present at every progression workshop.

Counter to the Scrum Guide, I'm not going to be proscriptive as to how much capacity the PO Teams do/should commit to progression workshops.  The goal is to have enough work ready for delivery teams to consume for a few sprints.

When progressing work, we do expect some artifacts to be generated, to contribute to the teams understanding of what will be developed, tested, and delivered. Below is a partial list of potential artifacts. To be clear, we do not expect all of these to be generated.

Potential Deliverables

• System Context Diagram
• Dependency and Risk Work Items
• System Architecture Guidance Acknowledgement
• Use Case Diagram and document
• Business Process Flow
• Known Business Rules
• High Level Technology Alignment
• Architecture Backlog for Planned Work
• As-Is Data Contracts
• Feature Work Items Assigned to Delivery Team
• Feature Business Value and Acceptance Criteria
• Feature Stack Rank
• Test Strategy

So, that's the high-level view of the Progression Workshop.  Most of the time, a feature will require two or more progression workshops before work is ready to be consumed by a delivery team.  Once features progress to a defined level of shared understanding, the delivery teams assist in the decomposition of features to user stories.  In this way, work is decomposed to the right level of detail for each delivery team.

I'm curious, how have you scaled feature development and backlog grooming in your organizations? What mechanics outside of the standard Scrum process have you found useful to refine work to be completed by delivery teams?  Have you evolved Story Time or backlog refinement?

Image Credit: Pictofigo.com

Top 10 Negative Personas of a Daily Standup Meeting

All Agile teams should be holding a daily standup meeting.  Don't think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead.  During a daily standup meeting, participants sometimes exhibit negative behavior that will detract from the meeting.  As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don't even realize people are doing them. So, I'm giving them some names. Next time you hold a daily standup, see if anyone (including yourself) exhibits any of these 10 behaviors. Rather than using the list as a means to label others, use it to reflect on yourself. How might others be perceiving you? Is the persona you are projecting counter to your goals? 

If you think of some behaviors that should be added to the list, I would love to see them.

Daily Standup Meeting Negative Personas

10. Pat Decker the Obsessive Phone Checker

This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. "Pssst, Bob, check out this Vine video or pic on Instagram". She's not so loud that she's overly disruptive but now Bob missed what someone else said during the standup.

9. Stephen Craig who is Always Too Vague 

This person can get stuck on the same task for days but doesn't want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like "Yesterday I was working on task 123 and today I will be working on it some more". No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.

8. Bobbie Bainer the Team Complainer

When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don't bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.

7. Jess Jewler who loves the Water Cooler

Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead?  Are you going to watch the Ravens play this weekend?  My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it's not about work.

6. Billy Platitude with the Bad Attitude

Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he'll give you what you need... in a few months. You want any changes between now and then? Forget it!  He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical "funny" comments at standup to point out how right he is about how stupid agile is.

5. Will Funky the Non-Committal Junkie

Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I'll get back to you, we'll see, would like to think, soon, almost. You'll also see Will be the last person to comment on something and will usually go with the crowd.

4. Tom Mater the Specialty Updater

Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he'll either tell you to look it up in a tool or he'll be very technical in his response. Half of the team doesn't understand what the hell he's talking about.

3. Drue Gru who thinks he's Better Than You (and the team)

Drue has been around for a long time. He's better than you and he knows it.  If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn't come at all.  He has little to say because you wouldn't understand what he's talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*

2. Pearl Revolver the Problem Solver

Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She's very curious what issues others are having because she's going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.

1. Ian Krumpter the Interrupter

Do you listen or do you wait to talk?  Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you're talking, you're less likely to be listening. He wants to prove just how awesome he is so you'll see him interrupt even if the topic doesn't really apply to him.

Thank you to the other coaches at LeadingAgile for their contribution to this post. The original post was dated March 17 over at the LeadingAgile blog.

Image Credit: Pictofigo

Favorite Project Management Quotes

There isn't a week that goes by that I don't hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you're stuck for a quote or analogy, to help someone understand what you're trying to say, do you ever ask yourself what's that awesome quote that I just heard the other day? Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.

---

• Because the needs of the one... outweigh the needs of the many. - Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
• The more they overthink the plumbing, the easier it is to stop up the drain. - Star Trek III: The Search for Spock, Scotty. I'm admittedly a Star Trek geek.  I've used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
• The thing is, Bob, it's not that I'm lazy, it's that I just don't care. - Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm'kay? Greeeeat.
• Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
• That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
• We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths.- Walt Disney.  I've told my son over and over again to challenge the status quo (I don't call it the status quo because he's seven) and when given the choice, try new things.
• When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
• Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
• Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
• We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff's session at Agile 2012, when I heard him say this.  It really resonated with me.  I don't know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

What is Agile, anyway?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement.

Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client, for LitheSpeed.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to "do" Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I've made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, "That sounds like waterfall!"  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  "Well, it's not Scrum.  If it's not Scrum, it's not Agile".

If it's not Scrum, it's not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel's post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it's going to depend on your touch points.

Go read Joel's post.  I think you'll enjoy it.  When you're done, I'm sure you'll agree that if it's not Scrum, it can still be Agile.

Image Source: Pictofigo (Go get one. They're free)

Simple Cheat Sheet to Sprint Planning Meeting

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

• Assign a relative story point value
• Remove dependencies
• Create testable examples
• Define acceptance criteria
• Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

1. Remind the team of the big picture or goal
2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as appropriate
6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
7. Present proposed product backlog items to consider for the sprint backlog
8. Determine the needs, sign up for work, and estimate the work owned
9. Product Owner answers clarifying questions and elaborates acceptance criteria
10. Confirm any new issues and concerns raised during meeting and record
11. Confirm any assumptions or dependencies discovered during planning and record
12. ScrumMaster calls for a group consensus on the plan
13. Team and Product Owner signal if this is the best plan they can make given what they know right now
14. Get back to work

// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //

Drawings by Pictofigo

Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won't know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none. We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown.  Even some of the unknowns aren't even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.

SWOT Analysis

I'm finding myself working through a strategic planning process. I've known executives who would just use gut instincts when doing their strategic planning.  But when you're dealing with someone else and their money, don't be so gutsy.  Just do a SWOT analysis.  What does SWOT even mean!? During strategic planning, upper level managers, directors, or executives ask a series of questions.  That's known as a SWOT analysis because they're trying to identify a organizations's strengths (S), weaknesses (W), opportunities (O), and threats (T).  Because I think a picture is worth a thousand words, please see the Pictofigo enhance grid below.

SWOT

• What are your major strengths? These are internal. How can you capitalize on them in the future?

• What are your major weaknesses? These are also internal. How can you overcome them?

• What are your major opportunities? These are external to your organization. How can you take full advantage of them?

• What are your major threats? These are also external to your organization. Is there anything you can do about them?