To Whom It Should Concern

To Whom It Should Concern,

I am writing to you on behalf of a team I have will have the distinct pleasure to work with.  I don’t know when – as I have yet to meet them,  but they are out there.  Some when in time. This team will adopt an entirely new way of working and will change many of the processes around them. They will also change the tools they are used to.   This team is a natural collaborator.  They may not have all the answers, but I will see them get stronger and more  resourceful with every challenge that they come across.   They will develop a calm and deliberate manner with which they approach the work.  They will help the organization to understand the product they inherited and their own capacity for work.  This team will often strive for opportunities to better themselves. They are earnest in delivering a product that is slowly becoming what the user really wants.  It may require a bit if patience as this team matures.  There will be sparks of innovation and creativity that pay small dividends and will continue to accumulate for the benefit and influence with the other teams.  This team will need your support and at times your patience.  They may even struggle at times or misstep as they find answers on their own.  They may even challenge you.  I will tell you, there is greatness in this team. They will grow and tackle some tough problems for the organization.  They will try, learn, teach, and influence others to improve just as they expect it from themselves.  Congratulations on having such a team.  They are the ones doing some heavy lifting.  I hope you trust their professionalism and that they honestly want to create something valuable.    Help them with obstacles and to celebrate the small wins along the way.  Stay engaged.  Your interest and guidance will eventually find that they will be able to run faster than you could imagine.  Congratulations.

Xtreme Feedback

I once posted that in an agile sense it seems like We Can Never Go Fast Enough.  Going fast means we need to have quick reflexes; the ability to adjust. This in turn relies upon feedback.  Some information that quickly lets us know how we are doing and allows us to steer back on course. If someone is YELLING, then it’s our ears. Very often, however, it is our eyes that tell us.  It is why we lean so heavily on information radiators and large visual displays.
There has been a growing trend for a while now in pursuing ever faster feedback mechanisms; often named Extreme Feedback.   

The Extreme isn’t so  bad. Not as in some reality show which uses shock collars when something gets broken, but rather in the ability to very quickly ascertain information.

1) Where the code is
2) What State the code is in
3) If Something undesired actually happens – Signal for help!  600px-Nabaztag-IMG_1666

Whether it’s a bunny from Nabaztag or an Arduino (Uno or Mega) with some LED’s like this starter kit - these indicators can be tied into a build process and let the entire team know what is happening.  Collocated or distributed, these devices are fun ways to immediately inform the team about what is going on.

A Team Foundation Server Build Bunny

I might choose the bunny because Easter is almost here! I might choose an Arduino because I am tired of Hidden Easter Eggs!
From the Quality side of things, I always disliked very long processes that went on and didn’t have any verification until a dozen or more changes were involved. Let alone another dozen processes had already been gone through.  It was even worse, if like in waterfall, the next stage was the verification of several months of work.  Extreme feedback pushes into the small changes that the build is compiling and does a great job of simply making everyone aware. Quality in the moment. Devices like this can be tied into deployments, and even into Test results. What about some aggregated sprint or release results? Granted the feedback on a release is going in the BIGGER direction – but the automated indicator of a :(  *sad* bunny is impetus enough to rouse ourselves to action and address the problem.  In a fun way of course.  

If the team has a budget (and I often think it should), this might be a great, fun, and motivating project to help the team to get ‘to good’ as soon as something goes wrong.  In TDD (Test Driven Development) terms “getting back into the green”.  A passing state, and out from the red, broken state, as soon as possible.  The term leverages from the eXtreme Programming or XP Practices that Kent Beck championed.

Have fun if your team decides to use one.  Let us know how creative you were.

Without A Net

As a traveler I know there is always something new just lurking around the corner.  Whether it is taking a metro train and navigating a city, navigating a building, or even meeting people for the very first time.  Sometimes even when I am doing something practiced, a new situation has the tendency to spill itself all over the comfortable events I had planned on neatly unfolding.

There was a book written a while ago Working Without a Net.  I liked the premise that – eventually we should get used to doing some great things without worrying if we had a safety net below us.  Now I do NOT condone physically working without safety equipment.  Yet the mental equivalent of something comfortable which might hold us back from trying something amazing now and again, resonates with me.   The chapter about channeling one’s anger, seemed outdated, since it suffices only as a very short term motivator. – But, back to my story…

I have had a slide deck around for a little while.  I spent an hour updating it.  Improving it a little each time I bring it out.  It might be getting a little long with all the cumulative material through the ages.  Yet it allows me to cover the breadth and depth of the material.  I am comfortable with the content.

I had arrived early to the room.  I usually like to get a feel for the space which I am going to be throwing ideas around in.  Often I will change the contents around in some formation that benefits the audience as they participate.  Sometimes just to introduce a a change that keeps a creative ember burning somewhere that spacial permanence has seemed to desensitize the returning audience.  Tables and chairs arranged. CHECK.

Then the projector, screen, computer, slide deck, and any typical markers or post-its that a ‘meeting-in-a-bag’ might offer.  CHECK.

I know my voice can dial up to carry across the room – no mic. needed.  Wireless presenter to allow for some mobility.  CHECK.

Audience is starting to trickle in now. CHECK.

and with a quorum – off we go.  First Slide… Starting into the topic… and the projector goes out.   *sigh*

Is there a quick 10 second fix… nope.. and then the priorities start to become clear.

Why are we here -FOR THE AUDIENCE.  These people are important to me and I absolutely do not want to wast their time.  They have asked me to explain and explore a topic they have all previously expressed an interest in learning more about….  Alright – I made the slides – and those were from my experiences and insights… I’m still functioning….   What do I have around me… I have just switched from assessing situation, and a quick personal (psychological) inventory to looking at my surroundings.  What in the environment can I use to aid my survival.  :)

