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


Where New PO’s Are Relocated (The State of Confusion)

Valerie and I started a thread of e-mails the other day. She’s on a big Agile adoption project and we were talking about the challenge of getting many teams up and running quickly.

Valerie is a Scrum Master by nature; I’m a Product Owner. When I say that we are who we are “by nature”, I really mean that. I’ve been “a product guy” on software—and other types of projects—for almost 30 years. Valerie was Scrum Mastering her way through her career long before “Scrum Master” was a title anyone could hold.

So she asked me for a few thoughts on helping new Product Owners come up to speed. What I’ve realized upon reflection is that new Product Owners might benefit from a “Survival Guide” of sorts. So that’s what I’m contributing here, in a series of posts, over the next few weeks.

Here’s Whatcha Gotta Know (Not!)

I thought about sending Valerie a few quick “Here’s whatcha gotta know” tips. Then I got more interested in actually trying to solve the problem of helping new Product Owners get up to speed quickly.

I went back to some of the books I have on Product Ownership. I pondered their wisdom in the context of a large project I worked on recently. From 2011 to 2013, I spent 18 months as a Product Owner on an enterprise application platform and data system. We had about ten teams distributed across three locations, 100+ people, and something like a $75 million budget.

That’s a lot of product to own. I was perfectly happy not to own it all.

The project was something of a trial by fire but I didn’t get too burned along the way. Thanks to the many people with whom I worked, I came out of it with a lot of confidence, much new and very useful knowledge, and what I think is a good sense of what it really means to be an Agile Product Owner, as opposed to all the other product development roles I’ve played throughout my career.

This most recent project was that very rare greenfield work in a domain we care about deeply—a once-in-lifetime opportunity, I thought. It was also rare in that there was no “Agile adoption” phase to go through. We hired for Agile and we started with Agile from the beginning. In particular, all Product Owners were given hardcover copies of Dean Leffingwell’s “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise”—probably the nearest thing that we have in the enterprise world to “ the Bible of large-scale Agile adoption.”


“Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise” is a heavy hardcover book. It’s the “playbook” for the Scaled Agile Framework, or SAFe as it has come to be called, and it goes hand-in-hand with what is now known as “The Big Picture”, a nifty interactive Web-diagram you can find here.

For the discussion that Valerie and I were having, I purchased a copy of the book for my iPad, booted up “The Big Picture” in my browser, and dug in. And I kept on digging. This is not a breezy “book at the beach” sort of read, and for good reason: The list of “Agile software requirements” is not short.

For me, a person who has shipped commercial software products since the late 1980s, who has held management and executive roles related to product development, who has followed Agile with great interest since “The Manifesto” was born, and who has even applied Agile ideas in domains outside of software, I was surprised to find upon reading “Agile Software Requirements” for the first time during my first week on the job that I was seriously knocked off my game.

I spent several hours reading each night after work, and about 10 more hours over the weekend, reading as much of the book as I could. When I couldn’t absorb any more information, I remember the feeling I had all too well. It was like a song playing over and over in my head with lyrics that went something like this:

“Someone just wrote down an inventory of things Product Owners have to do in order to fulfill the Product Owner role. Everything I need in order to know WHAT my job is has been written down here. But I don’t have a lot of information about HOW I’m supposed to do all these things. It’s midnight on Sunday and I am totally freaked out about going to work tomorrow.”

Of course it wasn’t that bad back at the office. But that’s the way I felt the night before. And I felt that way for a several weeks thereafter. Even re-reading the book again just a week ago, in the context of my current discussion with Valerie, I found myself overwhelmed by all the things a Product Owner is supposed to do and to be.

I “Heart” Product

I love product work because I’m at the center of everything. In Agile, I call the Product Ownership function, “Grand Central Station”. All the trains run right through the PO (engineering, QA, Dev Ops, stakeholders, project management, business analysis, executives, other POs on the same project, etc.) and the PO makes sure they aren’t crashing into each other in horrible, costly, and extremely uncomfortable ways.

According to what I’ve read, this requires me to possess high levels of technical knowledge, domain knowledge, stakeholder knowledge, Agile knowledge (of course!), business knowledge, and really, really good communications skills.

I am also the Product OWNER, and that’s not a figurative term. I own the work product that results from my team’s efforts. I don’t own the team, but I own our results. Most important of all, in the context of doing and retaining my job, I represent the work of my team to all other parties and account for it fully at all times, for better or worse, richer and poorer, in sickness and in health—you get the idea.

So two years ago, as I’m heading back to work on that second Monday morning, trying to remind myself how much I love product work, I’ve got another song playing in my head:

“I just read this huge book about what it takes to be a Product Owner and it is telling me that I have a huge number of responsibilities, that I need high levels of expertise in many different and disparate areas, and—oh, by the way—since almost everything I do has a huge human interaction component to it, none of my work is an exact science.”

I have a team of very talented people to work with (two teams as it turned out in the end), supportive management that is “all in” for Agile, and a stakeholder who is demanding but constructive. I have what is arguably one of the definitive books on the subject of my work. Our company arranged for one of the book’s major contributors to coach our project in several multi-day “all hands” sessions.I even got four days of CSPO-like training as well.

But it’s obvious in my first week on the job that my role is vast, and that while I am slowly coming to know what it is, I really don’t know how to do it. Even nine months after leaving the project, I couldn’t tell Valerie HOW I did it. So whaddya know? The books, the courses, and the coaches are right: Product Ownership is not an exact science, not by a long shot. As such, the books, the courses, and the coaches are not where the true answers are to be found. All of these things are helpful to some degree but they are far from sufficient for success.

Keeping Myself Afloat

