This presentation was given at the Boston chapter of the IIBA on November 2 and covers some important common experience that good Product Owners have, 5 Archetypes of Product Owners and the growth opportunities for each of them and 4 areas to focus on to grow as a Product Owner to help not only transition to a new role, but to truly make the leap and place innovation front and center.

The slides are available here.

I was working with a team a few years ago and like many teams when they are starting out, they were struggling to close stories in a single iteration. I was searching for something that would resonate with them and remind them to be focused on closing stories. Then I remembered the line: “A-B-C. A-Always, B-Be, C-Closing” and started using it.
In Agile, we don’t get credit for partially completed work, we only get credit when we close stories. This emphasis seems foreign and unimportant to those transitioning from waterfall approaches because they don’t see why it is a big deal to start and finish stories in a single iteration. As a coach I see the mess it creates for a team when they aren’t able to complete work in a single iteration. Velocity becomes highly variable, doing a yo-yo from one iteration to the next. The yo-yo effect makes it difficult if not impossible for a team to predict with any certainty how far through their backlog they might be by release time. If they can’t set expectations, expectations get set for them by those higher up the food chain. That pressure rolls back down hill through the Product Owner, managers and then finally to the team. Then the death march begins. This is not what Agile is all about.

Now let’s focus in on the root cause. It is relatively easy for teams to get a story to being almost complete, but the final steps that need to be taken to close it out are often the hardest and can feel the least rewarding. So what happens is the story is declared almost done and a developer rolls onto starting another story (men are particularly bad at this, we are great at starting things, but horrible at closing). Other team members get sucked into the excitement and rush of supporting and figuring out a new story and the challenge it brings. Meanwhile, there’s a perfectly good story, a few hours short of being complete just waiting for someone to finish it up and enabling the team to call another story done.

I have found that with the teams I coach, using the “ABC” phrase regularly draws attention and emphasis to closing out in-progress current stories. One team I coached had a team member that would yell out “ABC” at standup if another team member announced they were going to start working on a new story and they already had one open and in-progress. Everyone would laugh at the outburst, but it worked. It reminded everyone on the team to focus on closing those stories out.

If this approach works for you, go ahead and use it. If not, find something that helps bring the focus to closing stories, because closing is one of the hardest things to do. Now if I only had the discipline to apply this to my projects around the house, my wife would be much happier.

PS: The play was made into a very good movie with a star-studded cast. Be advised, the language is strong and direct.

A team had recently completed a round of basic agile training and was a few sprints into their work. During sprint planning, several members of the team felt organizational pressure to create a sprint plan that was twice the velocity they had established through their first 2 sprints. As I prepared to interrupt the team and ask how they arrived at the notion that they could double their velocity in one sprint, the most junior member of the team (a college student on a work assignment) beat me to it and said: “we can’t do that, it’s double what we’ve done before. Our velocity is x, so we should plan for x.” (I was glad to see that the training had stuck with someone.) There was some discussion, culminating in the more experienced members of the team answering with “well, we have to get all this work done this sprint, so we should tell management we are going to”.

So this very brief exchange got me thinking; Are the right people getting a chance to lead when they should be? I started to pay more attention to what was going on with these college students and how they were interacting with members on other teams. What seemed to be happening most often was the college students were standing off to the side remaining largely quiet.

Through one-on-one conversation I knew that the college students had a good grasp of the basics and how Scrum worked. Some just didn’t feel like they had the opportunity to speak up. They felt they were on work assignment to learn how the “real world” worked and as a result they played more of a passive role, but there were repeated scenarios where they would have been the perfect person to step forward and help the team take a different course.

So what?

Adopting Agile is challenging, so why would a team or organization want to ignore or not capitalize on all of its assets to make progress? Why should titles or amount of experience matter if someone has a genuine positive value contribution to make? That would be like a professional baseball team opting to not call someone up from the minors and only putting 8 players on the field because someone was hurt. It makes no sense.

This particular team had some really strong muscle memory to overcome, with the exception of the college student, members of this particular team probably averaged 13 -15 years of experience and many of them had more than 5 years with that company. This muscle memory creates these really tall and big obstacles that dictate how we handle certain situations. Most of the time, we aren’t even acting consciously; it is just a trained response.

It is up to the team and organization to create a culture and an environment that allows these entrenched behaviors and responses to be openly challenged and changed. So how do you do this?

Here are some things to consider:

• Inexperience counts – Don’t be afraid to look to the most junior members of your team to see what they think should happen. Personally, I have always enjoyed the questions that new team members ask. They have a fresh perspective that can shed new light on a problem or challenge that has plagued a team for some time. This fresh perspective and new energy can be contagious and get people thinking about other things that can be changed for the better.