Abandoning the projector and screen

I see a whiteboard… I’ve got a marker or two… and the slides now become the old ‘Chalk Talk’ using some dry erase markers.

What were the really REALLY important things I want them to come away with… my mind starts leaping forward and re-arranging the material instantly.  Let’s draw it out.

Along the way I reach out and offer some choices as an audience… there might be two different exercises we can do to practice this… ‘which one would you like?’  The decision from the crowd takes a few seconds… It is one way to characterize the group – how long do they take to make a decision and how many were vocal.

The time and breadth of topic passes quickly as we get questions along the way which perfectly explore some common areas that can be misunderstood.  GREAT Questions that actually lead me to cover areas I might have missed AND take the audience along the route they wish to explore.  I feel more like a guide than a presenter.  Our safari into the topic still leaves me with how fun it can be though I’ve been here many times before- just not in the same vehicle driving through it.

Joking, laughter, and even a few AHA moments.

And before we go, a few minutes for being retrospective and feedback about the time we spent together… Some pretty high marks…no mention of the projector.  The ability to switch manner of delivery and increase participation is perhaps left unstated; simply appreciated. No thing is perfect but our ability to make adjustments along the way is perhaps one of the basic tenants for agile – have a plan but get used to adapting.

A few linger afterward and want to explore other areas of knowledge.  I wonder if the teachers choose the students as often as students prefer to choose their teachers?

The NET that I was careful to prepare, the slide deck… seemed as if it held me back from really connecting and getting the best curiosity and participation from those who attended.  What else is there that might be so comfortable, it may actually hold back and keep from moving into some spectacular things?

Never Going Fast Enough

There is something about organizations today that is prevalent.  The feeling that we just can’t go fast enough.  Many don’t really know the organization’s capability, or aptly characterize what is going on.  To know precisely where and how to improve may be lacking, let alone be aware of the impact of it all.  Teams themselves get impatient and  start to lose some of their calm about the problems that beset and beleaguer them.  So what if we were to make a few basic premises about the organizational landscape.

1) We are all here to do the right thing.

Not everything will help, but wouldn’t it make a difference knowing that we ALL want the software that we deliver to not only rock… but paper and scissors as well. MakerBot’s 3-D printer MakerWare will install and tell you that you are installing a bundle of AWESOME.  I wish we were all as excited about developing and using our software! Trusting that we want to do better lets me have some patience as we try a few things to improve.  Being open and honest also means we are saying directly what concerns us. It also means that if we see a problem then we also know enough to get in there and be a part of the solution. We need EVERYONE’S creativity and innovation. Not locked in up in a solitary head, but communicated and collaborating with the team.  It also means that when teams get moving, they will be fairly quick to act in solving and addressing problems.

2) Organizations are fighting for growth – or sit back, stagnate and eventually become obsolete.

The universe allows very few things to continue without some form of upkeep, maintenance, and eventual improvement.  Mathematical equations might be one exception, but algorithms which are great at data mining are not.  Software is the same way.  Technology improves our platforms of usage with smart phones and tablets.  Education and expectation grow the demand of an increasingly integrated and aware customer base. Innovation changes paradigms and allows some great advancement or advantage.  Moving forward and improving is a continuous adaptation.  The time to react, from perception to deliverable is now the measure for organizations.  How nimble, how agile are we?

3) There are no limits, only plateaus- get beyond them.

Bruce Lee said something to this effect.  We have a tendency to complain about limited memory, limited attention, limited time.  Another way to put it is cognitive load.  The ability to think is relies on internal processes such as motivations, reasoning, planning, learning, and solving.  External processes would include perceptions, stimulus, and actions.  Most of my own limitations start with where I think I can’t.  I have always been most rewarded in pushing beyond what I’ve done before and doing it from the perspective that I CAN… GO.

4) Teams require work

Investing time in the communication, collaboration, and the cultivation of the team is important.  Remember the team is the only thing in the organization that will do the work and get the software to done. Investments in great performing teams will allow the organization to really move.  Just as individuals collaborate, so do teams. It starts to scale. I know some individuals out to change the organization.  How much more influential might teams themselves become?  How about programs of teams?  We might not be able to go fast enough. I will say, however, that if we see the improvement – our rate of change will increase as we push against our own limitations as an organization.



The Eye of a Transformation Storm

A little known fact about myself.  I used to have a great fear of speaking up in front of a room, in front of others.  No Joke.  It went to such an extreme that I buried myself in books (especially English literature) and memorized vast amounts of quotes from others.  My own words never seemed worthy enough to be expressive and meaningful. So I relied on these quotes and spent a lot of time trying to be prepared when I HAD to speak or give some speech. Then immersion was next.  Speaking again and again and learning something new from every single experience.  A powerful one is when the speaker actually listens to the rest of the room and adjusts to where the group asks to explore. It would be unfair if this circumstance is more like performing a rescue. Getting all gear prepared, getting into the helicopter, starting it up and then just sitting there yelling at a stranded victim to come to you.  We actually need to be at the very perspective they are, help them triage, prioritize and assess, and move.  Ever a balance with leading the group to where it needs to go.

