The Role of a Product Owner (Part 4): Pragmatic Considerations

In this series of posts, I have covered responsibilities, characteristics, daily activities and anti-patterns of product owners. In this final post, I wish to summarise a few pragmatic considerations of the role.

The product owner is the single neck on the block, and is responsible for setting the direction for development as well as making hard decisions in the interest of driving value creation. They work in close collaboration with stakeholders, customers, the Scrum Master and the development team daily.

Filling the Product Owner Role

Unfortunately, experienced product owners are hard to come by in many organizations. For this reason, existing employees will typically be expected to fill the role. The two employees who are most likely to make that transition are:

Project managers: PMs can serve as effective product owners by using their financial, people, planning and organisational skills to oversee domain knowledge and product backlog management. The ability to shed any command and control tendencies in exchange for a “one-team, one-dream” mentality will also help to smooth the transition. They will usually require assistance from a business analyst to manage the product backlog.

Business analysts: With their strong product knowledge and solid customer relationship skills, BAs also tend to transition well into a product owner role. They will often require a project manager’s support, particularly when it comes to stakeholder management and financial modelling.

Developing as a product owner takes time, so a “product owner team” comprised of both a project manager and a business analyst is often employed to provide the project with a secure foundation. This allows both the PM and BA to learn from each other for the duration of a project (or product development life cycle), and thus develop more rounded skills than they would have otherwise.

A Careful Balance

A product owner must carefully balance customer outcomes against business value while simultaneously considering both technical debt and team morale. This requires deliberate coordination between many elements within the project, including other teams, suppliers, business departments, customers and users.

Another necessary consideration is the widespread organisational change required to support agile development. Although this change begins with small Scrum teams, it quickly expands to encompass the entire concept-to-cash life cycle of a product. Of course, changing the finance, legal, HR and PMO departments of an organization can be a lengthy process, but agile requires--or perhaps causes--rapid cultural transformation.


Thank you for reading this series of posts. It has been an interesting exercise to open my thoughts on Scrum roles to challenge and discussion, and I hope they have proven useful to you in some small way. If you have any opinions or observations on this series, please feel free to share them in the comments section below.

If you’re interested in learning more about product ownership, I recommend the following five books:

“Succeeding with Agile” by Mike Cohn  “Strategize” by Roman Pichler  “Agile Product Management with Scrum” by Roman Pichler  “Essential Scrum” by Ken Rubin  “Product Mastery" by Geoff Watts 

Is Kanban Always a “Pull” System?

The pushmi-pullyu (pronounced “push me-pull you”) is a fictional creature in “The Story of Doctor Dolittle,” which is described as a cross between a gazelle and a unicorn.

Recently, I was talking with a fellow software professional about some issues he was having implementing Kanban, and the pushmi-pullyu came to mind. Allow me to explain why.

Kanban’s Popularity

Kanban is the most popular agile approach after Scrum, according to the most recently published State of Agile Survey. Scrum is, of course, massively dominant.

Only 5 percent of respondents described their teams as Kanban teams, while three-quarters used either Scrum, a Scrum hybrid or Scrumban. However, when asked what techniques they used, nearly four in every 10 teams said that they use Kanban boards.

This is might be an exaggerated figure since, in my experience, many people confuse Kanban boards with Scrum boards. They look similar, but have very different purposes.

While a Kanban board maps a value stream for the lifetime of the product, a Scrum board is a visualization of a sprint backlog, and is reset at the beginning of every new sprint.

Additionally, the Scrum board is owned by a single Scrum development team, while Kanban is agnostic about who owns the board. These differences turned out to be at the heart of the issue that my colleague raised with me.


Kanban means “signal card” in Japanese, but it was by observing the processes at work in U.S. supermarkets in the 1940s that Taiichi Ohno was inspired to include the technique in what later became the Toyota production system.

From there, the Toyota production system gave birth to lean manufacturing, which spawned lean software development.  Kanban in software emerged from this bloodline.

The core idea of Kanban is that no downstream process is sent additional work from upstream unless it has displayed a visual signal that it has the capacity to handle that work. 

Kanban signals are weapons used to eliminate the waste of inventory, such as work items that are queued or waiting to be processed.


