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

grand-central-station-impasto-vignette

Welcome to Grand Central Station

I began making products way back in the Pre-Agile-ite Era in the History of Software Development—roughly the mid-1980s to the mid-1990s. I realized early on that what I enjoyed most was being in the middle of it all, working with developers, designers, marketing, management, end users—the list never ended and I liked that a lot.

In the bright shiny world of contemporary Agile software development, being a Product Owner is even better in this regard because “the middle of it all” is more precisely defined. There are fewer turf wars to fight; everyone knows (or should know) why you’re in a particular meeting asking particular questions.

My last project was the biggest I have ever been on (100+ people, $75 million budget, 18 months to v1.0). I had what I now think of as “the full-on enterprise Agile experience”. I was in the middle of it all and there was a lot more “all” than I had ever been in the middle of before. I felt like I was going to work every day at Grand Central Station.

A Metaphor

Grand Central Station is where everybody goes to get from where they are to where they need to be. The Product Owner is the person everyone goes to to get the product from where it is to where it needs to be. Waves of humanity flow constantly through the Product Owner just as they might flow through a person standing in the middle of Grand Central Station at rush hour. The trick is not to control the flow but to know the flow and direct the flow with as little friction as possible so that everything ends up at its appointed destination.

Product ownership is a game of expectations: When will it ship? What resources are required? How do we know that our idea of MVP will be our users’ idea of MVP?. But it’s not about expectations management. It’s not “under promise and over deliver”. It’s “answer questions and tell the truth.” Why is truth-telling better than expectations management? Because expectations management is dishonest by definition.

At some point your dishonesty will be exposed and you will lose the trust and support you need to be successful. The worst thing that can happen if you tell the truth is that some people may not like the truth when you tell it to them. But telling people that their train has been delayed and will arrive an hour late is far better than allowing them to believe it is arriving on time and dealing with every story they make up about you when it doesn’t.

Another Metaphor?

There’s a view of Product Ownership as “running the show”: You are not conducting trains, you are the conductor of The Software Development Symphony Orchestra. Your backlog is the score. Your stories cue the players. You face the music when it comes to stakeholder and management interactions.

This is a valid take on the PO role. But it’s not one I like because the POs I’ve seen who work this way tend to be more competitive than collaborative. The “PO as Conductor” metaphor smells to me of ego and eccentricity, of command and control. It tends to set the PO above and apart from the project, just as the conductor of an orchestra stands on a platform above and apart from the players.

Any time you think you’re in charge of anything, think again. You’re the Product Owner, not the Product President, Commander and Chief of the Armed Product Forces, or master of the Bully Product Pulpit. To me, this “commanding” or “conducting” way of thinking is bad for relationships. And relationships are the currency of successful Product Ownership.

Relationships or Transactions?

It’s tempting to view your work as a huge series of transactions: taking stories to the team, getting requirements from the stakeholder, accepting stories from engineers, giving sprint demos, and so on—each has a built-in quid pro quo, simple trade of services from provider to provider: you do your job, everyone does theirs, we all go home happy. This is the fantasyland view of Product Ownership that you’ll often find in books and courses.

Real life, as we all know, is a bit more complicated. It’s tempting to see the work of Product Ownership as simply trading quid for quo all the time and not worrying too much about who you’re trading with. Everything’s a transaction, nothing’s personal; it’s cut and dried, black and white, professional, reasonable, rational—no emotional labor required.

Sounds perfect, right? But it’s not. The truth of transactional product ownership is that all transactions are not created equal; some are harder than others, and others are simply impossible.

In the quid pro quo approach, there are going to be times when you don’t have the quid to trade for the quo. There are times when there are no consumers for what you are trying to sell (a new stakeholder-demanded feature, a new goal from management) and no providers of what you would like to buy (a little more time, budget, or even just an extra dev server). In these situations, transactions cannot go through.

This is when projects—and sometimes careers—grind to a halt. Need a favor from someone? Can’t get it. Need the stakeholder to see reason? Not gonna happen. Need management to back off? Fuhgedaboutit.

In a transactional approach, when stakeholders want functionality that could drastically change scope, there’s no easy way to give it to them. When management seeks to impose unworkable time and budget constraints, knee-jerk capitulation will make your team think you’re a jerk. When your engineers are running on empty, and you need them to go the extra mile, no quid pro quo buying a few pizzas and some Mountain Dew isn’t going to cut it; the only reason they’ll go the distance is because you ask them to and because they know you’d never ask if it didn’t matter.

In these kinds of situations—and you’ll be in them all the time—the only sustainable strategy is to leverage relationships. But you can do this only to the extent that such leverage exists. And it doesn’t exist unless you create it—early and often.

Stakeholders have a right to demand anything they want. So does management. And you won’t make your team do anything they don’t really want to do because, among other things, you don’t control the actions of your teams; Agile organizations are much flatter than traditional organizations. It may seem like you are “in charge” of your team but you’re not; the team is in charge of itself.