I look back across the years from whence I deliberately wandered and can only smile.  I now find it wonderfully rewarding to speak to rooms of people.  This is where it starts. The spark to transform an organization starts in small teams and grows.  In the beginning of this transformation the inevitable J-Curve panic sets in.  Sometimes the initial chaotic dismay is like listening to a storm. There seem to be SO many problems that I often hear ‘I thought that Agile was supposed to solve all our problems’, and ‘Agile isn’t working’.  The reply is usually – that Agile will not SOLVE your problems, but it will certainly help expose them!  We rely on people to solve problems.  Agile just provides some framework in which we structure the interaction.  We all know that although people are quite comfortable with old processes, that they certainly didn’t work out well either.

Supporting each team in adopting, and watching them grow faster and faster, overcoming the next obstacle, is rewarding.  Watching as they begin to mentor other teams, even more so.  Jot down a few things about what you would like to change.  Then be patient about growing to get there.  As you improve, having a taste of what went well, teams usually move forward from there.  We aren’t only problem solving the right software in the right way, we are building some great teams as well.  The next step is to terra-form the organization to support and allow those teams to thrive.

There will be storms along the way.  I can tell you however that they usually pass.  Come and go.  With every one the landscape changes just a little.  Maybe because Spring is here; but with each deliverable, as we endeavor to make ourselves a little more agile – I see organizations being transformed as well.

Agile Conversations

There are plenty of conversations that are happening in teams.  No matter where along an experience spectrum you are.  I have one of the most rewarding jobs in the world in being able to participate in many of them along the way.  Listening to understand where the team finds itself, what it clearly recognizes, and the destination they have in mind.  Sharing my own experiences when the wisdom is appropriate is expected.  Having a genuine interest in who people are, helping them grow and change the organization they are a part of, has ever been rewarding.  Writing is one way to help practice the communication we come to rely on.  Communicating is typically very high on the scrum master list of things to improve around the team.  Rightly so. Information radiators, stand-ups, conversations, are a few of the things that guide our work and help us learn or focus. Edward Tufte knew how important it was to visually convey information.   With conversations I find myself mindful of a few guiding principles.

Be gentle and respect someone else’s time.  Keep them involved, not as a tactic, but because of genuine appreciation.

Help them from where they are, not from lecturing where they ought to be. Share the experience and learn along the way.  The inner fixed points from which we tether in order to perceive the world are familiar.  They can also limit us, because that person on the other side of the conversation is rarely at the same vantage.

Come away with the next small action that can help.  Working in the moment helps.  Decisions on what next to try and what might be too big to go after just yet, are important.  Collaboration, convergent expectation, and earning trust that we are all invested in growing in the same direction.





The Agile Hard Hat

When a company has made some inroads to being agile it seems as if something is always under construction.  A process, a team, the software… something. On a real construction site, it’s a hard hat that provides some degree of safety. LOOK OUT!  The same might be said for an agile environment.  But within the context of thinking caps, I think of a hard hat as a mode that seems to be stuck, frozen.  There is something to an agile environment that puts us into the edge and makes explorers and problem solvers. There are always a few that seem to hunker down and are really uncomfortable with the participation.  Sometimes it is trust, sometimes it is a slower rate of acceptance… the reasons are legion.  A good way to take some team members and start them down the road to perspective and context switching is Edward de Bono’s 6 Hats Exercise for a retrospective.  Now this isn’t a Scrum thing, but it is a way to get team members to become flexible thinkers.  To describe it quickly – each of the six ‘thinking caps’ represented by a color has it’s own way of thinking.  Take a look.  Black- critical, Yellow – optimistic, White – factual,  Blue – process, Green – creative, and Red – intuitive.   Scrum masters might want to switch up their entrenched black and yellow thinkers in order to move a team forward and get them to be agile thinkers.  Mix it up, rotate or randomize.  

Lincoln once said that if “I were given six hours to chop down a tree, I would spend the first four sharpening the axe.”  In his wisdom Lincoln was differentiating between activity and achievement.  Something John Wooden as a coach would often tell his teams were two very different and distinct things.  Activity. Achievement.  Scrum teams often have to use this disruptive innovation to focus at a level of thinking.  Are we tasking? Or maybe we are using this next (some-time box of) minutes to talk about and clarify our stories, features, epics, releases, product, or portfolio?

Now, as a manager or a project manager, I occasionally hear something that goes to the effect. ‘Why are my developers in a meeting?  They should be coding 100% of the time”  I try not to sigh noticeably.  This, is after all, where the some of the organizational terra-forming begins.  It can be  a mistake made by some traditional practices.  It is more surprising to continue to uncover this years into an agile adoption.  But make no mistake, I am always glad to bump into it.  We can’t get to the correction which makes it right until we are speaking openly and truthfully.  There is an echelon of QA and test professionals that echo this mantra.  However, I’m not usually the first to bump into the mentality – which means it is rather a rigidness of thought that has a tendency to persist until it meets with its paradigm shift.  Some one buried in activity has little time to change how they work, let alon how they think.  We advocate and support it should be expected instead some time is spent to focus on improving how we work.  Kaizan.

Agile does more than just re-arrange the way we do our work.  It changes how we think.  Software is problem solving and some pretty hard thought work.  If there is a difference between achievement and activity – the axe that we should spend some time sharpening - it is our own minds. Other tools and processes certainly fly into the mix, but the interaction still leverages our ‘thinker’.