Kanban (in software) implements this approach through the use of explicit work in progress (WIP) limits for each value-added stage in the workflow. These WIP limits are shown on Kanban boards, and are their most recognizable characteristic.

If, for example, there is a WIP limit in testing of five tickets, then whoever is responsible for testing should not accept a sixth ticket unless and until the number they are currently working on drops below five.

As a result, anything that is blocked tends to clog the entire pipeline. If enough tickets get blocked, then the entire value stream will grind to a halt. Then, everyone in the process gets involved in unblocking the pipeline and restoring flow. At least, that’s the idea.

Used properly, a Kanban system is a “pull” system where demand and capacity are balanced using explicit WIP limits. Scrum is also a “pull” system, in which a development team pulls a small batch of work into the sprint based on its estimate of how much work it can complete in the given timebox.

Scrum works because the team is self-organising. No one can tell the team how to do its work, or dictate how much work will be completed in a sprint.

Push vs. Pull

However, Kanban does not demand that a team be self-organising, and each value-adding stage (each column on the Kanban board) might reflect the work of a different team. So, the question is: Who sets the WIP limits? Again, Kanban leaves that open to interpretation.

In my colleague’s case, management set the WIP limits on the board. When the workflow got blocked in one particular area, managers came up with the “solution” of raising its WIP limit.

Of course, this solved nothing. In effect, management just told the team concerned to work harder. Thus, what was intended to be a “pull” system instantly transformed into a “push” system.

Now, this isn’t to say that I’m knocking Kanban. I’ve worked with a number of Scrum teams that use Kanban boards to good effect. But, in every case, it was the teams that set the WIP limits, which removed the temptation of managers to bully the team into doing an inordinate amount of work.

There’s no magic involved in Kanban boards, or in Scrum boards for that matter. Both tools simply serve as a visualisation of the work in progress. It is what you do as a result of what you see on the board that matters.

To me, the idea that you can achieve genuine agility without self-organising teams is just as fictional as Dr. Dolittle’s pushmi-pullyu.






Agile Transition Strategy

In May 2015, I attended Jeff Sutherland’s “Getting to Done” presentation at the DC Scrum Users Group meetup. During his presentation, two things really grabbed my attention.

The first was the Standish Group’s 2011 CHAOS Report, which revealed the percentage of successful, challenged and failed projects using either waterfall or agile methodologies. The second was Sutherland’s statement that “as larger companies adopt Scrum, the percentage of successful agile projects will drop.”  

For the purposes of their report, the Standish Group defined project success as being delivered on time, staying on budget, and reaching completion with all planned features intact. In their 2015 CHAOS Report, they published their findings on the state of waterfall and agile projects that were conducted from FY2011 through FY2015. The results of that report are shown in the table below.

Overall, successful agile projects only dropped by 3 percent, while challenged projects increased by a corresponding 3 percent. However, the more startling statistics begin to become apparent when looking at the success and failure rates of small projects versus those of large projects. 

Small agile projects were approximately three times as successful as large projects, while the failure rate of large agile projects was almost six times greater than that of small agile projects.

In light of this data, the question remains -- why is this happening?

My thoughts are (1) large organizations are feeling the pressure to adopt agile methodologies and do it quickly for fear of being left behind by their competition, (2) large organizations tend to underestimate the level of commitment and effort it takes to successfully transition to an agile environment and (3) they fail to realize that a successful transition is not going to happen overnight.

So, if small agile projects are three times more successful than large agile projects, why not incorporate the advantages of small projects into your organization’s agile transition strategy? Why not transition to an agile environment using a series of small transitions and rolling wave planning?

The advantages of doing so include not taking on the entire organization all at once, spreading out the cost over a longer period and having the freedom to make initial mistakes on a smaller scale with little to no large-scale repercussions. And, as you learn more, each subsequent transition will naturally progress more smoothly than the one before it.

When planning the transition series, consider the composition of your organization’s population. Every organization has three major profile types within its population. 

Those three types are:

Early adopters: These are the kindred spirits who are most receptive to moving forward with new and innovative methods. The silent majority: The mainstream folks who need to see solid evidence of success before embracing a new way of working. The Resistance: Those who are decidedly in favor of the status quo and are neither interested in nor comfortable with change. Their favorite quote is likely to be, “But we’ve always done it this way!”