During my first weeks on the project, I am dog paddling in the deep end, gasping for breath, putting in 10-12 hour days during the week, and logging even more hours at home, learning at night and on the weekends about Agile Product Ownership.

What I get from this effort is two things: (1) A friendly reminder from HR that the hours I’m logging on our internal billing system are way too high; and (2) A difficult “adjustment period” that didn’t seem like an adjustment or a period at all because I didn’t know how to adjust to it and I saw no end in sight for the period I had just entered into.

However—and this is where I had a big insight in talking with Valerie—I ended up doing this work pretty darn well, all things considered. I think I’m a pretty good Product Owner now.

I PO’d for three different teams—two simultaneously for seven really hard months—and served as the project’s overall domain expert. When I left, after the product was released, I received an outpouring of admiration from my peers and three offers of new positions from my CTO. I felt deeply honored by my co-workers, and especially proud of each new job offer I received, but I was leaving to head back home and work with my wife on her business. My decision was a lifestyle change for me, not an expression of dissatisfaction.

So I must have been doing something right. Yet there was literally nothing in the books I read, the coaching I received, or the additional PO-specific training I received that told me how to be a good PO. Always, smart people were telling me WHAT to do. But rarely did anyone show me HOW to do it well.

Curiouser and Curiouser

So the discussion I was having with Valerie made me curious. How did I become a decent Product Owner? I really didn’t know. So that’s why I was up late for a few nights once again this past week, re-reading much of “Agile Software Requirements” and a few other books, drilling into “the big picture”, and taking some notes on my iPad as I went. Each time I read about WHAT I was supposed to do, I reflected on HOW I did it. If it wasn’t in the books, I made a brief note.

I ended up with more than 50 notes.

Apparently, I discovered on my own—with a lot of well-intentioned trial and error, some good help from another Product Owner in the organization, excellents support from a stalwart scrum master, and some very helpful guidance from my CTO—HOW to be a decent Product Owner. But doing that involved putting into practice 50 or more “micro-strategies” to help me do my work, none of which came from coaching, courses, or books.

So Here We Go

With the incredible rise in the number of enterprise Agile adoptions, the number of people who are becoming new Product Owners these days is skyrocketing. These folks are probably all smart, hard working, experienced people. They’ll have books, coaching, and courses just like I did.

And I’ll bet they’re discovering much of what I did, too: that there’s an incredible amount of information available about WHAT a Product Owner’s job is, but not a lot about HOW to do it well. This is what I’m going to address in the next set of posts in this “New Product Owner’s Survival Guide” series.

This is not “official” stuff. It hasn’t been blessed by any major organization or well-known consultancy. You won’t get a certification at the end. Or even the ability to say, “I got advice from a famous person!” because I am in no way famous. This advice is entirely personal to me. And as the saying goes, “Your mileage may vary.”

But I don’t think my experience is that unusual. I think many of us are in the same spot. And I think more and more people are entering that spot every day as enterprise Agile becomes “the next big thing.”

Truth is, I’m using Agile in several different industry sectors right now. Agile is everywhere all of a sudden. And just about everyone is struggling to some degree to get their head around it.

We all have access to coaches, courses, and books. And these are all very valuable. But I don’t think they give us exactly what we need. At least they didn’t give me exactly what I needed, and I had some of the best support resources in the business—plus a very supportive management team encouraging me every step of the way.

I realize, among other things, that most new Product Owners will not be nearly as fortunate as I was to work with such great people under such hospitable circumstances.

I know how much I appreciated all the help I got from the terrific people around me. And talking with Valerie about the major Agile adoption she’s involved with made me think I might have something to give back to others.

So stay tuned in the coming weeks for more of “The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books.”

Steve Peha has split his 30 years or so of work across several industries including software development, writing, education, music production, graphic design, and a few other short-lived but long-valued professional experiences. He has worked for half a dozen software companies and even started one of his own that he was fortunate enough to sell to his publisher and count as a small startup success. Currently, he is working in the Agile world with Amr Elssamadisy on something they have created called “The Culture Engine“, a method for improving workplace culture in Agile organizations, especially those in the midst of enterprise Agile adoptions.

The Team Physical Task Board

I was once introduced to a new team which was been practicing agile techniques for a while.  As I listened in on their planning, it seemed to blend with other meeting purposes and I came away with an overwhelming sense that everyone was busy.  Especially the louder voices – which would find something for a quieter voice to do here and there.  The team talked about hours.  There were some stories entered into the backlog, and the team talked about a few of them.  Then the team seemed to wind down and proceeded to get back to work.  This is the time for opportunity and to bring a few basics to bear.  To be clear – I get a chance to explain what I see, and what we can improve.

A vision for making a better team.

There is a coach, Bob Galen who talks in terms of pebbles, rocks and boulders…  relative sizing.  pebbles might be equated to tasks – rocks were something bigger such as stories and boulders might be epics.  The proverbial agile mountain would be layered with all three.  The scrum master has to know where their team is on that mountain.  They may even have to act as a Sherpa and lead the team to where they need to be at that moment.  Is this poker planning where we talk about stories, is this the next-sprint planning where we are listing tasks? The scrum master’s gold coin is the focus of the team.  Are we self-examining? resource-balancing? How does this fit into processes? Are we making our commitments?

No room at the inn?