A rigidness of thought.  The thinker might have stalled out.  Ever meet that contrarian person?  Just so negative all the time?  To go the opposite extreme and be perennially optimistic can sometimes lead to solutions which might not be robust.  We need everyone to be agile thinkers to get this software to done.  I think I can… I know I can set aside my hard hat as we improve the software, ourselves, our team, and the organization.

The Sprint That Blew Up

Is it appropriate to blow up a sprint?

The Setting
We were several sprints in with a new team and suddenly the team was faced something new.  Something out of their control caused havoc with the priorities in the Backlog. The work that the Scrum team had committed to for the sprint was no longer needed.  In the Sprint Review the scrum teams voiced that we did not meet our original goals.   The teams and the product owners were hard-voiced about having to “blow up the sprint” and having to “re-plan and re-baseline”.  There was a discomfort level and some confusion within the team as to whether we might have done the right thing. The strongest statement was, “The institution of scrum was disrespected.”

The Cliff Notes Answer
Leadership, stakeholders, coaches, and scrum authors say we all made the right decision and behaved correctly. Changing our sprint backlog in the middle of the sprint made sense because it honored new business objects and the desires of our Product Owners. The scrum play book says it is perfectly fine for teams to break the sprint this way as long as this is the rare exception rather than the norm.
The Detailed Answer
As I am talking with the team I will start this out with saying “GOOD JOB”
and end my conversation in the same way. I start asking QUESTIONS.  
When is it appropriate to Blow up a sprint and re-plan/recommit? 
Are we allowed to do it? Sure.
Always I want to ask questions. The first one is obviously Why? 
Is this a BIG Deal? I think it is.  Firsts often are. 
Were our assumptions on the sprint goals wrong?
What risk did we not think about critically?
What wasn’t communicated?
Does this still make sense?
Were the release themes not vetted from above and below? 
Was everyone on the same page for acceptance criteria for the stories?
What changed our assumptions?
How can we prevent this from happening again?
The Team did A LOT of work! 
We adjusted to the highest priority!  
Will the business expect this as common practice?
How disruptive was this? 
What was the impact? Did we lose 3 days of our sprint?
What did we learn? 
How do we improve?
I write this after the fact because we are empowered to make these decisions.
Don’t regret the decision – learn and adapt.  You have also worked through a fairly large and complicated problem.
You have changed, and will continue to change some of the assumptions we have together, as an organization.
Good Job!
————–Here are some external references from the proverbial Agile Library: 
Succeeding with Agile (Mike Cohn) pg 282 “I usually advise Scrum teams to start taking a firm stance against mid sprint changes. This is not because I am Opposed to redirecting a team or because I want to slavishly obey a Scrum Rule. It is because I want to help those outside the team learn that there is a cost to redirecting the team.  Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t think ahead. I relax this hard-line stance against change after I see the organization no longer thinks of every new request as an emergency worthy of a mid-sprint change.   Being responsive is what has made us successful, and users expect that of us.
Exploring Scrum: The Fundamentals (Doug Shimp and Dan Rawsthorne) 1rst ed. pg 268 “Cancelling a Sprint. The product owner may cancel a Sprint at any time, usually because the Sprint Goal isn’t going to be met or because the Sprint Goal is no longer what is needed. In either case, the Sprint’s work is evaluated to see what can be kept, and whether or not a replanning is called for.  This is not considered abnormal, but it is simply an agile reaction to something that has happened. It should not be considered a ‘bad thing’ - it is merely a ‘thing’.”
Scrum Product Ownership (Bob Galen) pg 110 “Adjusting the Sprint. … In fact the leader here should be the Scrum Master. He or she is your partner and should guide you in making any necessary adjustments, etc.  However you do play a significant part in the Sprint recovery process, too!
 CONTENT DISCONNECT. The team is struggling to deliver the Sprint contents. Within a few days of the Sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint.  That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced length Sprint in order to maintain your Synchronization. …  I’ve seen teams significantly recover their progress and often meet the original Sprint Goal. …
 PRIORITY DISCONNECT. … In these cases he (product owner) was more likely to cancel the sprint and then re-plan a new one based on a major shift on the backlog.  However when re-planning we tried to stay open minded about integrating the new work and maintaining some of the original Sprint focus.  Another aspect of this is insufficient look-ahead. I was never convinced that we couldn’t anticipate these changes in some way. Remember, we were on a 2 week sprint model which is fairly nimble.”
Changing direction doesn’t come for free. We are trying to be agile and make adapting lightweight – but a team’s capacity to do so is not infinite.  The time and impact required to pack up what we were focused on, and then re-plan should not be ignored. When we commit to a backlog at the beginning of a sprint, the team is serious about delivering the work and trusts that they have everyone’s support and are allowed to maintain this focus in order to deliver.  Unanticipated work in the middle of a sprint distracts. If a team starts to believe their commitments will be ignored, the erosion of urgency, commitment and trust start to occur. Loss of trust erodes team morale and we’ll eventually find ourselves back to where we started. In quiet silos with being defensive about collaborating.  Our ability to fail early is not a joke.  It is instead a measurement for how quickly can we get to right.   
A message like this should be visible enough to encourage the team we did the right thing.  Some VPs, a few Directors, coaches and half a dozen managers as well as the teams themselves needed to know and think in a manner where there was no ‘us’ vs ‘them’.  There is only “WE”, together.  As in WE will make this better and work together so that it shouldn’t happen again.  As well as, we will be thought-full about the “But if it does…”.   This is what transforms the organization, delivers great software, and as a side-effect, makes some high performing teams.
If you’ve made it this far, thank you for reading through the details.