Handling Product Ownership as a series of transactions puts you in the position of endless negotiating, promise-making, cajoling, coercing, and capitulating. Things like excellence, engagement, collaboration, contribution, meaning, satisfaction, aspiration—all the things that really matter to people—will not be found, at least not easily.

Instead of working for everyone else, or trying to get everyone else to work for you, it’s better to work with everyone one else. The success of this approach is predicated almost entirely on the quality of the relationships you establish with people. But if true success is what you seek, this is the work you’ll undertake to achieve it.

Back to the Station

Getting thousands of people and hundreds of trains where they want to go seems like a challenge that cries out for processes and tools. But shift happens. Dates change. Budgets don’t balance. Stuff breaks down. Things fall apart. The center does not hold. The world tilts off its axis. And then you have to go to a person and work with them to right it—with no tricks, tools, or trades, just a strong relationship you will desperately need in order to get things back on track.

Living at your laptop, running Rally like a rockstar, is great. But even the best laid plans of the best POs often go awry. This is when your key relationships become the key to your success. Everything comes and goes through Grand Central Station. At virtually every moment, you will find yourself in between one or more parties and one or more other parties. It’s better to be between good relationships than between rocks and hard places.

Roles and Relationships

As Agile scales up to the up to the enterprise, we begin to see it formalize. And as it becomes more formalized, it becomes less Agile. There is nothing wrong with this; it’s just what happens. When we’re one happy little scrum team working in our happy little startup garage, we have more flexibility. But when we are 100 or 1000, we pay a cost for working at scale, and that cost is usually some degree of agility.

That being said, this loss of agility is compensated for by tremendous gains in capacity. We may not do things as nimbly as we could if we were small but we can do things we would never be able to do at all because they are just so big that one team of eight or ten people simply can’t get everything done.

Agile at enterprise scale, therefore, is heavily role-based. As such, people can seem like interchangeable parts. For the organization itself, this has obvious appeal. But it doesn’t produce optimal results in the long run because strict role-based formalisms are antithetical to the Agile mindset. When Agile becomes formalized, it ceases to be agile.

In highly formalized systems, we have to look harder for ways to improve outcomes beyond the point of formalization. Processes and tools, systems and structures tend to play themselves out over time. In the worst cases, they ossify and are rendered useless because new and badly needed changes can’t be operationalized quickly enough to meet the demands of a highly competitive marketplace and a rapidly changing world.

So how do we deal with this? Where do we find the Deus ex Machina, (the “soul of a new machine” as Tracy Kidder coined it) from where comes the magical, mystical agent of intervention that restarts the engine of change, rejuvenates a geriatric system, and restores lost agility?

Relationships.

The difference is in the quality of the human relationships we have. Better relationships equals better results through agreements kept, friction reduced, and increased workplace satisfaction that is the catalyst of greater productivity. Strong working relationships make up for the loss of agility as we take Agile to scale because relationships transcend roles. Strong relationships bring out the best in each of us by increasing our personal agility. And it is this increase in personal agility at the micro level that replaces and even exceeds organizational agility lost at the macro level.

What follows are brief thoughts about the common roles you’ll encounter and the uncommon relationships you will build. We will explore each of these roles in more depth in future installments of this series.

PO to Scrum Master

Requirements come through you to the engineers on your team via your Scrum Master.

Your relationship with your Scrum Master should be your closest relationship. Reach agreement early about how to work well together. Talk about the kind of team you want to grow and how your combined and well-coordinated actions might best serve that end. The Scrum Master provides technical leadership and management expertise but this is not the totality of leadership expertise required for success.

Seek to complement each other for the good of the team and the success of the project. Work closely but respect the “What/How Line”, that often blurry demarcation between WHAT you ask your team to build and HOW they go about building it.

Always stay on your side. But always seek to understand their side to the extent that they know you appreciate the incredibly intense, ridiculously demanding, and supremely stressful situations in which they find themselves almost every sprint.These are the people who do the work. These are the people who always have skin in the game, reputation on the line, and fat in the fryer.

How do you achieve this high degree of synergy with your Scrum Master? By cultivating a co-equal relationship grounded in respect: for your Scrum Master, respect for what needs to get done; for you, transparency for what can get done. This is where your personal agility will be tested most often. Be flexible, open, and always working toward agreement.

Pay close attention to how your Scrum Master excels at consistently moving your team forward and continually optimizing its efficiency and effectiveness. This is the essence of what great Scrum Masters do and it is often what they take the greatest pride in. Look for it. Notice it. Inquire about it. Make sure your Scrum Master knows how much you appreciate it.

PO to Engineer

Code comes to the project through you via engineers and the ritual of story acceptance.

To accept stories with confidence, you need to be able to ask many questions of an engineer without casting aspersions, causing offense, or creating some kind of warped accountability process or compliance task.

In most cases, you won’t be able to see what’s going on under the hood. So how will you really know if the story is done? You’ll go through Definition of Done, of course. But even here, there are ways for stories not to be done and for you not to know this.