Execute your strategy in the same order, starting with the early adopters. As you execute your transition, make sure to capture pre- and post-transition metrics as well as the user experience for each project. Then, make sure each project success is widely publicized and that the people who worked on those projects are recognized. 

Repeat this process for each profile type. This will give you the opportunity to build your case for transitioning to an agile environment while simultaneously fostering ground swell.

Using a transition strategy that incorporates this approach lets the organization publicize the fact that they are successfully transitioning to an agile environment, while doing so in a manner that will allow both the organization and its people to truly reap the benefits of a real agile environment rather than an environment that is “agile in name only.”

Mixing Roles in a Scrum Team

One of the powerful advantages of Scrum is having two different types of responsibilities: the shared responsibility for the final product, and the individual responsibility based on each team member’s role.

Responsibility for the product is shared by the whole team: the product owner, scrum master and development team are all collectively responsible for the development and delivery of a working product at the end of each sprint. On the other hand, each one of those team members is also individually responsible for a specific part of the product.

While the product owner is responsible for gathering requirements, shaping the product vision and prioritizing the “What, Why and When,” the development team is responsible for devising ways to  provide the needed features, as well as determining how much time and effort is needed to fulfill the requirements of each user story.

The Scrum Master, by supporting the team and driving them to achieve better results, acts as the catalyst of the sprint.

Despite this separation of roles in a Scrum team, sometimes management thinks that it makes sense for a single team member to take on multiple roles.

I’ve heard about teams where a developer acts as Scrum Master, as well as teams where the Scrum Master role is rotated among the development team members. My view on this approach is that it creates an unhealthy structure due to the conflicts of interests present within each role.

I would find it strange for a developer who is supposed to work on user stories provided by the product owner to simultaneously coach the product owner on how to write and prioritize user stories.

This type of team structure also fails to deepen the development team’s confidence or trust in the product owner to decide what features are needed or make proper decisions.

One other unhealthy situation occurs when the line manager of the team was also a developer who was actively participating in the development. The lack of a boundary between these roles can cause various different problems.

The development team wouldn’t be eager to challenge their “colleague’s” technical proposals, since he or she  is a member of the same team. Sometimes the developer-manager would overrule the product owner, since he or she was the product owner’s manager as well. 

In some situations, user stories might get injected as a result of urgent requirements from management. For example, a user story to show a report needed by the management might get injected in a sprint hindering the delivery of another user story needed by the customers.

A different type of structure, which can be frequently found in startups, involves a developer who is also the product owner. This structure would succeed only if the developer managed to overrule their inner geek in favor of the business needs of the product.

When the founder is not able to differentiate between his or her role as a developer and his or her role as a product owner, the success of the startup can be jeopardized. The few startups that do succeed are able to do so because of this key factor.

In normal cases, I would prefer that the roles in a Scrum team remain separated, as they should be, in order to enable each team member to achieve what is expected from his or her particular role.

Effectively creating a healthy environment in which a team can work properly is critical to the team’s success, and thus should be a top priority for management.

Have you ever worked in a team with mixed roles? I would like to hear about your experiences and thoughts in the comments section below.

3 Reasons You Need to Seek Feedback in Your Agile Process


When it comes to agile teams, far too many of us get trapped in the habit of working independently without a high level of external interaction ‒ this is especially true for teams working on software or web development projects.

While it’s understandable that working with others outside of your immediate sphere can initially seem stressful and overwhelming, investing a little time in clarifying details can go a long way towards cutting the number of iterations in your feature development cycle.

After all, the Manifesto for Agile Software Development teaches us that individuals and interactions, as well as customer collaboration, are core values, which should typically be prioritized over processes, tools and contract negotiations.

Additionally, agile methodologies like Extreme Programming make it a point to collect feedback from the customer on a frequent, ongoing basis ‒ but how many teams actually take that feedback to heart?

I’ve seen too many teams erroneously believe that a two-week sprint means blocking out all feedback from the customer, which can prove to be a mistake in the long-run. If you'd like to help your team move faster and collect as much information from the customer as possible, take a look at these three important reasons why your team needs to seek out feedback during your agile process.