A Safe SAFe Journey

I have been very open about my views on SAFe.  I’m a supporter and, admittedly, cautious in my support.  I am cautious because I worry the emphasis on people and the necessary mindset isn’t prominent enough on the “Big Picture”.  In the wrong hands, the results of implementing SAFe could be….lacking (aka: horrendous) resulting in a horrible experience for all involved.  While, honestly, the same can be said of any framework used to implement Agile; SAFe is riskier because it’s BIG.  It can be HUGE even which, as we all know, isn’t the preferred way of operating.  Recently, I embarked on an opportunity to coach a a group with a BIG vision and they want to be as close to Agile as they can be.  Enter SAFe and the journey of making it safe for all those on board the train.  I’m going to do my best to share this experience with you.

I’ll start by explaining what I mean when I say “safe” or “safety”.  To me, a safe environment is one in which the values and principles of both lean and Agile can be put into practice without fear.  It is safe to raise issues, learn, make quick decisions, disagree, develop, release code into production, be honest, tell someone “no”, empower people, trust people, try something new and do what’s necessary to achieve the vision everyone (and I mean EVERYONE) is aligned to.  There’s more – lots more – but I’m sure you get the gist.  This kind of environment isn’t an easy one to create from the beginning and even harder to achieve when an organization is established and set in their ways.  So, where did I begin?  With the people who invited me to coach them and their leaders.

Do you know how hard it is to get “higher-ups” to spend a day with you for “training”?  Most of the time, it’s not even possible.  I can’t tell you the number of times I have watched perfectly good and valuable training which, typically, would be a full day get hacked down to 2 hours.  Funnily, it’s not the people receiving the training who require the cliff-notes version.  It’s those below them who insist a whole day isn’t possible and you’ll be lucky to get those 2 hours.  Then, you don’t get past slide 3 because slide 3 USED to be slide 30 and you’re training slides 2-29 off-the-cuff.  And, just when you really get going….times up!  Anyway, don’t get too excited because I didn’t get a whole day.  However, I was able to spend a solid six hours with them and I believe that time is one of the differentiating factors for this particular SAFe adoption.

The first clue I had to the possibilities of this group was they didn’t balk at spending time learning about Agile, lean, SAFe and what it means to be a leader in Agile.  The second clue I had was their laptops were down, phones were on silent and turned over and they were 100% present and engaged.  Granted, I did ask them for that but they didn’t complain!!  They just said OK and did it.  Third, the place where we spent the majority of time was on being a leader in Agile and working on how they would work together to make this effort special – not only in WHAT they were delivering but also HOW it would be delivered and how they, as a leadership team, would work together towards realizing BOTH objectives.  They immediately were applying what they learned to their team and their situation with completely open minds and genuine excitement. Finally, this group of leaders with open minds and genuine excitement realized and discussed how difficult this would be for those directly and indirectly involved and how, while they didn’t have the answers, would need to be supportive of each other through the journey of learning.

So far – and it’s only been a month or so – I have observed some pretty cool stuff that started during those 6 hours.  I have watched these guys engage with others in a different manner and subtly shifting the tone of conversations by sharing their vision and extending invitations to be involved.  I heard them asking other leaders (and each other) to “ask the team”.  I have seen them catch themselves and correct behaviors to model Agile principles.  Most of all, when they were up there in front of 150 team members, they all said (in a nutshell) they were there to support and enable the teams and their ability to achieve greatness personally and professionally.  They talked about empowering the individuals and the teams.  They stated they didn’t have a hard date and a backlog of non-negotiable scope.  Instead, they had release candidates and the teams were in control of what was brought in and what was left out.  They communicated their vision and invited everyone in the room to participate.  The response from the teams has been awesome.  From them I hear things like “These guys actually seem to believe in and want Agile so why don’t we try <insert experiment for team to get closer to Agility here>?

Here are the key learnings I have from this particular stop on this journey:

  1. Be very clear on what you want people to leave the room with following your time together and spend the majority of your time there.  The training isn’t what’s important.  What is important is what they do when they leave training.
  2. Ask people to set aside what their reality is – for a time – so they can learn without interference from it.  Then, ask them if it’s OK to hold them accountable to that (assuming they agree to).  This keeps the dialogue open without getting mired down in specifics from their reality.
  3. End your time with real-world application.  NOW they can bring their reality in.  This time is priceless. Minds are open.  Challenging their conventional wisdom is fluid and the knowledge goes from theoretical to practical.
  4. Start with the mind-shift and take it from the TOP.

The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part Four


Eight Tips for Optimizing PO-to-PO Relationships

I’ve talked before about the inherent problem with enterprise Agile: having more than one Product Owner on a project. The fact that the problem is inherent, however, doesn’t mean that enterprise Agile is flawed, it simply means that we have to accept the incongruity of what amounts to mutual ownership, shared ownership, or no ownership at all (when no PO feels like a true “owner” of any part of the “product”).

In the archetypal Scrum team, there is but one Product Owner. So enterprise Agile, with its multiple POs represents a change from that model. Agile embraces the idea of harnessing change to increase value. So it makes sense to ask, “How do we harness the inherent ‘problem’ of multiple POs to increase value for our stakeholders and satisfaction for ourselves.”