The task board is representative of a teams’ sprint.  There are other information radiators which will scale larger for releases across several sprints – but I’m just focused on the teams’ sprint task board here.   Some teams do not get the opportunity to have a ‘room of their own’s as Virginia Woolf  would advocate.  Instead of complaining and letting it fall into the ether – use this an opportunity to get creative and feel a bit empowered at changing the physical environment.  A team that can walk into a room and move tables without asking permission is far more empowered.  The physical environment acting as a parallel to the thought universe.  There hasn’t been a place yet where we couldn’t make one.  The most creative by far was one that wrapped around two side of a gigantic square column that was ideally situated right in the middle of the team.  They just hadn’t thought of it as usable real estate and took a lemon (sour or negative circumstance) and started making it work for them.  Take painters’ tape and a portion of barren wall.  Use the hallway or corridor – this IS supposed to be about visibility after all.  Try a window, or a rolling board, but try something. Dont get stopped.  Some teams use idea paint, and turn a section of wall into something they can write on with dry erase markers.

3 vertical and one horizontal line.    Stories (Rocks) | To Do (pebbles) | Doing  | Done

The scrum master helps the team spend time together – working and non working. There is much about a board like this that the scrum master takes note of.  Capacity: What is the team’s average velocity at the story-level, and quite possibly how much is being done at one time (task level).  The manner in which it gets done is also telling.  Is the team working highest priority, and swarming as they need to?  Is the team likely to delaminate and each starts their own story?  When did risk surface from the team?  This should be early on and not the day before the end of the sprint. I have my task(s), is it the best thing to be doing right now? Does it contribute to the story?  Does it help the release?  Does someone need help? Large tasks that sit in ‘doing’ all sprint aren’t helpful.  It means we haven’t performed our agile duty and broken it down into something smaller and actionable.  Quick feedback loops.  Are we all on the same page with regards to the end deliverable fairly early into the sprint or are we still thrashing late in the game? Are we improving our interaction? Is the team getting better suggestions from each other and evolving processes and quality of work?

Visibly working and communicating the sprint plan every day in a light touch is important.  Also – Is the plan working? The sprint burn down is a side-effect.  We don’t complete tasks to make the burn down look better – we complete tasks to get the work to done.  The burn down is simply a reminder like a gas gauge – do we seem to have capacity as a team – if not then we need to adjust the plan.  As a scrum master knowing the records for most amount of tasks they’ve ever completed in a day is an achievement worth celebrating.  It gets the team to think as a cohesive group for what they are capable of.  I had an earlier post: Burning Down Not Out

Finding out the the team is experienced and knowledgeable enough to task and tear all the work apart.  Were there any skills or processes or artifacts that would have made the sprint easier?  The scrum master is out to enable the team and remove issues.  This may even take some time to do so.  With enough attention, perseverance and work oysters turn an irritant into a pearl.  The scrum master can even look back on the sprint task board and see how many new tasks were added.   – This is the team learning about what it takes to get everything through the organization and into the customer’s hands.   Always with an emphasis on making the customer delight and re-engage with the experience of how we collaborate and what we deliver.  Some teams may need to call out the preparation for the review as a task for completing a story.  We always want this to be light weight and not overly prepared – more go than show, but some conversation and preparation contribute to a successful review.

We have a plan, and the team has confidence enough that together we can adjust and deliver the work.  What is the team’s confidence in their own plan? Are they engaged and an active part of it or really just waiting around because they know it is doomed to fail.   At the end of the sprint, our plan is pretty much thrown away and the team is left with feedback for how well we problem solved, and worked together to accomplish all of this.  The teams are earning trust by working on high priorities for the business.

Color coding by stickers or by post it’s is often used to convey stage of tasks, if the tasks were added after planning, who might be responsible for a task, or even priorities.  Getting used to Capturing the conversations IN THE MOMENT is an art in and of itself.  It is the lightest weight meeting.  No one leaves with extra cleanup up to do.

Moving a story to Done.

Though tasks are moved by the team – the person doing the work, Teams often like stories moved to done as a ceremony by the product owner.  It conveys they have reviewed and accepted the work.  The product owner should not be surprised by what they see in a review.  The scrum master often acts as a conscious for the team and may probe for definition of done compliance. Especially if this sprint was a new level-up in terms of delivering to the expectations of the organization, role, or the team itself.  “Did we have unit tests completed?”   The team will thoughtfully answer, and we trust them.  Questions should never provoke a team into a defensive posture.  If they do – this is a signal that something else usually requires a bit more investigation and fixing.  Physically touching the work isn’t just an arts an crafts thing – it hits us visually, we feel it, tactile.  This is representing our work that we move with progress from left to right.  It is a visual indicator which radiates information about where the team is at and heading towards.  Within the context of the group – we accept we will make our work visible.  The team talks during the stand-up around the physical board.  Others from outside the team are even invited – but usually don’t speak until after the team is done. You might even judge a successful stand up by the number of break outs that happen AFTERWARDS.   As a team we are also endorsing accountability.  There are some strong proponents for ‘HOLD ACCOUNTABLE’ but I will often say “HELP ACCOUNTABLE”.  Not everyone is good at asking for help, or seeing a possible solution because we are heads down in activity.  Together we rely on each other as a team, and strive to balance in doing the right thing the right way.  No one is perfect every day.  The group together helps, picks up members who might be down, and gets motivated about completing the team goals.  Ever continuously improving to work better and together.

The More Mature Teams

I am looking for everyone in the team to participate.  Problem solving what is needed to get the work done.  This critical thinking is an opportunity to teach and visibly vet what is needed.  It also ends up being a plan for the team.  The team will adjust the plan as it needs to.  This is about driving out risk and unknown.  Teaching the team to be better and better with reliably representing their capability to the organization. Making commitments to the business and customers.    Load balancing the team resources, thinking ahead and envisioning the end game at a couple different levels.  Does this align with our goals for the sprint?> How about our larger goals for the release?  Are there any dependencies we need to address early? Is everyone stepping forward appropriately? Is there some swarming behavior?  Are we focused on the tasks that get the stories to done or are we instead focused on hours which really obscure whether something is simply done.  If you have all that and are a great team, and want to move to electronic forms of tasking, then do so with blessing.  Go faster, improve processes.  Just bring with you the practiced behaviors that you developed together as a team.  Distributed teams rely heavily on this to keep connected. I look for a team to pop – their communication includes each other, their plans for the day are intertwined.  There is a great side effect of having teams like this in every organization.  It is force enough to move mountains.