1. You Need to Understand How the Customer Interacts with the Features You’re Building

Many agile teams understand that it’s important to collect customer feedback after an iteration is complete, but it can also be useful to collect feedback while you're in the process of building your shippable iteration.

Giving the customer a preview mode or prototype to interact with can teach you a lot about how they plan to use the features you’re building. Sometimes the way the customer interacts with the features you build is markedly different from the way in which they were expected to.

Using an abstract hypothetical, a car customer could ask an agile team to build an ejection seat to prevent death during a car crash, but their core need is more likely to be an airbag. Why? Because an airbag can better address their core requirement ‒ reducing death and injury with an efficient, cost-effective product that can get to market quickly.

While many agile teams understand the importance of collecting true customer requirements based on true user needs, why not do this on a much smaller scale as well? Your customer won’t wait for your two-week sprint to conclude before changing their mind or providing clearer requirements, so why not collect their feedback on a day-to-day basis?

Some folks may argue that all requirements should be collected perfectly up front, but making this assumption would be failing to prepare for the cases where requirements change or become clearer over time ‒ something that happens far more often than many of us want to admit. After all, responding to change is what agile teams are all about, so why block out input instead of seeking it as quickly and regularly as possible?

Sure, we can organize tasks and goals into short-term sprints without adding additional tasks or requirements, but if your requirements aren’t correctly and clearly defined at the outset of your two weeks, you’ll find that not communicating with the stakeholder during the sprint will surely result in an increment that could have better met customer needs.

2. You Need to Understand the Context of the Features You’re Building and the Work You’re Doing

The features you ship don’t exist in a vacuum ‒ real customers are interacting with these features and the results they produce. It’s important to understand how the customer interacts with the features you build on as frequent a basis as possible.

Talk to customers, and talk to them often. Don’t talk to customers solely on an individual level, but collect data on an aggregate level as well. Think about the industry or market you’re serving and its particular requirements.

In some cases, your customers may not even understand their own requirements as clearly as you can. For example, high school students might be the target market for a website or application designed to help them get into better universities, but these customers ‒ high school students ‒ may not even clearly understand the best methods to get into the best universities in the first place.

In other words, you may need to conduct research beyond customer feedback and in turn educate your customers about what they need.

There’s so much context that can help you understand the customer, which goes beyond their feedback ‒ terminology, regulations and laws, best practices and much more. Don’t assume your customers will simply tell you everything you need to know up front ‒ the features you’re working on may need to guide them or provide solutions that they themselves have not yet conceived of. 

3. You Need to Uncover True Requirements Much More Quickly

As I've already alluded to, it’s crucial to reduce the cycle of understanding requirements as much as possible. Idealists will tell you that requirements should be completely understood from the get-go, but this is often an unrealistic goal.

The reality is that requirements change ‒ the customer themselves may realize new requirements, laws and regulations may change, terminology may change and a slew of other changes may occur, all of which can lead to the introduction of different requirements. Ignoring these changes in requirements simply means extending the amount of time spent building towards incorrect requirements, which will ultimately amount to wasted effort on your team's part.

As agile teams, most of us like the concept of a protected sprint, but this shouldn’t blind us to the introduction of real changes in the marketplace or customer needs. The worst thing you can do as an agile team is ignore changing realities and, in doing so, fail to adapt to changing requirements.

What You Can Do About It

Want some actionable ways you can better adapt to changing conditions? Keep in constant contact with your customers and end users.

Do frequent research on the context surrounding your product and users, such as laws and regulations, marketplaces, terminology and any other relevant factors. Shorten feedback loops as much as possible ‒ do not shy away from customers, and force yourself to interact with them and ask as many questions as you can.

Remember, agile is all about responding to change, so staying ignorant to the changes surrounding your work is a fatal mistake. Don’t just respond to change ‒ seek to study and anticipate changes as quickly as you can, and you’ll be able to ensure the iteration you’re working on is heading in the most accurate direction possible.




Personal Change: Unlock Successful Organizational Transformation

Here we are, about month and a half into the new year. According to Gold’s Gym, it’s also the “fitness cliff” - the week most of us will stop going to the gym.

Why is it so hard to keep those resolutions, to make changes stick? After all, there are only three things one needs to know to embark on change:

Where we are (me: a bit over 14 stones) Where we want to be (a stone less) The means we should try to maneuver the territory between #1 and #2 (eat less, exercise more) Old Habits Die Hard

One reason individual change can be so difficult is the power of habits. All of us have created many routines over the years. These behaviors have not only been responsible for our success, but have also helped shape our inner identity. We have been rewarded for certain behaviors, which we then strove to maximize. And we have likely been disincentivized (punished) for our non-compliant behaviors.

Meet Your Inner Reptile

One of the biggest obstacles to modifying our habits is our amygdala. That element of our brain structure gets direct inputs from our senses. It is highly pattern-focused, and processes many of our memories and past experiences.

The amygdala has a direct line to the neural networks that activate both our reward (approach) and threat (avoid) circuitry. It is very, very sensitive to danger and does its computations rapidly, well before we have had a chance to think things through with our much newer (and much slower) brain structures.

That ancient part of our brains helped our ancestors stay alive long enough for us to emerge from the evolutionary tree.

Thank Goodness for a Neocortex

Fortunately, we can work with the adaptive nature of our newer gray matter - our neocortex - to help us make change happen and stick.

Social neuroscientist David Rock has done extensive study into how the neural networks of both our older and newer brain structures impact our behavior in groups. I believe his model offers a key to unlocking successful change at an individual level - which then can cascade to the organization.

Rock’s SCARF model looks at the following five areas of social interaction:

Status – Relative importance Certainty – Ability to predict the future Autonomy – Sense of control over events Relatedness – Sense of safety with others (Are you my friend or my foe?) Fairness – Perception of fair exchanges (Are the rules of the game are clear?)

Being aware of these five domains and their influence on our behavior during periods of change will help each of us to get in touch with what might otherwise remain buried deep in the older recesses of our brains.

This understanding will help us when it comes time to making new kinds of decisions and taking new actions. It will help us manage our emotions and our stress levels when dealing with the uncertainty that accompanies change, when the path forward is unclear.

Gaining control over our emotional reactions to the stress of change and being able to train our neocortex to inhibit our amygdalas will have an added benefit of making us smarter. I’m not kidding here. Studies have shown that when we are in a stressed or threatened state (i.e., amygdala on high alert), there is literally less oxygen and glucose for the neocortex’s cognitive functions.

Unwrapping the SCARF

Let’s explore a couple of elements of this model in the context of a middle manager making individual changes to move from a command and control attitude to an agile mindset.

Our manager has likely attached much internal meaning to the importance of her status as a boss. She may have even responded in the past with aggression should her power be challenged (“We can’t possibly deliver X scope by Y date, boss”): “It’s my way or the highway!”

This is because a threat (perceived or real) to her status activates exactly the same primal neural networks as a threat to her life. And cortisol, the stress hormone, flows fast. That vigilant amygdala processes stimuli well before things reach her conscious awareness.

Well, that now presents a problem, eh? To be successful on the journey of embracing agility, our middle manager has to look at things in a very new way … decisions will need to be distributed to the wisdom of her teams, not addressed by hierarchy. And if using a Scrum framework, the team will not be dictated scope and delivery dates, but will themselves decide how much of a workload to accept in a given iteration.

Fortunately for our manager, there are tools that will help build a bridge to a new way of interacting:

Team Agreements Delegation Matrices Definition of Ready (DoR) Definition of Done (DoD) Enabling Self Learning Teams

Created in a spirit of collaboration with the manager’s teams, these tools can develop an environment of greater certainty, autonomy, and fairness, paving the way for good change - and not just for the manager.

The Power of Iterative Change

But as mentioned above, it will take time for our manager to change her ways, to move out of her habit-realm (See above: Old Habits Die Hard). Her evolution will likely be bumpy as she trains her neocortex to inhibit her amygdala.

In the beginning she will start to catch herself after the fact of an amygdala hijack. (“Damn, I just [gave out an order, provided the ‘right answer’, yelled at the team]…”) During her next stage, she will catch herself in the act (“WTF is wrong with them! typing… getting ready to hit reply all… oh wait…. save draft instead of send.”) Emerging to neocortex domination, she will think about things before she acts. (“Feeling the need to say something that really what’s best? Let me count to five first…”) Arrival: She says and acts in a new way (or in some cases does not act) without forcing herself to think about it.