Here are eight ideas. In my experience, pursuing all eight give me the opportunity to maximize my effectiveness. But pursuing any of these with transparency and diligence will improve your results—and because you’re a Product Owner, they’ll improve your product, too.

1. Pick a PO Partner

The most obvious thing we can take advantage of on an enterprise Agile project is that we are not alone. Specifically, I recommend identifying one other PO you can think of as a true partner. As a Product Owner, you face pressure from all sides of the project. The only people who truly understand this are your co-POs. Having one person you can go to—for advice, consolation, or just to vent—is a very useful thing.

If you set out with good intention to pick a partner, you’ll eventually gravitate toward the right person among the other POs on your project. In most cases, there will be several different people you can partner with successfully. Look for two things: (1) A person you can relate to easily and who can relate to you; and (2) A person who has skills that complement, rather than amplify, your own.

The PO role is simply too expansive and ill-defined for any single PO to have everything covered. Finding a PO partner who has knowledge and skills that you don’t, who is also someone you can come to in confidence, and come to depend on for support, is invaluable.

The value of a strong PO partnership is probably best seen when we are struggling. If I struggle alone, there’s a good chance I’ll get stuck. But if I struggle in the presence of a partner, there’s a good chance that person will help me get unstuck.

This can take many forms, but the most valuable thing that I have experienced is the benefit I’ve received from another PO in helping me understand and serve the needs of stakeholders. Often, in our attempt to collaborate with stakeholders, we end up negotiating instead—and all too often we negotiate badly because negotiating is not something most of us specialize in. While stakeholder collaboration is preferred over contract negotiation, we all seem to love to negotiate on the job, such is the competitive nature of most workplace cultures.

At times, I have had a very hard time communicating effectively with stakeholders. At times, I have not clearly understood their needs or faithfully represented their requirements. At times, stakeholders have seemed to me entirely unreasonable. But notice that these assessments are based on my own survey of my own perceptions, perceptions that could be highly flawed. After all, a survey where n=1 has a margin of error of infinity.

If, however, I can check off my perceptions about stakeholder interactions with someone who knows me well, someone I trust, and someone who has exactly the same relationship to the stakeholder that I do, I can get a much more accurate read on what’s happening and gain valuable insight into how to perform my role of stakeholder advocate more successfully.

2. Practice Reciprocal Altruism

Evolutionary biologists are always working to make the case that one key element in the survival of the human race is our ability to execute acts of reciprocal altruism. In fact, the best explanation I know for the development of language in our species is that grammar is the easiest way to know “who did what for whom” so that we can remember to return the favor.

Think of this less like scorekeeping and more like investing. The altruistic things you do for other POs—the things you don’t have to do and take no immediate benefit from—are investments in your future success. The more you invest, the more likely others are to reciprocate.

I suggest the investment analogy over the scorekeeping analogy because the latter is competitive and the former is cooperative. Doing something I don’t have to do for another PO is a form of cooperation. The interesting thing about this is that it doesn’t take two of us to agree on the cooperative action. I can initiate it myself.

One of the biggest investments you can make in this regard is picking up the occasional story from another PO’s backlog when that PO’s sprint may be in jeopardy. Invariably, on a project with 5-10 teams, one or two will be doing just fine on their sprints, while several others struggle. Under normal circumstances we can’t barter our team’s resources because this amounts to reassigning work, something that is clearly in the Scrum Master’s domain. But I can always offer to do this if I say, “Let me take this to the team first.”

In fact, I have gotten into the habit whenever I receive a resource-related request of saying, “Let me take it to the team.” What I mean by this is that I am open to considering any and every way of contributing positively to the project but I can only do this through the unanimous consent of my team members.

Setting the high bar of unanimous consent may seem like saying, “I’ll never help anyone ever.” But, actually, it allows you to help everyone more often because it simultaneously displays respect to your fellow POs, to your team, and to the needs of the project as a whole.

If people know that you are always open to considering their needs, they will bring their needs to you more often. If you are transparent about the conditions under which you will be able to help, everyone will understand why you do some things at some times but not at others.

Even consideration is a form of reciprocation. This means it’s perfectly OK to come back with, “The team says we can’t do that right now.” Making the project safe for “No” is a huge achievement that will dramatically improve your organizational culture. It will also make your organization a place where others are more likely to say “Yes”.

3. Root for the Other Players

Multiple Product Owners is a recipe for competition. It’s so easy to get into the habit of zero sum thinking and “win-lose” propositions that we have to put forth a deliberate effort to build a culture where this is less likely to happen. The best way to do this is to actively root for other teams and their Product Owners.

No two teams will perform equally well across every sprint. Some will perform better, others worse. Over time, some teams may develop patterns that contribute to sustained high performance while other teams struggle, sometimes for no obvious reason. When I’m on the high performing team, it’s very easy for me to feel superior. When I’m on the other end of the scale, it’s even easier for me to feel like a failure. Neither of these positions is helpful.

My feelings of superiority, even if they are grounded in empirical evidence, set me apart from my co-POs. This is corrosive of cohesion and culture. It’s also a recipe for disaster if I get into a situation where my team hits a bump in the road. Perhaps worse is the situation where I begin to sense my own failure. Now I want to isolate myself, to pull away, to lay low hoping no one notices until I can figure out how to get things back on track. Ironically, this is the very time I need people around me.

If I’m always actively rooting for the success of other POs and their teams, we stay closer together as a community. My success is everyone’s success and, even better, the success of others is shared with me as well.