Scrum Master Series: Team Maturity

There is no doubt that a scrum master’s role is seen as a leader.  A leader should also be prepared to adjust their leadership style to provide what the group may be missing.  This would compliment the team.  Other times the team might be best served by capitalizing on their strengths and instead augment them.  Yes, there may also be times when the team is so empowered that for a short while they may be almost invisible; sharing the leadership with others. A scrum master might consider being lenient with some processes in the cases where the team is showing respect for the agile principals.

A Scrum master will grow a team.  Keep the team and the organization continuously improving.  The ability to identify where a team is in its maturity will help.  To be clear, a team’s maturity has little to do with the time spent together and is more about the characteristics of the team.  How do they interact?  How well do they tackle some fairly thought-intensive work?

Bruce Tuckman described 5 phases to team formation.  All these phases required common tasks or goals for the team to align with. While the product owner’s abilities lay in the analysis of unfolding information; the scrum master’s job is to facilitate the team’s transition through towards becoming more mature, shaping the interaction.


Here the scrum master is a trainer.  This group of individuals may be seeking acceptance and may feel relatively uninformed.  Being more directive while members of the team seek acceptance and start orienting themselves.


Still as a trainer, the team may be expressing some dissatisfaction as they test limits and boundaries.  Many different ideas are competing as they form acceptable leadership behaviors.  How the team deals with conflict will stop them or help them move onward.  Does the team focus on minutia or avoid real issues?  How is time spent?


Now as a coach, the scrum master is helping the team integrate with one another. The team has a goal and a mutually derived plan.  Some of the team members may have to acknowledge and help champion an idea that was someone else’s or perhaps even contrary to their own. All done towards achieving the group goal.


Now as a Mentor, the scrum master is seeing the team produce.  The team has a rhythm and perhaps even a swagger as they operate smoothly and are able to problem solve effectively without much conflict.  There is a high trust among the team members.


Things with beginnings also have an end.  Having closure, ending, celebration, recognition and reflection are all part of this cycle.  If the team delivered, celebrate and recognize the team for the win!  Not every ending is ideal however.  Say that a team has worked 6 months to deliver a product, has a sustainable pace AND met their deadline but the product is never put to market by the company.  There is no closure to the goals that have been the vision of the team for so long.  Motivation will certainly be affected.  It might take a while to get going again.  So too the loss of a team member… even one lost to promotion.  Keep visibility and an openness as teams deliver or maybe even wind down projects, deprecate portfolios, and assign applications to obsolescence.

Being an eternal peacemaker within the team might even inhibit a team advancing from norming to performing.  The largest caveat here is that the journey is not always a linear one.  The team can revert or be thrown into ANY of the stages for a time.  Maybe a new member has been added, or a particular stressor has the team acting differently.

Another way to look at a team’s maturity is to gauge the capability and characteristics.  Every team has it’s own unique identity, and watching an agile team work is  organizational behavior.

12 Criteria for measuring the maturity of a team

  • Feedback Mechanisms (poor -> excellent)  Does the team adapt? How long does it take to adjust?  Does it revert to a defensive posture when questioned or is it more reflective and thoughtfull? Does the team possess and agile mindset where they exhibit iterative, time-boxed and incremental improvement?
  • Decision Making Methods (dysfunctional -> functional)  This is bad when a head is locked up in a little view or single perspective.
  • Group Loyalty / Cohesion (low -> high)
  • Processes and Tools (inflexible ->very flexible)
  • Use of Member resources (poor -> excellent) Does the team exhibit swarming behavior? Is everyone efficient and effective?  Are we challenged and utilized?
  • Communications (unclear -> clear)  Does the team talk? Can I hear them? Does the team participate and help inform the organization? Are they visible with information radiators that are up to date and aligned?
  • Goals (unclear -> clear) The Product Owner will answer what is next, while the team will be able to explain their vision, how we will get there, and how we will know if we are there yet.
  • Problem-Solving Ability (simple -> complex)  Does the team stall out when presented with a challenge or do they forge ahead?  Are the solutions brittle or robust?
  • Participation in Leadership (low -> high) Is the team engaging, challenging and growing the organization around them.  Great teams have and influence others and benefit those around them.  What about outside the organization and in the community?
  • Acceptance of minority views (low -> high) are the quiet ones considered or even invited to speak?  Is is just one person’s opinion again and again? What about all the different perspectives that might use or even abuse this product?
  • Standards (low -> high) Is the quality of work high?  Are there defects or rework that make others avoid this team?  Is this team’s work readily accepted and meet a definition of done that sets a new level of expectation.

Just remember that where your team(s) might be,– is just the start of where they might go.

Scrum Master Series: The Team

Definitions and Back to Basics

Once in awhile I get to look back over some of the notes I put together on topics.    I think about organizations, teams and roles that we have.  Once in a while I have to lay the justification to an organization for one of the roles.  A scrum master included.  For a few people in the organization, as I take them through their valley of disbelief, I like to start very simply, and sometime include some history lessons along the way.  Dr. Winston Rice, the father of waterfall wasn’t all bad, but over time we learned to organize ourselves in even better ways.  New ideas in an organization that is pretty big and set in its ways is never easy, but I love watching the transformation.  I have the patience to see the changes and continue to grow and support the people who are experiencing it as well.