The relationship you need with your engineers is one that is characterized by safety and clarity of intention, a relationship where any question you ask is phrased as sincere interest on your part regarding their contribution and skill so that it is perceived as inquiry not indictment. To be truly successful, create relationships where you have made it clear that it is always safe for engineers to disclose things to you about code quality, tech debt, or risk and never have that information used against them.

Many engineers pride themselves on mastery. They write clean code. They are precise. They sweat the details.That means you don’t have to. Thank them for it. Treat them as trustworthy by default. Frequently express your appreciation of the knowledge and conscientiousness they bring to their work.

PO to QA

Validated functionality comes to the product through you from QA.

If you have embedded QA on your team, you have an extraordinary opportunity to have good acceptance criteria translated into great testing. It is well worth an hour or two listening to a thoughtful QA person talk about his or her approach to testing a story. But you won’t get that much of that this person’s attention unless he or she knows how much it matters to you and how much you appreciate the time your QA person is giving up to give you greater assurance in the validity of the work you own and represent to stakeholders, management, and the organization as a whole.

Think about it this way: when you go to do your sprint demo, you vouch for the fact that new functionality exists. For the PO to say, “We completed our sprint!” is, in a sense, to give your word that the work has not only been completed but validated as well.
This implies the delivery of defect-free functionality. Even though we know there are always defects, we don’t stand up in front of stakeholders and management and present completed stories that might have big holes in them. How do you know the holes are plugged? Your QA tells you they’re plugged and you trust your QA implicitly because you have the kind of relationship where that level of trust is possible.

The point of pride for many QA people is rigor. Rigorous testing catches defects early. Thorough and rigorous testing catches more defects even earlier. Take the time to understand how your QA person thinks about rigor and breadth of coverage. For Product Owners, life is always about the Happy Path. For QA folks it’s always about the bumpy road. Show them how much you appreciate their willingness to live that rocky ride so you don’t have to.

PO to Stakeholder

Work comes to the team through you from the stakeholder.

This is the classic Agile relationship. In theory, the PO is the stakeholder’s advocate on the project. While technically true, and often the best stance for making sure stakeholders get what they want. It’s an incomplete perspective for making sure stakeholders get what they need.

What stakeholders say they want isn’t always what they need because they don’t just want functionality, they also want certainty. You are their advocate, yes. But you act responsibly in that advocacy by advocating for things because they are right and because they are possible, not just because your stakeholder wants them.

While your stakeholder may certainly know more about their own challenges and goals than you do, no stakeholder knows enough about the range of possible solutions to solve their problems optimally. If they did, they wouldn’t need a Product Owner to help them render their requirements. The mere fact of your existence is proof that the stakeholder alone is not fully prepared to dictate every aspect of the product.

Instead of an advocate, think of yourself as a mediator. You want all parties to come together in agreement that the right thing has been made the right way. Insulate your team from stakeholder concerns; insulate your stakeholder from team operation. You want the stakeholder to consider your team a very capable and reliable “black box”. Stakeholders have enough anxiety; they don’t need to be wondering if your team can execute, and they certainly should never be tempted to wonder about how well your team is executing.

Stakeholders care about getting what they want, the way they want it, when they want it. The key to dealing with this type of uncompromising demand is clarity. You want your stakeholders to be very, very clear. So notice when they are and thank them for it. Encourage clarity at all times. Look for patterns in your interactions where clarity emerges by default and seek to repeat those patterns. Take responsibility for situations where stakeholders might not be clear by guiding them to clarity. Take the lead by being clear yourself, not as a way of diminishing or manipulating your stakeholders, but as a way of ensuring that your stakeholders really do get what they want.

PO to Architect

Great risks are mitigated, and great rewards are won through you via clear communication with your architect.

If you are very fortunate, you will have an embedded architect. This person can help you understand the past, clarify the present, and predict the future better than anyone else. Or your architect can render inscrutable all that your team has done, is doing, and will ever do.

This person can be your greatest teacher and most valued advisor. Or he or she can be an aloof genius who doesn’t have the time or the interest to tell you anything about what’s really going on.

How this plays out is entirely up to you and how hard you want to work to create and sustain a strong personal relationship that encourages your architect to share his or her thinking even when it is well beyond the limits of your expertise and the scope of your role.

Where many of us like to be appreciated for what we do, many architects like to be appreciated for how they think. Take a sincere interest in the intellectual elegance that many architects prize so highly. Ask them how they solve the problems they face, how they resolve and wrestle with the myriad tradeoffs that always exist between one way of doing things and all the other ways.

PO to Management

Organizational goals are achieved through you via directives from management.

Can management tell you what to do? Of course it can. It told you to be a Product Owner, right? So what happens when management puts on the pressure? You have to absorb it so it doesn’t hinder your team or trouble your stakeholder. (If management is your stakeholder, you have double duty here.)

Management pressure is serious pressure. So the only sustainable strategy is to have ways of alleviating it. And all of those ways will come from the quality of the relationship you build and maintain.