• Put managers in the right place – Trouble can often result when managers try to play a double role as team member. It is a near guarantee that team members defer to the manager’s “wisdom” and knowledge. It takes a very special person to play the role of manager and team member at the same time. Managers are often best used as problem solvers or you could defer to them as a tie-breaker on technical issues. Managers are often best positioned to focus on improving the things outside the team that have a drag on the team’s productivity. If it is unavoidable having a manager play team member, choose your moments carefully. Your staff will listen to what you say more carefully than anyone else on the team, whether it is out of fear or respect only you know, but they do listen more carefully and are more likely to follow your lead even if they think it isn’t right.

• Your company culture determines how a lot of things work – Agile adoptions can be made or broken by the culture of the company. If the culture is one of conformance and standardization, an Agile adoption is likely to fail. Agile teams look and act different and in that environment standing out is frowned upon. On the other hand, a culture where learning, mistakes, reflection and continuous improvement are accepted, there is a much higher chance of successful adoption. Encouraging people to step out of their roles helps push the boundaries in positive directions.

• You are all in it together – I always tell teams that they need to take an approach similar to that of great sports teams. You win or lose as a team and everyone should be treated as an equal. Individual statistics and glory means nothing at the end of the day. Act as a united group, focused on delivering valuable, quality software.

Agile is about simplicity and common sense and requires changes at many levels to move forward. Is it so strange to think that someone who “knows less” is in a better position to help lead a team through change? It is a sign of a healthy team when anyone on a team can step forward and take a leadership role for a certain practice or idea and not have anyone else feel threatened.

After the presentation I thought more about our exchange of information and realized what an interesting set of challenges having distributed teams really presents to some of you and your teams.  I really liked some of the ideas that were shared and it shows some of the creativity being applied to solve the challenges of distributed teams.

As I promised, here are the slides from the presentation.  Best of luck everyone and thanks for having me.

When starting out many people operate under the assumption that Agile can’t work across distances or worse yet they convert their distributed waterfall organization over to just start doing Agile and are surprised when they don’t like the results they get. It should be no surprise to us that when team members get a chance to work face to face, the results can be quite good. Working face to face certainly doesn’t guarantee good results (it certainly didn’t for decades before off-shoring and distributed workforces came into vogue) nor does taking a distributed Agile approach have to mean pain and failure. What it does mean is you have to know what you are getting into and make sure you are addressing the specific needs of doing Agile over distance.

Agile needs a high degree of collaboration to work successfully. I’m talking true collaboration, not just people working on the same project together. So anytime we take on an agile endeavor, we have to create an environment that allows collaboration to flourish. In order for collaboration to work; 1) people need to know and be comfortable with each other 2) everyone has to bring something to the table 3) you have to be able to work on the same thing at the same time (you may not always be working on something at the same time as someone else, but you have to be able to do it when you need to).

When we look at distributed teams, the main challenges that stand out to me are: geography, time zones, and talent spread.

Geography:
With the conveniences of modern technology like video conferencing, web chatting and instant messaging, the globe is getting smaller and geography issues are becoming more conquerable. It still isn’t the same as sitting next to someone, but I think it is workable. I’ve even heard of some cool new technology that connects two rooms with a display wall that makes the rooms feel actually physically connected to each other.

Time zones:
Time difference plays a bigger role than the actual distance between team members. The less overlap there is in “normal working hours”, more independent or solo work is going to be taking place (read: less collaboration) which can easily take teams off track. Successful Agile teams have strong and immediate feedback loops that allow them to validate work with each other before investing too heavily in an approach. The more of the workday team members are spending without the ability to reach out to someone in another role, the deeper the investment becomes in something that could be discarded.
It’s not uncommon for people to be asked to work adjusted hours to better accommodate everyone on the team, but this can create issues with employee’s family schedules or cause “extended days”. With extended days, team members may often get stuck working their adjusted hours to work with their team and also working their“ normal working hours” because they are expected to be in the office during those hours. This isn’t a sustainable model and will lead to burnout very quickly.

Talent Spread (or alternatively cross pollination of disciplines within a physical location):
In software, truly successful collaboration happens across disciplines, where you have a developer working with a Product Owner, or a UI designer and a QA tester, or a QA tester and a developer. There are numerous permutations, but the point is people representing different skill-sets, concerns and areas of expertise get a multiplier effect when they are able to work together and collaborate. I personally love having analysts and testers work together on creating test cases/requirements. My rationale is analysts are good at building things and figuring out how to make stuff work, testers are great at breaking things and seeing the cracks. By having the two disciplines collaborate, teams get really solid sets of tests that are well thought through and cover most scenarios. Obviously, Product Owners, developers and anyone else on the team are welcome and necessary partners in that collaboration as well.