I had a developer say to me that they hated agile.  A very clear and aggressive message with an emotional anchor.  All pre-formed before I even got to know this individual or what his prior experiences were.  I love what I do, and it shows.

It’s not about you.

Organizations are dedicated to using teams.  This means what?   A team is a group of people… pretty basic.  But wait, there is more!

  • Holding themselves collectively accountable
  • For using complimentary skills
  • To achieve a common purpose

Scrum does not assume a minimal skill set.  There is also an assumption that the work is complex enough to warrant a team. Ralph Douglas Stacey who spent a career analyzing organizational relationships had a Matrix which might be adapted to agile as follows…Stacey Matrix

Scrum tends to play really well in breaking things up from chaos and pulling them down into the complex realm, and again pulling complex solutions down into the complicated.  Scrum for it’s simplicity cuts through the noise.  Kanban tends to work really well with simple or repetitive solutions we find ourselves performing again and down into the complicated.

Why a team?

Well, it has the tendency to be good for people.

  • Improves our creativity
  • Can make better decisions
  • Can increase commitments to action
  • Help control their members
  • Helps offset large organization sizes
  • Types
    • Formal vs Informal
    • Temporary vs Long Term

In groups of a certain size we no longer feel lost amidst a very large organization.  Daniel Goleman who wrote Social Intelligence was curious about the maximum number of people to exhibit innovation in groups.  What he saw was natural pairing in groups of 2 then 4 and somewhere greater than 8 the groups tended to fracture and not be as cohesive.  Greater than 8 we don’t collaborate as well.  Seems right in line with what individual scrum teams are used to.

What can Teams Do?

It does seems obvious that we use them to develop software.  Our teams place an emphasis on making or doing things.  Team might also exist to recommend or just run things as well.   I get into teams more and more in the coming weeks as this is really where the scrum master matters most.  The team might be considered the scrum master’s product.

I will end with some immediate Dangers to a team.  Again this is always tricky with people who can have selective hearing. As a basis for evaluation in order to really make decisions with steps towards getting better, there are several terms which apply to groups becoming dysfunctional.

Dangers to a Team:

  • Social Loafing – complacency.  It is GREAT to have fun (There is an awful lots of stress and hard work)  but this points more to appropriateness within the context of accomplishment
  • Group think – the team actually loses its ability to think critically and is making decision from a defensive posture within the organizational hierarchy.
  • Social Facilitation – behaviors that start to become acceptable in front of others.  Teasing and hazing are such examples.
  • Personality Conflicts
    • Antagonizing relationships
    • jeopardize team accomplishments
  • Disruptive Behavior
    • Interrupts the group’s processes
    • Limits the teams effectiveness
    • Impacts the team’s cohesiveness

I have never called out an individual as being an impediment, as I tend to distinguish and separate behavior from a person.  There are certainly some behaviors I don’t care for and wont be helpful to a team.  One of the ways to focus on the good part of being within a team is to call out your working agreements.  Together as a team establish some guiding principles of your own.  There are quite a few examples and it has the tendency to put everyone on the same foot forward as they will come together against some tough thought problems.

Test Driven Developement

TDD, ATDD, BDD… were all pretty much alphabet soup.
These acronyms were flung around with the accusatory context that they weren’t being done.  People actually started developing ADD 🙂
Test Driven Development, Acceptance Test Driven Development, even  Behavior Driven Development.  I’ll cover some of the TDD aspects today.
I never liked coming in saying nothing was being done.  Maybe it’s just my style, but if a child is learning how to walk – it doesn’t do much good to simply yell “right foot – no, NO, you’re doing it all wrong”.   Instead it is far more effective to stand beside them, share in the moment with encouragement and recognize their wins.  Capitalize and keep moving with small improvements to become better and sustainable.

 In teaching TDD – there are just the three steps –

1) create a small test.
2) create the code to pass it.
3) Refactor the code/test.
This works at the unit-test level, the test case/functional level, even an automation level.  Is this all you need?  of course not.
But starting somewhere means something actionable and not just a complaint hanging in the air over a team to be lost in the nether.
I liked the many levels of insight and wisdom that Kent Beck had in his book (below) on why we want to do it this way.
Write the test first.
We are breaking it up into smaller pieces…. If the test is hard to write – then maybe the architecture should change.
we converge on the expectation. The test once created is run and expected to fail.
we know what it takes to pass.
we are not afraid of seeing an expected failure.. we learn to explore them. fix them
Write the code to pass.
We refactor if needed.
Get rid of duplicate code.
We have had a small success.. easier to move on AND we learned something.
We move on to the next small test.  If the test doesn’t pass then there isn’t much required in order to get it working again.
Also called ‘moving to the green’. – (red would be fail)
I also like a three pronged approach.  Coming at any problem from multiple, supporting lines of attack, usually assures a solution.

1) Just don’t throw a book at someone – help them to practice it.

There are some really good books and depending upon the level of the tester or developer.  I liked the Wesley Signature series.

There is no problem making the topic a book club, lunch-n-learn or a topic at the Community of Practice.  In stressing actionable, try actually suggestions from the team on where/when to DO it. Emphasize the action and not the complaint.  Perhaps it depends how receptive everyone is IF we are breaking bad habits, right? Don’t look back at all the legacy code.  Start today and move forward.  Today’s features and Today’s backlog items.  Time spent converting is not always fruitful.  To convert legacy code you may actually be trying to replicate bad architecture, and none of which gets you to the features your customers may want today. If you have a story that takes you into legacy land – that is the time to improve it.  Bring it up to our definition and expectations for done in alignment with backlog priorities.