Regardless of how formally and at arm’s length your manager may want to treat you, you need to have a close relationship with this person because there will be many times when you will have to say, “No” and have “No” be an acceptable answer.

Respecting the “No” from a subordinate occurs only if both parties respect each other—as human beings on a planet not as slots in an org chart. You can’t own your product if someone owns you. The only way to beat the tyranny of the org chart is to develop peer relationships with people who are, technically, not your peers.

This requires getting to know people, and letting yourself be known to them, in ways that extend beyond the the structures and strictures of the organization. This is not breaking the rules; it’s making the rules. It’s changing the game from its zero-sum default to a more promising win-win reality.

Management’s reward comes from results. But along the way, management usually wants to be appreciated for the qualIty of its stewardship. Keep that in mind as you form the foundation of your relationship.

PO to PO

Unexpected work comes through you to your team from other POs.

In a large project, with many teams and many POs, this is your most interesting and often your most valuable relationship.

There will come times when one team cannot complete its work, or when one part of a system to which a particular team has been assigned generates more than one team’s worth of requirements.

The over-burdened team is just as likely to be yours as someone else’s. When that happens, you will need to be able to go to one of your PO peers and ask them to take a story or two from your backlog. The only way that people will do this for you is if you demonstrate at the earliest possible opportunity that you are willing to do it for them.

You cannot arbitrarily pledge the technical resources of your team toward new and different areas, but PO-to-PO you can always offer your consideration by saying, “I’ll take it to the team and get right back to you.” If it’s not possible, it’s not possible. But it’s always possible to see if it’s possible, to show that you were open and sincere in your effort to assist.

If your relationship with your team is based on cooperation, and not coercion, you will find them more sympathetic to the needs of other teams and other Product Owners—and ultimately to the needs of the organization as a whole.

You know what motivates you as a PO so look for that and reinforce it in your PO peers. You will also find POs who are much better than you are. Study them, express your admiration for their abilities, ask them to mentor you to the extent that they are willing. For those POs who are perhaps not quite as comfortable in their role as you are, pay it forward and do the same for them.

In the the PO-to-PO relationship, think of apprenticing yourself to your practice. That is, instead of taking the reductionist view of “Product Ownership as required functional role”, take the expansive view of Product Ownership as an evolving art, something always to be practiced, never to be mastered. And then appreciate the mastery you encounter in others.

How Product Owners Get By

As a Product Owner, you go to work every day at Grand Central Station. Things can come at you, things can go around you, or things can go through you. Things that don’t go through you will come back to bite you—unless other people have your back. The only way that will happen is if you cultivate good relationships.

In modern enterprise Agile projects, Product Owners have a dizzying array of disparate responsibilities. No degree of domain knowledge, technical expertise, 24/7 work ethic, or even sheer bravado will ensure that every responsibility is met. You must have help. And you must know you have help in order to make the tough calls that you, and you alone, will have to make.

Being in “the middle of it all” is exciting. But at certain times in a project lifecycle, it’s overwhelming. At some point in almost every project, your work life will become complicated beyond chaos. Nothing will be clear or easy.There may be no good choices, no correct answers, not even half-solutions to the monstrous problems you face.

And you own the product, right? So how do you get by?

If you’re as old as I am, and you started making software in the Pre-Agile-ite Era in the History of Software Development, you probably grew up listening to The Beatles. They were, arguably, the most agile band of all time. How did they do it? They got by with a little help from their friends.

Advertisements

The Dormant Environment

Death Valley Spring 2005 Bob Canfield

I was listening to a TED talk and the speaker threw out the word “Dormant”.  He used it to describe Death Valley which is named Death Valley because, well, nothing grows there.  No rain=No growth.  However, something happened in 2004….it rained (7 inches in fact) and in the Spring of 2005 Death Valley was having quite a hard time living up to the name.  The floor of Death Valley was covered in flowers.  Turns out Death Valley isn’t dead.  It’s dormant.  Underneath the barren landscape was loads of potential just waiting for an inviting environment.

I’m a little obsessive about environments – specifically environments for teams to be successful.  Today, more than ever, there are companies, consultants and coaches out there trying to crack the Agile nut in order to deliver value more frequently, efficiently and of higher quality.  It’s a HARD nut to crack.  The frameworks, Scrum, Kanban, XP and the consolidation of them in SAFe provide the manual and direction for companies to take.  Yet….they’re [still] not seeing the expected and much-desired results and I believe, with every nook and cranny of my heart, the reason lies in the environment.

DORMANCY:  The state of quiet (but possibly temporary) inaction. – Definition from http://wordnetweb.princeton.edu

Underneath the surface of the frameworks we’re using or, if you prefer, the foundation, are the Agile and lean values and principles.  But, I don’t believe the appropriate amount of time and attention is spent on teaching these.  Certainly not to the point where they’re understood well enough to be put into practice.  What’s more, I don’t believe most environments are suitable for the demonstrative manifestation of these values and principles.  So then what you end up seeing are the process side of frameworks in action – not people.  The frameworks are designed to bring the values and principles to life.  Frameworks need people to bring THE FRAMEWORK to life.  So, really, you need people to bring the values and principles to life and the environment, generally, just isn’t conducive.