Applying this idea against the backdrop of outsourcing and off-shoring models that many companies have adopted where entire departments or disciplines are moved to a new location (i.e.: development or QA to India) and you can see how challenging real collaboration can be for many teams. I’ve heard the argument for 24-hour workdays for years, but in practice, I’ve only seen it work for short bursts on a project where the team had a good grasp on what they were doing for the next week or so. However, beyond that, obstacles are encountered, feedback is needed, design reviews happen and the list goes on. All these things effectively put traffic lights into the 24-hour workday and all the lights are rarely green at the same time.

So what to do?

When setting up a distributed team, consider the following:
• Have the fewest number of different physical locations involved in that team.
• Don’t ever have one person working alone in a location.
• Make sure you have team members with different skill-sets in the same location and try to build a critical mass there.
• A double-digit time difference between team members is going to be a challenge and is not likely a sustainable approach. If this is unavoidable because of the locations your company operates in, build a fully enclosed product development team in each location that ideally has a product owner embedded with them and can work side by side with the team.
• Have a remote PO or PO proxy that is empowered to make product decisions when the primary PO is not available. Expecting the PO to be available 24 hours a day is unreasonable, conversely constantly waiting to the next day for a decision is a big red traffic signal that backs everything up.
• Travel – team members should get together to spend time face to face to build strong relationships and an understanding of each other. Ideally an entire sprint can be spent together working side by side so team members actually get a sense for how they work over the cycle of a full sprint. It’s helpful if travel can happen repeatedly over the course of the project to help to continue to grow the relationships.

I ran a mid-size Agile program a few years ago with a mix of distributed and co-located teams where many of these techniques were employed so I can say with first hand knowledge, you can do Agile across distances if you follow some basic guidelines and are willing to invest in the right things.

I’m sure there are many other creative techniques that can be used to bridge the gaps and I’d love to hear from anyone else who has successfully done something different.

I find that when starting with a new client and discussing the idea that we are going to put all their tasks and activities on a wall for everyone to see and so that it’s easy for the team to update, there is almost always push back or at least hesitation. The concerns typically are centered around the fact that “well we already have a dashboard system we use here to track project status and Sr Management uses it”. My guess is they have never seen a good story board/task board wall.

So where does the refrigerator part come into this?

Well, recently my refrigerator went on the fritz and stopped working, but I didn’t know it. I noticed that items coming out of the fridge seemed to be less cold, but I figured it was just me. So I didn’t do anything. Many hours later, the problem seemed to be worsening. Lo and behold, we had a problem and ended up losing a bunch of food in the refrigerator.  We had it repaired and all was fine, until it broke again.  This time the “breakage” was more obvious, but only because I was standing in the adjacent room (there was an electrical popping sound and a puff of smoke that came out from under the unit).  If I hadn’t been in the next room, again I wouldn’t have known something was wrong.

In the end, my wife and I decided to buy a new refrigerator instead of repairing the original.  The unit we purchased was half the price of the original unit (which was only 7 years old) but has more features and fit our needs better.  We purchased based on price, look and features, in that order.  It has a feature that I really didn’t notice/appreciate until it was in my kitchen and plugged in.  A digital display that shows the temperature of the freezer and of the refrigerator.  That’s the information radiator.  It even has an alarm built in alert us if the temp rises too high.  I could have a manual thermometer in the fridge and in the freezer to tell me the same information, but the difference is, I have to go look for it.  I would have to open the fridge, find where the thermometer got moved to and read it, just like a traditional dashboard.

With my new information refrigerator every time I am in the kitchen I know if things are working as expected simply by looking.  No digging for thermometers (or dashboards located on the web or in some program management tool somewhere).  So now if one of my kids leaves the door open or if it breaks (it better not, it’s brand new), I have a much better chance of knowing and being able to take a corrective action.

So what makes a good information radiator?

• It’s highly visible
• You don’t have to go find it, it’s just always there waiting for someone to look at it
• It is kept up to date – it’s simple enough that the team actually uses it and updates it and it reflects what the team is working on
• It can alert a team to a situation that needs corrective action – it doesn’t tell you what to do, it just displays the facts, we have to do the rest
• It’s simple

I love the information radiator part of my new fridge so much, I’m not sure I would ever want one without it.  Just like I would never want to run a project without an information radiator.  Once you see it and experience the simple power of it, you’ll know what I mean.

If you are a virtual team you have additional complexity to deal with.  BigVisible has built a virtual task board (information radiator) that is free for anyone to use, check it out at www.seenowdo.com