(this should be number 1) right?)  For instance – Are the testers having a whiteboard at the beginning of the story on how it will be tested so that developers are on the same convergent expectation for what being done will look like.  Are there overlapping or redundant areas of test coverage between what we will do for unit and functional tests?  Are tests finished before the code – and code will get them to pass? Is anybody waiting? (a bad sign – there is always something that needs to be done or could be improved)  Can test automation be useful is creating example data in a developers environment so they can run and see the tests pass themselves? Can test automation created to prevent the excessively long hardening periods our organization has? Here we have code, test cases, test automation all developed at the same time. The proverbial vertical slice that is focused on delivering the story.  Do teams still put in unit tests as an afterthought?… the coverage is there, just not the correct sequence. Develop the unit tests first and watch their impact on how the architecture emerges.  Something very difficult to pass should tell us something.  By the way, consider using the unit tests for integration points and not always just trying for coverage.  Also accept that 100% coverage is very difficult and while the teams balances appropriately, list how you will cover exceptions.

3)Keep it simple but improving

What do the teams have today that we can leverage and improve.  Are we re-using tests, unit tests, code example libraries, test cases or test automation? Are we creating a thousand point and click here… or did we need just a few of those ‘beginner/training/ cases and most require some knowledge of the system and hit the bias paths and main workflows?  We are considering tactics and strategies on how to test the work. Without making the test harness a product itself (unless that IS your product … Selenium, Cucumber, etc.)  Testing augments the quality of the product the customer gets. The working deliverable is created more efficiently, making the team agile and faster in delivering it.
Celebrate the leaders, early adopters and achievements with recognition.  Scrum masters might even ask the team if they completed the tests first.   Think of easy metrics to make efforts visible and that point to improvement. There may be signs in velocity, type of work, fewer bugs and hotfixes… etc.  Lines of code usually decreases because quality is higher.
As ever, stay agile.

Empowerment Quiz

“Do you feel empowered?”

This is a question a scrum master may look for and even ask directly of an individual or a team.  The emphasis is usually on the teams as a group feeling able to go out and change the world.  There is something very active here.  Solutions don’t always find their way to you as you sit back… you actively have to seek them out and influence their outcome.  There are many types of POWER…  In 1959 an article by French and Raven pointed to types of power between people being based on:

  • Coercion
  • Experience and Expertise
  • Being guarded about Information
  • Legitimate role or position
  • Referent or acceptance seeking
  • The ability to grant Reward

Yet the best way to think of a definition of power is simply the ability to influence.  Can you truly influence a person, solution, process…?  In some areas we have more ability to affect whatever is before us.  In standing back and self-examining at an individual, team, or organizational level, I might ask many questions.  Each of which might be answered yes or no and support or detract from a perceived influence and being truly empowered.  What are some of the questions that resonate with you?

Here are a mix of 50 questions that might come to mind:

  • Can you purchase a tool or software package to try it out?
  • Do you have the ability to purchase a book or have access to e-books with relevant topics.
  • Did you learn something new this past week?
  • Do you feel your opinion is heard?
  • Is your suggestion or question being constantly interrupted before you finish?
  • Can you try a new process?
  • Do you find yourself actually holding back from making comments?
  • Is everyone on the team participating? … Or is it the same one or two people on the team who get heard?
  • Can we move the furniture, put up information radiators on the walls and generally change the physical environment? 
  • Did you feel productive?
  • Was the customer proud of the teams solution?
  • Were you making suggestions that improved how the team worked together or even solved a particular problem?
  • Do you feel that your co-workers are constantly criticizing everything?
  • Did you contribute to something in the agile community outside of the organization or team?
  • Are you able to teach others in the organization?
  • Does management ever attend any of the team stand-ups and is interested in what the team is doing?
  • Does it feel as if you aren’t trusted to do your job?
  • Did you see something that made you think “wow” or “yes!” the past week?
  • Are you proud of your contributions? your team? your organization?
  • I’m worried about what others will think?
  • Are you working on the same thing that you worked on last month? -in the same way?
  • Do you feel the organization recognized you?
  • Was the team rewarded for its accomplishments?
  • Was most of my time was wasted today?
  • Why am I always thinking I am not very good at this?
  • Is it easy to walk over to another part of the organization and enlist their help?
  • Am I isolated?
  • Does the organization continuously seek outside for best practices and know why?
  • Did my team offer to help or include another part of the organization?
  • Is the customer excited about the software and collaborates often?
  • Do I feel burned out and that the pace is unsustainable?
  • Do I think we are working on the wrong things?
  • If you ask for something, how likely are you to actually get it?
  • Do you feel as if you are growing and gaining experience?
  • Did you have the opportunity to be creative or innovative in some way?
  • Does your manager regularly set aside time for you?
  • Are you an active part of the solution?
  • Do you remember the last time you laughed?
  • Does the team interaction seem forced and awkward yet?
  • Do most tasks feel like a check box?
  • Did I thank someone recently for something that really helped me out?
  • Do I feel supported in my role by a couple different people?
  • Can I truly look back over the past few months and see how much more agile and improved we are today?
  • Are we making more work than we are delivering?
  • Am I able to repeat and understand what our current vision is and the goals which align to them?
  • Do I constantly receive or seek feedback from people?
  • Can I walk into a meeting room or office when the door is closed? …And I’m not on the invite list?
  • Can I say that my team ROCKS?
  • Am I focused and really want this to be the best solution for the customer?
  • Is this the best team I have ever worked with?

 … And as with any super hero/heroine – use your powers for good!

0, 1 or Many…