Occasionally, there will be a micro-climate where, somehow, a team is flourishing.  I’ve heard these teams referred to as “magic teams”.  The magic of them is they created their own environment or micro-climate and bucked the odds – kind of like the Spring of 2005 in death valley.  Which, goes to show you, it’s not actually magic…it’s the environment.  Creating the environment is the key to unlocking the potential of people to bring the framework and the values and principles to life which will then bring the amazing results we’re all searching and striving for.  Oddly enough, those micro-climates are noticed by others as well.  The magic team is sought after and asked about their secret and the magic team will gladly, willingly give it away and, then, those seekers will tell you all the reasons why replicating it just aren’t possible elsewhere.

Maybe we just take for granted the environment will be there or it will evolve to meet the changes in process and approach.  Or, perhaps we don’t even want to think about the environment because changing or creating environments is difficult, hard work.  Also, there’s nothing telling you that a framework NEEDS any certain type of environment.  All of that said, I can’t think of a single organization who isn’t fully capable  and up to the challenge of creating an environment to enable success.  Especially if, at the end of all that work, the results would be nothing short of spectacular.  I would go so far to argue that the environment of every organization is dormant….quietly inactive.  I may even take it a step further and say the “environmentalists”, or those with the ability to be, are complacent.  Meanwhile, there’s all this potential just there, waiting for the right environment or a very persuasive environmental activist to get the ball rolling.

 

 

 

Monkey in the Middle

One of the keys in Agile is an empowered team.  Empowered to make decisions, self-mange and self-organize.  In order for a team to be empowered, they also need to be trusted.  Trusted by their teammates, their managers and their stakeholders.  I bet if you were to ask HR what kind of attributes they looked for in employees, they would tell you they want intelligence, creative thinking, a team player, a self-starter, one who has and takes initiative…..all attributes which, really, should make it very easy to trust that associate.  If you ask managers about the attributes their direct reports have their list would likely look a whole lot like the one from HR.  So, when it comes to empowering teams, why is it so difficult to relinquish control?  And, if managers aren’t willing to relinquish control, what happens?  I’m getting ready to make some guesses and assumptions here and would LOVE to hear your thoughts.  I don’t believe I have the whole picture myself, I’m just starting to dig in to this challenge more deeply.

WHY IS IT DIFFICULT?

1.  Fear.  Managers are afraid if they empower their teams, they won’t be as necessary.  If teams are identifying, designing and implementing their own solutions and they work…..why, then, do they need a manager?  What happens if the solution an empowered team implements doesn’t work?  Will the manager be blamed?

2.  Communication or lack thereof.  I see managers who don’t feel comfortable communicating the whole picture to their associates.  They operate in a mind-set of “need to know”.  When associates don’t have the complete picture, they can’t possibly design a complete solution.  They only have a fraction of the information.  A manager is needed to review and expand on the solution using the remaining information.

3.  Job Description.  Managers are held accountable to the performance of their associates.  Also, they are expected to manage work, find ways to improve the work and make the company overall, better.  Is the same true for those who aren’t managers?

4.  Trust.  Managers don’t trust their associates enough to empower them.  Managers also don’t trust those above them enough to realize the value and benefit of empowering their associates.  They may be worried it will look as though they’re not contributing themselves.

5.  Lack of Safety.  The environment isn’t one where it’s safe to trust those beside, below OR above the manager.  The “system”/environment is so fraught with booby traps, inefficient processes and fragility that it’s not safe to do anything without understanding the safety procedures and having a buddy or entourage.

WHAT HAPPENS?

1.  Disengaged associates.  If they aren’t trusted, don’t have the whole picture, aren’t expected to really live up to the HR job description and can’t implement any solution that isn’t fraught with risk there’s no reason for them to engage.  Their contributions aren’t valued, recognized or rewarded.

2.  Angry associates.  You ask people to give Agile a go.  You train them and emphasize empowerment, self-managing and self-organizing then, they’re not allowed to walk the walk.  It’s all just talk EXCEPT there’s an expectation of more, better and faster.

3.  Frustrated associates.  Tired of feeling they’re not valued and angry at the bait and switch move, they struggle to do as asked and told and don’t see any progress.

Now, the funny thing is, most managers were once regular associates and, I’m pretty certain, it would not have been acceptable to them if any of the above possible reasons were truths for them.  Managers grew into their position because they exhibited those attributes most companies seek and seem to value.  It is probably also due to….THEIR MANAGER.  Great managers exploit the positive of their associates.  They develop their strengths and find opportunities for them to shine.  They seek the input of their associates and teams because they know it’s not possible for them to have all the answers themselves.  They know the better their teams does and the more they grow can only reflect well on them and, ultimately, contribute more value to the company.  They know that being a barrier to their associates success serves no practical or valuable purpose.  They aren’t afraid of one of their associates surpassing them organizationally.