There are many ways to root for others, but two have worked well for me: (1) Publicly acknowledging the work of another team during a cross-team demo; and (2) Acknowledging the skill of another PO in private.

4. Exude Optimism

This is huge. Actually, it’s huger than huge. Seriously.

Whether it is fair that the role of eternal optimist should fall to you, a Product Owner, is irrelevant. You must play that role. If the Product Owner is not optimistic, why should the stakeholder be optimistic? Or the development team? Or management?

Optimism doesn’t mean glossing over challenges or misrepresenting hard realities and inconvenient truths. It means responding to these things with a “glass half full” attitude.

Even if you don’t know a way to solve a problem, assert that there is a solution and pledge your best effort to discover it. For every misstep that occurs, focus on the lessons learned and immediately show how you can apply that learning to the next iteration. Reframe problems as opportunities.

Enterprise projects are never a picnic in the park. They are more often a long, hard slog. At difficult points in a project lifecycle, times may be hard for everyone. It is at these crucial points where success is won or lost.

For the most part, perseverance is the key. And the energy for perseverance comes largely from optimism, from the mental calculus we all engage in about whether something is worth our effort based on our impression of its likelihood of success.

You, the Product Owner, are the public persona upon which many of these assessments are based. When things go wrong, nobody likes to move forward. Yet this is precisely the time when leadership is most required. As long as others believe that you believe there is a way, they will follow. You don’t have to have the answers, but you have to insist that the answers exist, that they will be found, and that when they are, effective action will be taking by everyone involved.

5. Know the Narrative

Large projects are like long novels. They have a narrative: a past, a present, and a projected future. As a Product Owner, you are likely to be the only person who knows the whole story.

Development teams are often protected from stakeholders and management for good reason: so they can get their work done with the fewest distractions. At the same time, stakeholders and management have a deep need to know how things are going because they bear the ultimate responsibility for success or failure.

Whether you like it or not, one of the requirements of being a PO is being a storyteller. Not a teller of tall tales, something more like a historian. You are the person who knows the most about where the project has been, where it is now, and where it is headed.

Why is it so important to know the narrative? Two reasons: (1) As I just mentioned, everyone naturally wants to know it and they know that you know it best; but more important than that is the fact that (2) When fortunes shift, people will naturally look to you for your interpretation of events.

I’ve never seen a project that didn’t have it’s low points. I’ve seen teams hit negative velocity because more time was spent in a sprint on tech debt and defects than on features. I’ve seen resources run low and executives run hot. It is at these times that many people feel like giving up or getting away.

And that’s the last thing a struggling project needs.

I have a talk I give called “Great Expectations”. It’s about how most of us start new projects with high hopes even though every project we’ve ever been on has hit rock bottom at one or more points in time. There’s always a moment in the talk where I ask the audience, “What do you do when you don’t know what to do?” Astoundingly, more than half the people say something like, “Start looking for another job.”

This is why we suffer so many colossal failures on enterprise projects: at the very time when we need to pull together, half of us have one foot out the door.

This is the crucial moment when the Product Owner must construct a new narrative for a new outcome. Again, this does not mean diminishing difficulties or spinning circumstances. It means honestly and transparently projecting a way out, a path, a possibility—better yet, two or three because one of them certainly won’t work.

On my last project, we hit the wall three or four times in 18 months. Each time, people thought the project might be cancelled, that we would lose headcount, that teams might be shuffled and responsibilities changed.

Time and again, people asked me about these things in private. They were right. Times were tough. And the easiest thing for me to do would have been to console them and send them to my favorite headhunter.

But that wouldn’t have been right or smart. It wouldn’t have been right because I wouldn’t have been advising my friends based on my belief that we would, indeed, find a way to be successful. And it wouldn’t be smart because encouraging people to jump ship when you really need all hands on deck is almost a form of self-sabotage. Think how you might feel if the most productive engineer on your team left for another job right at the worst time in your project.

Things were really bad at certain times on our project (though we ultimately delivered). Concerns were justified. But panic is never justified—and even if it is, it isn’t helpful. So what did I do?

I offered plausible reassurance based on three things that were part of the project’s narrative: (1) Past history (Did anything bad happen the last time?); (2) Current circumstances (What value would the company see at this point in stopping the project?); and (3) Reasonable forecasts (If we can get through this, doesn’t it seem like there will be a big upside for the company down the road?”)

These were all legitimate and honest ways of responding based on facts and, in the case of future projections, reasonable assumptions that could easily be supported by facts.

It is especially important that you project optimism to your fellow Product Owners because they are keepers of the narrative, too. When times are tough, it’s important that we all stick together. When things seem unstable, people crave stability. Projecting optimism when times are tough is the best way to create the feeling of stability that people need to do their best work even if such stability doesn’t, or can’t, exist.

6. Bestow Respect

I was giving an all-day talk at a conference a while back and I discovered that some of the participants did not understand the circular nature of respect—and that this was getting in the way of their own success and the success of their teams.

One engineer said, “I don’t respect my manager. He makes too many bad decisions.” Another said, “I don’t respect my Scrum Master. His technical knowledge is insufficient.” And so on.

These are unfortunate situations. But they are also common ones. The reason they are so common is that disrespect (which is what these two people were expressing) is a vicious cycle. How likely was it, I asked, that either of the people they did not respect respected them?

Not very likely.