In uncovering better ways to solve problems, we often examine how we think. Sometimes we are even ‘too close to the experiment’  to realize that we might have missed something small or large just outside of the current scope of our attention.  It is part of the implicit trust that we, as part of team, not only seek feedback, we consider it from everywhere in order to get at the best solutions.  In the case where a third party is being talked about in absentia, I usually like to circle back to the person who was not present.

   1) It’s much more fun to involve the person about whom you are speaking. What can I say? It’s the coach in me.
   2) Whether it was good or bad, this is the same reason.  It’s feedback, simple as that.
3) When it’s praise, this is reinforcement and recognition. When critical, then it’s alignment, impact, adjustment.

The critical conversations tend to be learning times for the both of us.  There is also a series of books out there about having these crucial conversations.  It is a chance for me to learn and individual’s thinking, reasoning, motivation, and not only how they communicate but how they interpret as well.  Sharing feedback builds trust, and in larger contexts of the teams or program, brings the perception into reality and better measure the impact. Collaboration, Communication, Convergence – none of this happens without trust.

The best job on the planet is one where we can get paid by contributing both productively and creatively; while learning and growing.  The productive means not only in time, but that the solution is usefulmeaningful.  To be creative means that I can bring something of myself, something reflective, thought provoking, unique.  Any learning augments our contributions.  

Zero, One or Many…

Some one had his code patterns all figured out. Zero, One or Many he would say.  This method will interact with exactly none, one or many objects.  As thought provoking as that is for a moment.  The thinking stopped; and it is only a matter of time before the criticism of the product of that thinking will set in.  How about code quality – what about the undefined or indeterminate?  We should have error handling for bias path escapes.  What about ‘Many’ and the sense of scale?  Typically many would mean everything.  The code would show it’s inflexibility when we needed to SCALE.  Inclusive, exclusive, sets, limits and constraints all prove that there can be priorities when processing everything.  Even security attacks exploited this with Denial of Service distractions to limited resources. The questions became different, could we limit to the first 1,000 in order to save valuable computing resources? How fast can we change to correct or improve our code?…  Conway’s Law postulated that the code reflected the social structure of the organization.  He could see it.  Being a product of our thinking, it will reflect how rigid, or how flexible our minds are.  Communication (thought interface) affects and is affected by our organization every day. How flexible, how agile will we become and how long before that shows up in our solutions?

I heard a coach once tell me of his proudest moment.  His son came home from grade school and started in on his homework.  He said, “You know Dad, everyone at school is always telling me WHAT to think.  You taught me HOW to think”.

The Emphasis on the Impediment

I got into a conversation with a coach once about something which had blocked progress.  We usually call these impediments and the goal is to make them visible, and go after them to remove them from being such a problem.  I wound up considering a few things along the way.  Even though this particular problem was already resolved, the emphasis from the coach still fixated on the problem and the problems it caused.  Though we retain this as experience, it still caused some emotion for this particular person.  I tend to emphasize the solution and action of the solving.  Since time immemorial history favors the conqueror or problem solvers, the tactics used to overcome obstacles.  The obstacles themselves are temporary.   The labors of Hercules, Alexander’s Gordian knot, Alan Turing and the Enigma Machine, Rutan’s White Knight and SpaceShipOne winning the X prize…

Can you go around, over, under it, or iterate through time?

Ender’s Game has a zero gravity room in which there really is no up or down – just an orientation around where the problems are.  Kids are left to explore that context and find different ways of getting around.  Context and situations, call for different strategies and tactics.  Exercises like brain storming, or using the five whys are now often intermixed with daily activities instead of separate and distinct activities with the teams.  We are developing individual and team skill sets as we don’t just ‘go get there‘ but instead ‘grow to get there’.  We can never go fast enough, we are never truly ready, just perhaps we are ‘ready enough’ with the resolve to continuously improve.

Why so much focus on the problem and then simply walk away?

There is a bystander effect which can indicate the cohesiveness of the group.  Many simply find it easier to by remaining a critic.  In the critic’s voice you get to be part of an elite group that establishes a hierarchy over some other group.  Active participation, suggestions and alternate solutions are far more preferable.  The best teachers share. The behavior to get ramped up and even show emotional venting doesn’t strike me as productive and often hurts the situation.  Switching over to better adaptive behaviors to solve problems should be emphasized. Have the calm and experienced understanding to move through it with a state of grace.  Teams should be problem solvers, the best solutions do not come from being defensive, panicked or fearful. They come instead from drive, passion, creativity, inquisitiveness… If you want to continue to foster this in your environment, then some recognition and reward is also important.

Can a person be an impediment?

I have always separated a person from their behavior.  I like people! There are some behaviors I don’t care for. I don’t list a person as an impediment. It’s too easy of a stereotype and doesn’t tend to solve the problems we are having. Selecting a scape goat or  blame and then walking away is not helpful.  Role assignment, support, responsibility,  processes, visibility, convergent expectations, aligned goals all are things that might help.  Things we can TRY, and still continue to move forward.  A person however can solve the problem, a team even more so. Very often techniques like the five whys left us in silence where there was no longer deeper knowledge to draw from.  It is often hard to bring a context you have never experienced as a possible solution.  We speed up this process of extrapolating solutions from experience by communicating ideas in a group and sharing that richer set of contexts for the entire team to draw upon.  We even communicate in abstract development patterns and have some pretty common ones.  Sometimes we bring in architects, subject matter experts or coaches depending upon where the impediment exists.

In the movie Ender’s Game, Ender winds up with someone on the team who steps forward and tells Ender he doesn’t even know why he is there. The two boys don’t even like each other.  Ender’s reply is that he is there to make the team better and responds with his own question – Is he wrong?

WANTED: Environmentalists