So, now I’m stuck.  What do you do to help overcome this challenge?  Ask provocative questions – there are so many!  Reveal the picture to them through questions.  They may be able to see it but, may also still be resistant.  It’s easy to help people who are aware and open…how do you help people reach awareness and openness?

I chose the title “Monkey in the Middle” because it’s one of the MOST frustrating games I can think of.  In the situation I have begun to lay out here, there are several possible monkeys.  The associates who are just waiting for an opportunity to grab the ball.  The manager who wants to be secure enough to empower their associates but doesn’t feel empowered themselves.  Then there are the people passing the ball, trying desperately to make sure the monkey in the middle never gets it.  Dropping the ball would mean giving someone else an opportunity to play and that would be????

Thinking Before Leaping to Agile

So, you think you want to “Go Agile”?  The very first question I have for you is:  Why?

Before you embark on a path as challenging as an Agile adoption be very sure, from the outset, of your goals.  And, let me be very clear here, the goal cannot be “To meet a mandate from our <insert title here>”.  It also cannot be “We just need to deliver more, faster.” There’s no doubt there are benefits to be had through an Agile adoption, but you will need to know WHY you want to take this journey.  More importantly, the people you will be asking to embrace, support and implement this change will need to know why.  If you’re not able to explain it – to put your goals out there – STOP.  Don’t take one more step or have one more conversation about it until you do.  Then, once you’re clear on those goals look to see if there’s anything about people on them.  The heart, soul and awesomeness of Agile lies in people.  If there’s nothing in the goals about people, STOP.  You will not realize the goals you have laid out without considering, paying attention to and cultivating your people.

What about people is important to an Agile adoption?  Well, all process and structures/frameworks depend on the people working within them to bring them to life.  In an Agile adoption, people and their ability to trust you and your ability to trust them is vital.  There will be things you learn about your company that will be uncomfortable and they need to be able to bring them up to you, their leader, to help change them.   Additionally, they will need an environment where they really can live the Agile Values.

When I reflect on the goals an Agile organization should consider they’re, actually, rather simple.

  • Are we delivering more value to our customers?  How do we know?  Your customers will tell you.  Ask your customers prior to your effort to tell you how they feel about the services and benefits you provide and, then, continue to ask them.
  • Are our operating costs going down?  Is your call center experiencing less call volume?  Is it easier to resolve an issue when they do call?  Do you need less and are able to deliver more?
  • Are our associates reporting a higher degree of engagement?  Do they feel empowered?  Do they feel they have real, true ownership of solving problems?  Do they feel their managers are, more than ever, focused on their development over their work?

Agile alone isn’t a Silver Bullet.  Maybe it seems that way OR someone is positioning it that way to you but just “doing Agile” will not deliver the results you’re probably looking for.  “Doing” Agile will get you some improvement – in the 25%-35% range.  “Being”  AND  “Doing”  Agile has the potential to deliver exceptional (400% improvement) results.  Being Agile depends on you, the leader.  When you announce the intention of an Agile adoption, you’re making an agreement to adhere, as closely as possible, to the Agile Values.  What’s more, your people will believe you and it’s critical you mean to live the values and you’re asking them to do the same.  Your actions from that point forward will confirm (or not) your commitment to those values and, essentially, your people.  So, WHY do you want to go Agile?

My Light Bulb Moment

Thanks to Michele Sliger for asking me to write it all down!

I started out as an ”Agile Project Manager”.  I accepted a contract for an IT project (my first) and was told it would be run as an Agile project.  I had no idea what Agile was and I was a Project Manager.  I had a great track record as a PM of driving results.  I googled Agile and was thrilled to learn my entire team would be in the same room, everything they were doing would be on the board and we would only have a 15 minute meeting once a day to discuss the project.  Oh….how very wrong I was.  Mind you the team delivered after slogging through entirely too much overtime, continuous pressure from me and the business and constant driving.  Unfortunately, their work never saw the light of day – two weeks before launch, the project was pulled.  What had worked for me before didn’t work this time.  I heard a lot from the people on the team who knew what Agile was and I was decidedly NOT a Scrum Master.  I cared, a great deal, about the people on the team and there were certain things I began to grasp but not enough to make a difference for them.  Honestly, why I stayed in IT after that project is beyond me but, I did.

Following that project, the next team I had was already formed and doing well on their own.  I still hadn’t had any training but, was asked to be the Scrum Master.  I started reading more and asking more questions of those around me who seemed to get this whole Agile thing.  I came into the team sure I would make them different and better.  I came in without acknowledging or respecting their history.  I asked them all kinds of questions about the work they were doing, why they were doing things the way they were doing them, pushing them a little so, in short, I didn’t really learn much and it still wasn’t clicking for me.  It was not a very comfortable place to be for anyone.  Then, someone had the brilliant idea to combine two teams together – mine and another – and that was when things started to get interesting.  The team that joined my team DID get Agile and they were not at all OK about how I was running them.  They pushed back.  I went to CSM training.