All along this path, people will value our middle manager differently. Not because of the implied power of her position but because she is changing in a way that brings out the best in others. Voilà: Status reward.

And here’s a really cool thing: People think about themselves using the same neural networks they use for thinking about others. As our ex-command and control manager begins to make breakthroughs in her own growth, doing better than last time, her own internal reward circuitry will be activated!

Unlocking Organizational Transformation

Sure, it can be hard to keep those New Year’s resolutions. However, the good news is that with conscious effort (and the support of a good coach), we can make changes that stick.

Along the journey, we will need to pace ourselves, taking time and making space to:

Pause and reflect Accept and learn from failures (don’t sweat ‘em, just don’t stop trying) Celebrate accomplishments, big and small Expect the unexpected

And since all organizations are composed of individuals, this collective pursuit of individual change will lead to greater things.  

As we make breakthroughs in our own growth, we will likely become more aware of potential changes to organizational systems – compensation, flexible work arrangements, extrinsic motivations, information flow, training, on boarding and a vast range of other structures – that can have a huge impact the SCARF domains of our environment.

All of this is the master key to unlocking successful transformation at the scale of our organizations.

The Role of a Product Owner (Part 3): Anti-Patterns

Part one of this series examined the responsibilities and characteristics of a product owner; part two looked at their daily activities during a sprint. This third post focuses upon common anti-patterns seen with the product owner role.

Here are my “dirty-dozen” product owner anti-patterns:

1. No Single Product Owner

Each Scrum team must have a single product owner. Multiple stakeholders are acceptable and usual, but one person must be identified and empowered in the role of product owner for the team.

Solution: Identify a single product owner for each team.

2. Inaccessible Product Owner

The product owner must be available to the team to answer questions whenever required so as not to reduce capability and lower morale.

Solution: The product owner must be present to support the team during development - aim for at least 50 percent availability.

3. Proxy Product Owner

When the real product owner is unavailable, and a proxy is appointed, then it is critical that they are fully empowered within the role. Proxy product ownership often leads to delayed decision making, conflicts in direction and an overall lack of trust within the team.

Solution: Engage the real product owner or fully empower a proxy. Additionally consider employing specialists to provide extra support.

4. Role Confusion

There are only three roles within a Scrum team - product owner, Scrum Master and developer. The Scrum Guide specifies each team role, following this guidance helps to avoid confusion and potential corruption of the framework. Additionally, the product owner should never be double-hatted as the Scrum Master.

Solution: The product owner should perform that and only that role. Also, note that the product owner is part of the Scrum Team and not separate to it.

5. Lack of Product Focus

The product owner’s focus must be on developing a successful product. When the role is confused as a managerial role it can attract political appointments and results in sub-optimal performance.

Solution: “The product owner is responsible for maximising the value of the product and the work of the development team” - The Scrum Guide 2016.

6. Inadequate Product Backlog Management

The product owner is responsible for creating and managing the product backlog. By evolving the product backlog during development, the product owner maximises return on investment and improves customer outcomes.

Solution: The product owner must maintain the product backlog so that the work is visible, transparent and ordered.

7. Poor Feature Slicing

Product Backlog Items should consist of vertical slices of end-to-end functionality. Solutions are developed and delivered incrementally from skeletons, prototypes, minimum viable products and minimum marketable products to fully featured products.

Solution: Create work based on the end-to-end value to maximise feedback and reduce risk.

8. Lack of Vision

The product owner creates and communicates the vision for the product based upon customer domain knowledge and an understanding of the development life-cycle.

Solution: Create a clear vision and communicate it to everyone.

9. Faster, Faster

Pursuing the speed of delivery over customer outcomes does not lead to long-term product success. Although shorter lead times (concept-to-cash) is great for feedback cycles, sometimes faster is just faster.

Solution: Focus on addressing customer’s needs with high-quality solutions, iteratively and incrementally.

10. Failure to Trust

Product owners must demonstrate trust in the development team in their words and interactions. Trust prevents poor practice such as:

Stretch Goals- Product owners identify extra work “in case the team finish early.” If the development team completes the planned sprint work early, they will ask the product owner what they would them to work upon next. Development Interference- Micro-managing teams plus tracking and chasing each task performed. Self-organising teams require leadership and not management. Estimates as Deadlines – The development team forecast the work to be completed within a sprint. This estimate can change and the product owner must take this into account.

Solution: Trust and support the development team to deliver.

11. Absent Governance

Scrum is not the absence of discipline; governance is still essential to maximise value and minimise risk. The correct outcome-based metrics are required in addition to stakeholder and risk management. Applied correctly, agile projects are lower-risk and more transparent to everyone involved.

Solution: Provide appropriate light-touch governance throughout development.

And we are done. “That was only eleven anti-patterns and not a dozen as you claimed” I hear you cry, well that is because we are agile and always finish early (wink, wink).

Hopefully you recognise some of these patterns and can avoid some of the others.

You have to learn from the mistakes of others; you won't live long enough to make them all yourself.”

- Eleanor Roosevelt (quote attribution is actually unclear, though Mrs. Roosevelt is the best match)

In the final post of this product owner series, I will focus upon the pragmatic considerations of the role.

What do you think? Please let me know in the comments below.

Agile Examinations

Imagine walking into a school examination hall and opening up your exam paper to find a single question. As you complete your answer, a mark appears and the next question is revealed. However, this time you have some all-important feedback from your previous question.

Now I don't know whether the examination’s outcome would improve, however it does provide options:

1. If you got the question right, the best course of action would be to continue what you are doing.

2. If you got it wrong you can:

a) Chose to adapt your next answer or

b) Decide to get up, leave and do something more valuable instead.

No, this isn't an excerpt from J.K. Rowling’s next book. Welcome to the world of agile education.

From an early age, we are conditioned to get all the answers right the first time and take large upfront tests of our knowledge. This mindset can also be seen in our working lives, where there is a belief that if we research and study the customer hard enough, we can determine exactly what they need through analysis and assumption.

In his book: “Kanban from the Inside” Mike Burrows describes the need to shift mentally from taking orders and fulfilling requests to discovering and meeting people’s needs. This is reinforced in the opening line of the Agile Manifesto, "We are uncovering better ways..."

So how does this relate to examinations exactly? Think back to your most recent exam; it may have been a CSM or PSM you were sitting. You probably attended a course and then spent many hours reading and storing away knowledge that may or may not be tested in your exam session.

Now imagine you were instead assessed on the quality of the hypothesis you construct, how you might go about testing it or what you have put in place to accommodate the possibility your hypothesis may be invalid. This calls upon an entirely different set of skills and thinking patterns.

A few years ago, I had the good fortune to spend time with the former NFL player Eric Boles, who, since leaving the world of American football, spends time with teams and individuals, helping them identify their limiting beliefs.

One of the insights he shared which has stuck with me is, "What got you where you are today, will not get you where you want to go tomorrow."

Now I have no doubt this quote is attributed to someone else and please let me know in the comments if you've heard it before. However, he delivered it with such impact that it placed in my mind the image of a trapeze artist, swinging gracefully through the air, grabbing the next trapeze yet refusing to let go of the previous one.

The result is they become physically stretched by these two opposing forces and lose significant momentum.

This is what can happen to us and our teams when we are not ready to let go of that learned behavior of getting it right first time. Eric stressed that the act of letting go can feel very daunting at first, yet it is something that, practiced regularly, can start to replace the need to know all the answers.

So how might this look in practice? First, we need to free ourselves from the perceived need to know the right answer and instead focus on choosing the right experiment.

Invariably this first experiment will be big and daunting, so break it down to the smallest possible question (or hypothesis) that creates a feedback loop.

Once established, customer feedback loops are like an uncertainty vacuum, removing doubt and replacing it with the confidence that you are meeting a real need. They also work in two directions: As you discover more about a customer’s needs you provide more of what they seek, then the relationship grows and the customer shares more.

So next time you get a feeling in your stomach that what you're developing is not what the customer needs, listen to your intuition and shift your focus to the question: "What is the smallest, safest experiment I could conduct to gain feedback?”

You may not get it right first time, but that's the point. Examinations measure knowledge at a point in time, whereas learning = continuous growth!

What do you think? Let me know in the comments below.