Description:  The Corporate Environmentalist will work tirelessly to ensure the organizations environment is one that allows a new culture to emerge.  Additionally, this person will strive to make is safe for teams and individuals to realize their maximum potential through learning, disagreeing, experimenting and communicating openly and honestly both inside and outside their teams.  The environmentalist will create an environment which:

  • Encourages simplicity
  • Is intolerant of waste – all kinds of waste (time, tools, process)
  • Models the behaviors they would like to see in their environment
  • Challenges the status quo – banishes the phrase “It is what it is”
  • Rewards improvements – individually and organizationally
  • Respects every person and part of the environment as they all help maintain the balance of the ecosystem
  • Inspires others 
  • Enables everything in the environment to be as awesome as possible

I believe an environment is separate from culture but neither can exist nor be healthy without the other.  Perhaps it’s a bit chicken and egg but, there it is.  Culture emerges as a result of an environment.  If an environment isn’t one that encourages, fosters and expects open and honest communication the resultant culture will likely be “CYA”.  A real world example is a large project has been running along for well over a year.  All possible resources are working on it and it’s mission-critical for the business.  For months, the project has been reporting “Green” and everything is on track for delivery.  All of the sudden, one month from launch. WHAM! It’s RED with no hope of delivering.  Why wasn’t this known beforehand?  The environment.  It’s not OK for projects to be yellow or red.  Everything must appear to be in hand – even when it isn’t.  If you do have a problem, it’s not OK to signal it without corresponding solutions and options for stakeholder consideration.  Also, please make sure the problems don’t point at all to systemic issues of an organization like, too many projects in progress, people over-allocated across too many efforts or technical development constraints that don’t  support what it is you’re trying to do.  No…..rather, it should be due to missed dependencies, departments like business and/or IT not doing what they said they were going to do or ineffective project management.

Sound familiar?  Again, I find myself writing about issues organizations actually have whether or not Agile is something they’re trying to adopt.  In order to avoid situations like the one I describe above, the environment is the key.  I hear people say it’s the culture but the culture of an organization is a direct reflection of the environment people work in.  Again, Agile or no, the leaders of an organization are the ones who create the environment.  Why?  Because they’re the ones who associates look to set expectations, model behaviors and support (or not) the people operating IN the environment.  

If the environment isn’t supporting the ability to deliver value, faster, cheaper and higher quality today it will not support it later either.  So, before demanding, mandating or expecting different results, an honest assessment of the environment is in order.

  1. What makes it difficult for people to get work done today?  Too many meetings, too many projects, too few people, too much documentation? WHY are we doing those things today?  How, if at all, do any of those things add value?  How do those components enable or not your efficacy with regards to getting work done? How can you simplify? What needs to be true of the environment to support simplification?
  2. What behaviors would you LIKE to see in your environment?  How does your current environment support – OR NOT – those behaviors?  What needs to be true of the environment to support and encourage the desired behaviors and allow what’s already good to expand?
  3. What role are you willing to play in the environment?  If the answer is “none” or “whatever my manager says I need to” you’re not an environmentalist yet and probably, won’t do much in the way of creating one other than mucking it up more.  What needs to be true of the corporate environmentalist?

Funnily enough, it’s pretty straight-forward and comes directly from the “High Performance Tree” developed by Lyssa Adkins.  A corporate environmentalist needs to be:

  • Committed – To constantly improving the environment.  This means hearing the good, bad and ugly and not getting defensive or dismissive.
  • Open – To hearing things objectively and trying things that didn’t originate with you.
  • Courageous – Going boldly where others have been afraid to go and walking the walk so others can too.
  • Focus – Not on the day to day but, the bigger picture.  Warning!  You must first have an understanding of the day to day.
  • Respect – For the people and parts that make up the environment today.  Bulldozers and rain forests don’t go together.  Your ecosystem will be fragile for a bit…

If you’re a leader, and happen to be reading this, conduct a self-assessment first using the dimensions of the high-performance tree.  If you find yourself lacking, do some soul searching as to why that might be and seek to learn how to improve and change.  Start with you, then move beyond into the environment.  It’s not something that will happen overnight and none of it will be easy but, I’m telling you, it will be totally worth it.

Why I Do What I Do and LOVE Every.Single.Minute of it

Not too long ago I took a 2 day class on personal presence.  It was an incredibly good use of time and I highly recommend it.  It’s taught by actors – real ones – and they work with you to learn how to make an impact with your presence.  It’s about knowing, when you get up to speak, what your passionate purpose is and “setting” the stage to maximize the efficacy of your message.  However, the very best tool I took away from the two days was an understanding of my “personal elevator pitch”.  In short, you had to create a summary about yourself that would convey to others, in plain non-corporate speak, what you’re about.  I had a very difficult time with this particular exercise and was fortunate to have a co-worker help me work my way through it.  Here’s the gist of the “elevator pitch”:

I’m a composer NOT a conductor.  I can hear, in my head, how amazing a piece of music will sound.  I understand how all the instruments work together.  I work with each section of the orchestra to learn their part and help them understand how it fits into full piece of music.  And, when the pieces come together to create something amazing, I’m in the very back row to appreciate the brilliance each musician, each instrument and the full orchestra brought to the performance and celebrate their achievement as a team.  I take pride in seeing them work together and experience what I heard in my head.  Once complete, I slip out the back and begin to think about the next piece of music.  

I do what I do because I love it.  I love the people I get to meet.  I love the challenges I get to work through.  I love the learning I experience every day. And, more than anything else, I love seeing the amazing things that happen when people begin working together well and finding ways to be even better.  I also love that what I do isn’t immediately obvious to anyone.  When awesome things happen – it’s not me that made them happen – it’s the team of people I was fortunate enough to work with.  It’s THEIR accomplishment and that’s what I love the most.