Joe Little and Jeff Sutherland were teaching the course and, as I sat there, all the pieces started coming together.  I understood how it was supposed to work and how I wasn’t doing anything AT ALL to make it easier.  Jeff Sutherland made the point that I still true back to all the time:  Protect The Team.  I came back to work energized and excited.  It clicked and I couldn’t wait to get going.  That said, there was this HUGE team which was really two teams trying to keep their individual team identities in place and continue to be the good teams they were separately.  It wasn’t working. I knew, in theory, what I was supposed to do but I didn’t know HOW to do it.  They fought over desk position, norms, how stand up should be run, how planning should be run and we were all incredibly miserable.  I thought I was doing the right things and protecting the team.  I wasn’t.

I asked another Scrum Master for help.  He came to observe a retro and, at the end of an hour, told me I couldn’t stop.  I had to keep the team talking for as long as it took for them to work their issues out.  The retro lasted all day.  Seriously, all.day.long.  Everyone was open and honest including me.  There were things said which were really hard to swallow for me.  I really had been trying to do the right things.  They made me question everything I had ever thought about my abilities. However, after that retro there was something different.  We all realized we were all trying to do the right things.  There was no malice or ill intent.  We trusted each other a little and we had overcome a decent amount of pain together.  After that retro, I started reading, researching, asking and experimenting and the team let me.  I would tell them what I wanted to try and why and I knew they would tell me when I was off track. They would tell me because they knew I was trying and I wanted to get better.  They also wanted to be better.  We all wanted to be the best team possible.

So, we’re all on an upswing now and someone decides to split the team back up.  Yes.  After ALL that pain we needed to split.  I remember being in the room with several other people figuring out who would go where and they were all looking at me to make the new teams.  It tore me up though.  I had gotten close to everyone and they were doing so well but, I did it, and I chose the team I was going to stay with.  The team was named BOB.  We worked together for about a year and it was the single-most rewarding and fun time of my career.  What I learned from that team in terms of trust, what empowered teams can do, what protecting a team meant and what the role of a Scrum Master really was is what has shaped me and guided me to where I am now.  It is an experience I hope everyone working in Agile can have.

We were nearing performance management time and I was writing my self-appraisal.  I didn’t have anything to write.  I didn’t have any results.  There were no “BIG WINS”.  In fact, I sat there thinking I hadn’t had to do much with the team at all.  I started to get truly worried about what was going to happen come end of year.  With none of the usual problem-solving, risk mitigating, implementation strategizing and scheduling management-type-stuff my piece of paper looked really empty.

“Scrum Master for a team who has delivered more scope than originally requested within the same amount of time.  No defects released into production.  Team has created automated test harnesses to enable faster identification of defects and leverage the QS resource more effectively.  Team members have learned new skills to be more efficient in their delivery approaches.  The team manages themselves, including removing most impediments. The team has created a build book to be used by the platform and serve as guidelines for UI development.  The team is able to respond quickly to change and is frequently sought after by the business to help shape strategy and inform intent.”

The TEAM had done great.  They had knocked everything thrown their way out of the park.  They were having fun and everyone wanted them.  Then it hit me.  They did it!  They were a self-managing, self-organizing, high-performing machine.  That’s what is supposed to happen.

 

 

This Old House – Agile Edition

When you’re transitioning to Agile, there’s a lot going on all at once.  It occurred to me  it’s similar to home renovation – a really, really big home renovation.  Personally, I LOVE old homes.  I love going to see them and, one day, I want to buy one and fix it up.  Sometimes, I walk into a house and while I’m oohing and aahing my husband is groaning.  He’s groaning because the houses don’t generally meet any criteria he has for a home.  I’m oohing because I can see the potential a house has.  All you need is some imagination, good bones and time.  That’s what an organization needs to create a great environment for Agility too.

IMAGINATION:  To begin, you need to be able to ooh and aah instead of groan. You need to be able to see what is possible for teams, management and your users.  If you don’t have imagination absolutely everything about the process will frustrate the hell out of you.  You can’t hire someone to “take care of it” for you or oversee it.  Nope.  You need to be willing to be architect, general contractor and all the subs.  If you have imagination and can envision what it will look like you have an open mind.  An open mind is necessary because everything you thought you knew about “how your house was built” is going to get thrown out the window.

GOOD BONES:  There are some things that just need to be in place.  It’s no good and not practical if you have to bulldoze the house and start from scratch.  You need smart people who are willing to opt in and give Agile a serious go.  You need managers who are way more into the products their company produces than they are into their “turf”.  These managers must also understand how to support, motivate and develop people.  You need a culture of drive and commitment.  You need a business who will look at the business differently.  You need a company that invites people to opt in instead of mandates.  OPEN MINDS are essential.