Here’s the vicious cycle part: If we have decided that each of us must earn the respect of the other, then what happens when our success depends on collaboration? Was it possible, I asked the people in the workshop, that the manager and the Scrum Master need your help in order to be successful?

Well, yes, they supposed  it might be.

And you certainly need to be respected in order to be as successful as you can be, right?

Yes, obviously.

So what happens when two parties who depend on each other’s success are waiting impatiently and judgmentally for that success to emerge—while withholding respect on the condition that it emerges?

In this situation, both parties likely fail, respect declines, failure escalates, respect bottoms out completely, and soon, the respect none of us can earn from the other becomes palpable friction that slows our progress to a crawl or halts it altogether because we’re both withholding based on a condition of mutual disrespect in which neither of us can deliver.

Many of us have this notion that respect must be earned. While understandable, and very human, this is a potentially disastrous attitude to take and a toxic culture to take part in.

Respect is bestowed, not earned. I’ll say that again in bigger letters this time: RESPECT IS BESTOWED, NOT EARNED.

Respect must be the default condition. And, in fact, if we truly want to be successful, respect must be a constant because without it, we lose much of the power we have to solve problems collaboratively. And on enterprise projects, most problems need to be solved collaboratively.

This idea about the bestowal of respect, its default nature, and its constancy, is particularly crucial among Product Owners. If POs don’t respect each other, how can they depend on each other to collectively deliver a product? And if they can’t depend on each other because they don’t respect each other, what is the likelihood that they will collaborate to solve hard problems?

And if they don’t collaborate to solve hard problems? You guessed it: ownership declines until, really, no one owns the product because the entire PO group has collectively abdicated its most basic responsibility.

As difficult as it can be at times, maintaining respect for others (and for ourselves, too) is critical to our success. Every member of the PO group on an enterprise project must respect every other member because every other person on the project is looking for leadership from the PO group.

7. Learn From Your Peers

There really is no standard playbook for POs on enterprise projects. There are books, courses, coaches, certifications, etc. And these are helpful. But they tend to focus on the tasks and competencies of Product Ownership as a generic functional role. You need to understand the specifics of your job as it exists within your specific project.

This why it’s so important to learn from each other.

Unlike engineering, which is a relatively mature concept, Product Ownership came into being only in the last decade as Scrum became popular. That means that most POs don’t have a lifetime of experience and wisdom to fall back on.

What became obvious to me on my last project was that there was something I could learn from each of the other Product Owners. One was particularly good with the stakeholder. One was very technical. One was extremely conscientious and always very well prepared. One had a very interesting talent of being able to identify a team problem and express it succinctly in a single sentence.

At this point in time, I know there are master engineers, wise architects, well-tested QA people, and so forth. There are also many standard references for the technical aspects of software development. But nothing like this exist for Product Owners. We are probably still a decade away from having the definitive PO playbook in front of us.

In some sense, we’re all still trying to figure out how best to do our jobs. And the Product Owner’s job changes more with each new project than almost anyone else’s. So even those who have served on several projects over several years may not know everything they need to know on their current project.

Agile software development is all about learning. And in many ways, POs have the most to learn. It’s not that POs lack skill or experience, it’s just the nature of the work that each product a person owns will likely be a new and different experience.

Because the Product Owner role is, by definition, a singular role, Product Owners tend to be individualists. On behalf of stakeholders, they are responsible for holding the vision of the project. But this doesn’t mean they always have a vision of how to be successful in delivering it.

Acknowledge this with your co-POs. Maintain a collective vision of success and muster the courage to achieve it. But move forward together in a spirit of inquiry. Nobody has all the answers. And in many cases, the answers are unknowable until very late in a project. While having more than one Product Owner has its challenges, it also has the big advantage that several heads are usually smarter than one.

8. Leverage Collective Domain Expertise

As the Product Owner, you are required to have or to develop deep expertise in the problem domain of your project. If you’re lucky to enter a project with years of domain experience, that’s great. But it’s hard to have both years of domain experience and years of Product Ownership experience because Product Owners typically don’t spend years working within a single domain.

This means that you must leverage the domain experience of others.

Your first source for domain experience should be the other Product Owners on the team. Instead of competing to see who knows the most about what, cooperate to first discover and then act upon the domain experience distributed across the group. But don’t count on the PO group entirely to know everything that needs to be known.

Stakeholders are, in some sense, experts in their own domain. But here again, different Product Owners will have different experiences of their stakeholders. And in many situations, stakeholders won’t actually know their domain as well as you might hope. Often, people needing something need it for a very simple reason: they’ve never had it because they’ve never been able to define what it is.

Don’t disrespect the domain. Don’t trivialize it. And absolutely do not take for granted that every PO sees the domain the same way you do. Remember that an enterprise project with eight teams has eight POs. Ideally, those eight minds must in some sense function as one. The only way that’s going to happen is if you leverage the collective domain expertise of all POs on the project.

Harmonizing Chaos

With 100 to 150 people working on a project, and eight to twelve people “owning” it, there’s bound to be some chaos in the machine. The best thing a group of Product Owners can do is strive to continually harmonize the different voices on the project, to refine and synthesize all the ideas floating about, to distill the essence of what it is the teams are producing, to find order in chaos, and to communicate all of this clearly and concisely to everyone else on the rest of the project.

Only through carefully considered collective coordination (yes, that’s a quadruple alliteration for a reason: it’s really important) can a group of POs serve their teams, their project, and their stakeholder well.