TIME:  It took a long time to build what is, arguably, good enough.  To change, grown, learn and be great you need time.  You know the saying “Rome wasn’t built in a day”?  An Agile transformation doesn’t happen overnight either.  This renovation is going to take time.  Since you know that, you also need to know to be patient.  Also, you should know that you will never be “Done”.  You will always and you should always look for things to improve on.

In my vision of a great Agile environment there are spaces for teams to work together, as a whole team and places to pair or collaborate with a smaller group.  There’s technology available for distributed teams to use.  People laugh!  Anyone walking by can see what the team has going on and how awesome they are.  There’s some corporate furniture around but teams can put their own identity on their spaces too.  There’s a wall for anyone who wants to put an idea up to try and others can join in the effort.  Directly opposite is another wall that celebrates the successes and failures (learning) from the efforts of these self-organizing teams.  The environment is safe for everyone to be open, honest, disagree and try anything they think will be for the good for the team, the company or the user.  This safe environment also has a hum – there’s energy and people are genuinely happy to be there and be a part of it.  There’s also an endless supply of post-its (all colors & sizes), sharpies (all colors), magnets and flip charts.

As with any major project, you’re bound to hit some snags.  That’s OK.  It’s all part of the adventure.  You have no idea what you will learn along the way and the creative solutions you will find.  The time, thought and care you put into creating this environment will be huge.  If done well, at the end, you have teams of completely happy and motivated individuals.  You have a safe environment where learning, trying and trying more is encouraged.  You have users who are loyal and more than satisfied with the products you are producing.  All this because of the environment.   There’s no need for razing the house to get to the land.  Keep what’s good and useful, ditch the rest and strive for the perfect environment.

All Pain and No Gain

In an Agile transformation we all focus on getting the teams set up, training them and get them working in Scrum (or whatever).  Then, you have these teams going and you see some improvement but maybe not the BIG BANG improvement  you thought you would see.  So, you start looking into what the teams are doing.

Are they having stand up? – CHECK!

Are they doing Sprint Planning? – CHECK!

Are they having Retros? – CHECK!

Are they using a Scrum board and burning down daily? – CHECK!

Is it effective? – Ummmmmmmmm

The thing is, the tactical parts of Scrum are in place to teach the teams how to think and work differently.  A team can only get so far with the tactical elements alone.  In order to realize the benefits of Agile, a team needs to shift their mind set and so the all the people outside of the teams.  The tactical part of Agile is easy.  It’s the Cultural part that’s really difficult.

If teams are having challenges breaking down the work into small enough increments, you may be able to address it with some training and hands on guidance during planning.  However, if the business cannot think differently and insists or MORE it may be that the team isn’t empowered to break it down smaller.  Or, maybe, in demo, stakeholders are critical of the “little” the team has ready and pressures for MORE.

If teams aren’t continuously improving and having their retros, it could be that the team needs some instruction/coaching on what continuous improvement means.  Maybe the Scrum Master isn’t leading effective retros and needs some help there.  Or, maybe, the team isn’t given the time for retros because of some outside forces insisting they do something differently.  Maybe the Scrum Master doesn’t have time to learn how to be a Scrum Master because they’re busy writing status reports, going to status meetings and completing documentation for an organization that hasn’t embraced Agile yet and relies on Project Management artifacts and methods.

I’m staring to think an Organizations transformation doesn’t start with teams at all.  I think it starts with everyone else.  Scrum and Agile are easily applied to any type of work.  The Agile values and principles are also applicable to any type of work.  Maybe the teams should be left alone until everyone else understands how to work in this way.  In focusing the effort outside teams first, the culture shift could start with those who have the ability to stifle or supercharge the teams.  Once everyone outside the teams are ready for the teams THEN the transformation can begin.

Because, until the culture starts changing – in earnest – an organization is really just going through the motions NOT transforming.

Focus on those who OPT IN

I’ve been thinking a lot lately on where to focus.  In a large transformation effort, there’s more than one area requiring attention:  Teams, Scrum Masters, Middle Management, Leadership, Performance Management, Space, Culture…..  You name it, it probably needs some care and feeding so, where’s a person supposed to spend time?

Initially, my thought was to focus on those people or places that were not far along the change curve.  Then, I realized how much effort and time went into that category.  We talk about empowering people and teams to deliver value.  Why shouldn’t the same apply to learning and change?  If you make training, workshops, blogs, books, coaches and every possible thing imaginable available, people who want to learn and change will avail themselves of those resources and more.

The time we spend “selling”, convincing, cajoling and, yes, begging people to give it a try is wasted.  Those people will either opt in or not.  I’m not saying zero time should be spent on this category.  I AM saying it’s a pull system and, when asked or requested, some time should be spent there.  Spending time pushing it isn’t valuable. As people are ready, they will pull – just like a team and a backlog.

Focusing on those who are opting in makes sense.  Results will happen.  People will be happier.  Formerly opt-out people will notice and they will come.  When they’re ready, you should be too.  Be ready to help, coach, guide and keep the road as clear as possible for their own transformation journey.  The cycle will continue.  It just takes time.