Agile Collaboration

Collaborate (verb) – to work jointly with others or together especially in an intellectual endeavor

Collaboration (noun) – the action of working with someone to produce something.

(Source: Merriam-Webster)

I was recently giving some training where I asked people if their work environment was open and collaborative. They answered yes. I then asked if they knew what the CEO, CTO, CFO, Marketing, Sales were doing that week. Most didn’t know the answer. I asked how much say and influence the development team had over the type or scope of product work. The answer was little to none.

We often work in environments that are considered ‘open’ and ‘collaborative’ yet we have small groups making all the decisions and passing them around like dinner invitations. We get a meal but little input into the meal itself. For better or worse, the development team is often told what to do through some hierarchy and given requirements with the expectation that these requirements will be implemented as is and on time.

Collaboration and culture

How familiar does this sound: You’re in a meeting trying to solve some problem. The manager asks for suggestions and you boldly give your opinion on how best to solve the problem. The manager is looking at you without expression, perhaps even staring. You finish your comment and the manager continues to look directly at you for a couple beats after you’ve finished. The manager then states the solution which has no relationship to what you just said or for that matter, what anyone else has said. The manager closes the meeting saying something like, “Great ideas and a great collaborative effort. Thank-you all for helping.”

Now some would say the manager took on-board all the ideas and arrived at a solution but more likely, the manager had already made a decision. The manager held a meeting to check if he or she overlooked something and gave the illusion of collaboration. This kind of behavior is not uncommon and in at least one place I’ve been, managers were expected to make all the decisions.

How your culture is set up can determine how collaboration will work. Think about how your office works today. In Steve Coats’ article, “The Conundrum of Collaboration“, he describes it like this:

Think of it this way. You are one of two candidates being considered for a promotion into a higher position. You have always looked for opportunities to collaborate and have been part of many successful achievements. The other contender’s profile doesn’t focus much on collaboration. Instead it highlights a string of great accomplishments that this person has been directly responsible for throughout his or her career. From what you know about how promotions have been determined in your organization, would you feel like you are in the strongest position?

Although the company culture can deter collaboration, Steve Coats goes on to state that people’s own sense of self is a larger barrier to collaboration.

Clearly there are things about an organization itself that impact collaboration efforts, but none of those are the number one reason that collaboration stalls. That reason is much more personal. It is self-interest. People frequently refuse to collaborate because they do not believe it is in their best interests to do so. And those organizational confines just discussed strengthen that argument.

Sure businesses want people to collaborate but the reward goes to the individual who achieved something. At one place I worked, the performance review rated how independent I was. The top score was “works independently”.  Asking for help can be seen as weakness; always working with others can be seen as a crutch. You can’t expect collaboration if there’s no reward for doing so.

The hero and the collaborator

The Agile Manifesto and Principles don’t tell us how to do software, it’s up to the facilitator and implementer to figure out how best to be agile. While agile doesn’t directly say that collaboration is required, the expanded responsibilities needed for a successful agile team means that collaboration is a necessity.

In most organizations there are identifiable heroes; those people the company can “count on” to make projects successful. While this sounds familiar to most it is also an illusion. The hero does it all except grow the team. If the hero is away or leaves then there’s likely a vacuum that takes time to fill because the development team haven’t been trained or encouraged to step up.

In traditional projects, the heroes are in constant motion, making decisions, telling people what they need to do, and genuinely doing their best to make the project a success.  If the project were less than successful, either schedule or budget weren’t met, fingers are often pointed, usually at development. The heroes are Teflon coated and any negative feeling usually won’t stick to them. One reason heroes can flourish is they have knowledge that others do not have. To maintain their status as hero, it’s incumbent for them to withhold certain knowledge. To be clear, they are not withholding knowledge that could be catastrophic if not shared; they are not about to allow the ship to hit an iceberg. However, they might withhold details of why the work is being done. Development teams are expected to write “IF … THEN … ELSE” and not participate in the broader question of ‘why’. But here’s the problem: the development team collectively has a vast amount of knowledge and experience that is left untapped and businesses should tap into this to grow. Agile would sacrifice the hero to get to this untapped resource.

The hero acts like a tourniquet; too tight and the limb withers and dies, too loose and the patient dies. If the hero holds too tightly to knowledge, the development team will feel less engaged. If the hero let’s go without priming the team, the inexperienced team will likely falter. The tourniquet is not the long-term solution but a stop-gap. The danger to the business isn’t the hero themselves but the over reliance on the hero to the detriment of others learning and growing. I’ve been in meetings where one person says they’ll do everything and everyone else steps back to allow them to proceed. A hero can help make the company successful but we’re not here to rest on our current successes, we want to be more successful. Having heroes can limit imagination and growth because you’re stuck with what the hero knows.

Collaboration and success

The need for collaboration can come down to how you measure success. If you’re being agile, success is measured by customer satisfaction and achieving business goals due to that satisfaction. In traditional software development, success is measured by completing the project plan on time and on budget.

To be successful in agile, everyone working on solving the customer problem needs to be aware of how the customer perceives their problem and what they feel is a solution.  This is the fundamental shift from traditional project management. Everyone involved in the solution needs to have a near-identical understanding of the customers’ problem. This necessitates collaboration with the customers, development, product, marketing, sales, support, and management.

Steps to improve collaboration

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win”JFK Rice University 1962

“win just one for the Gipper” – attributed to Knute Rockne

“I have a dream!”Martin Luther King 1963

If you’re looking to improve collaboration, one could say simply change the company’s culture to reward collaboration but this is insanely hard. Besides, when was the last time something big happened because you ‘said so’?

Improving collaboration within a business and between teams requires finding the answers to these two questions:

  1. how does collaboration benefit the individual
  2. how do I collaborate more

Neither question has an easy answer and the details of the answer are wholly dependent on the environment. However we can look at some general strategies to answer both.

Benefit the individual

One thing that most people will agree on is an engaged employee is a happy employee. The first step toward engagement will be to trust the them and their team to collectively find solutions. This begins with the business establishing boundaries where the team can operate and make decisions freely. For a development team this probably starts with the product backlog and grooming the requirements/user stories. To be clear, it becomes the team’s responsibility to work side-by-side with the customers, users, and product people to appropriately understand and refine the work. The reward is the team gets more input to the product. As the team becomes more involved with the business of solving customer problems, the more skin they have in the game. The teams will spot pitfalls and opportunities much sooner, increasing the likelihood of success. Taken together, this empowerment to make decisions and the added responsibilities will:

  • create strong team bonding
  • increase the team’s sense of ownership of customer and business problems

This will also allow a team to fail earlier and make corrections much sooner.

Collaborate more

It’s very easy to tell people to collaborate, very hard to have valuable collaboration. When I worked with teams that were located in different cities, I arranged for two scrum-of-scrum meetings each week. I also set down an agenda that balanced high-level knowledge sharing (e.g. business/customer problems being worked & architecturally where the last and next changes would occur) with low-level implementation work so developers weren’t stepping on each other. These collaboration sessions were facilitated by scrum masters and one team in each city documented decisions and actions. We did the double documenting to make sure we all heard and understood correctly. As we progressed we adjusted these sessions to maximize the value and reduce the duration. We generally did them in less than 20 minutes.

To get the executives, senior managers, customers/users, and agile teams on a first name basis so to speak, we did inception workshops. A key activity for internal collaboration was a ‘who/do‘ table. This is based on the book “Gamestorming” by Dave Gray, Sunni Brown, and James Macanufo.

Through this table of actions, all stakeholders team up and commit themselves to achieving a successful result. While there are several activities that can be done throughout a project to strengthen collaboration, retrospectives for example, having this at the start sets strong expectations for all stakeholders. The ‘who’ on the list are actual names of people when needed or roles otherwise.

If the team has trouble identifying who they need to collaborate with, they can do a variation of the circle & soup game during retrospectives. This is a game usually used to identify improvements and problems that either slows down or blocks something the team feels is important.

  • Inner circle: “Team Controls” – what your team can directly manage
  • Middle circle: “Team Influences” –persuasive actions that your team can take to move ahead
  • Outer circle: “Soup” – Can’t control or influence: elements that cannot be changed. This refers to the environment we work in and must adapt to. Ideas from the other 2 circles can identify ways to respond to the barriers floating in our “soup.”

As well as identifying problems and how to approach finding a solution, the circle & soup game makes clear the avenues of collaboration. For those improvement items they ‘control’, these are the areas that collaboration is needed within the team and between teams. The items in the ‘influence’ and in the ‘can’t control or influence’ circles means collaboration with those people who own the area of interest. The different circles suggest that different tactics and collaboration skills will be needed.

Mutiny

What happens with the developer who only wants to write code and doesn’t see talking to users or writing user stories as enjoyable or desirable? Moving these people is hard and could be likened to moving the sofa across a floor. At first you’ll need to exert lots of force to overcome static friction but once moving, you only need enough force to overcome kinetic friction. However, there is a point when it’s cheaper to hire right thinking people for the team rather than attempting to change behavior. This may sound harsh but it needs to be done on occasion. When I’ve seen this it often benefits both the company and the individual. I’ve also seen where someone once removed from an agile team returns sometime later.

Summary

Collaboration isn’t natural behavior for people and is therefore something that must be practiced and learned. There are tools that can help, ‘who/do’ lists and ‘circle & soup’ games, but in the end management and teams must recognize collaboration adds a dimension of efficiency and speed to any endeavor. The business needs to setup the conditions where collaborating becomes natural. Managers and management have long been collecting information, filtering it, and making key decisions. Pushing decision making down to the people who have the knowledge will be a challenge for some managers. However, only management can begin the process of removing hierarchies from peoples’ minds and teach teams how to collaborate and how to behave to maximize collaborative results.

 

Being Agile When The Business Isn’t – Communications

I recently met a group of people having a hard time ‘doing’ agile. They understand agile but others in the business chose not to participate. These were managers and business leaders. Although the group’s first reaction is to ‘sell’ agile I gave them an alternative of doing things to add value both for the business and for customers without a sales pitch. What if the team communicated a better way of doing work that created more success? Wouldn’t the business embrace better ways of being successful?

Let’s start by establishing that A) No one goes to work hoping to fail and B) Business leaders and managers often don’t see how changing themselves can improve the team’s outcomes.

Although people don’t want to fail, we can’t assume they’ll do their utmost to be successful. Being successful takes effort but this is something that can be leveraged for your advantage. You’re not going to push agile but rather advocate a means to be more successful. Your communications with the team and business leaders are about being successful and about ways to be more successful.

When you communicate with managers and senior stakeholders in the business, they’ll most often listen to you but more importantly, you’ll need to listen to them. These people want something from the teams and your best approach is to understand their real needs and not just their ‘wants’. Although the business usually measures output as a key indicator, it’s been my experience they need reassurance that progress is being made, promised business value is being delivered, and the team is meeting their delivery commitments. Often times however, management are unaware of what they need to do to help the teams be more successful and it is this particular behavior that teams need to communicate.

Simply put, these communications have three parts: 1) teams to understand the needs of the business and what makes the business successful, 2) business leaders need to understand their role in helping teams (and themselves) be successful, and 3) the teams need to find the means to meet the business’s expectation and let the business know the ‘actuals’. Sounds easy, yes?

Inception workshop planning

The best way I’ve seen to get everyone started on the same page and establishing desired communication patterns is using an Inception Workshop. You can use the inception workshop to fully communicate intentions, expectations, and create an initial delivery plan. Although an inception workshop can have many topics and areas of exploration, I would focus particularly hard on the following topics:

  1. Why we are here – the reason for this activity and our outcomes for a successful workshop
  2. Why is this important – the business goals and objectives we want to satisfy by means of solving customer problems
  3. Product Vision – developing a shared product vision that inspires everyone to achieve the business goals using the product
  4. Stakeholders Who / do – the key stakeholders both internal and external and the actions required for a successful project
  5. Empathy Mapping – a deep dive into the users, customers, or stakeholders
  6. Journey Mapping – how users, customers, or stakeholders will use our product or service (
  7. Trade off sliders – the team’s upfront assessment of what’s important and what will or will not be compromised to achieve total success
  8. Epics / Story Cards / Relative order – initial story mapping to discover or confirm the highest priority requirements/user stories
  9. Estimates / Releases – continuing with story mapping to develop a release plan. The team(s) commit to this release plan acknowledging that some information might be incomplete or unknown.

These nine steps are about reaching a common understanding of who benefits from the project and what problems need to be solved to achieve our business goals. However, more important than these two outcomes is the openness and transparency of the communications between the business and team(s). Planning your business’s next project or endeavor using an inception workshop sets the precedent of business teams and creative teams working together as one in an open communicative environment. Now the real trick is to somehow institutionalize this new-found communication pattern into the organization.

Company culture

I’ve worked in organizations where managers were expected to make decisions and be seen as leading their teams. The reality is this can be changed but it does require a lot of openness and introspection (see The Journey to Servant Leadership as an example).  To keep the open and collaborative feelings discovered during the inception workshop going, the senior business managers and middle managers might need to change the way they work. The key to business success is always knowing where you’re at. This is what needs to be continually communicated upwards, from the teams to the business managers and stakeholders. This part is generally easier to achieve than getting business managers and stakeholders to communicate their current situation and results back to the teams. Why should this be difficult?

One of the reasons a company’s culture is not opening itself up to change is the breakdown in communications. This is evidenced in high level managers aggressively stating how things cannot change and giving ‘reasons’ why this is so. Often when this happens, those wishing for change back down and accept the status quo. The following illustrates people taking positions on an issue rather than communicating.

  • Team lead to Business Manager: Can you tell me how the business is doing with our latest delivery?
  • Business Manager to Team lead: Customers seemed to be happy with the new features.
  • Team lead: Can I get their specific comments and the overall NPS?
  • Business Manager: No, sorry. That’s confidential information.

With that little dialog it’s easy to see how the company has limited access to information. The painful reality is the teams must be completely transparent to the business but the business often has policies that limit its transparency back to the teams. This is where the culture shift needs to occur. If the team is to feel fully engaged with the business, the business must fully engage with the team.

One way to overcome these obstacles is to change the dialog. The dialog above has the team lead ‘telling’ the manager what they need to do. The manager responds with a shallow summary but hides behind policy when it comes to any meaningful depth. The above dialog is just that: a dialog. It doesn’t fall into the collaborative conversation category because clearly there is no collaborative effort made by either party. Culture trumps communication.

A different approach would be for the team lead to consider the business value of their request. For example, take a look at this illustration from Michael Sahota of agilitrix.com.

What the illustration shows is a variance of culture between the team solving problems and the business people running the company. It is hard to change either of these cultures so don’t try. As I’ve talked about in previous posts, the best way forward is to work within the business’s culture and make a compelling business case for opening a previous inaccessible communication path. Here’s how that communication might go down:

  • Team lead: We’ve been getting some customer feedback at our reviews but we are having some difficulty mapping our value delivered with the actual progress in achieving two business goals: increasing NPS and increasing customer referrals. If we can get better and more specific insight on what customers are saying and doing, we can make sure we’re working those requirements that can deliver the most business value sooner.
  • Business Manager: How can you use this customer information to achieve our business goals sooner?
  • Team lead: Once we can get their specific comments and the changed NPS, we can analyse what is motivating customers to use our product. Once we have that we can groom our stories to get those stories which enhance features customers are talking about to the top of the backlog.
  • Business Manager: Ok. It’s confidential information, I can’t just give it to you but I tell you what, let’s get all the team leads together and we can review the raw data. Will that help?
  • Team lead: Absolutely. I’ll get the team leads together and we can meet here in your office at say, 2:00 pm?
  • Business Manager: 2:00 pm is good. It should take about an hour and if we need more time we can find it later.
  • Team lead: Great! see you at 2 and thanks a lot.
  • Business Manager: You’re welcome. See you all at 2.

The difference with our second example compared to the first is the second is clearly a collaborative conversation and one that resulted in potentially creating more business value sooner. The team lead has changed the conversation from one that is a request from the manager to one that is offering to serve the manager.

Summary

Communications between the business and the team needs to be collaborative and mutual. Using an inception workshop is a great way to start any project or adventure with an open, collaborative setting.

It’s also important to understand that the cultural bubble around the teams and the organizational culture are probably different. Any ongoing communication needs to account for this. When talking across cultural lines, use language and terms that are meaningful in the ‘other’ culture. In our team lead example above, the team lead used the language of better achieving business goals to break down communication barriers.

User Stories: The Product Manager & The Development Team

If you’re being Agile, …

Sorry, it’s not about Agile but about customers and customer value. Let me start again.

If you’re using User Stories as the vehicle for product creation and improvements, the product manager and development team can both be best served if they share a strong understanding of the business rational and customer problems to be solved. The user stories act as the bridge between business goals and the value the product brings to the customer for all stakeholders on the business/product team. In Scrum, the product manager is often called a product owner. Depending on your business, the product manager and product owner could two people but for this article I assume they’re the same person.

In the 2016 Scrum Guide, the role of the Product Owner is defined as the sole person responsible for managing the Product Backlogand “is responsible for maximizing the value of the product and the work of the Development Team.”

This is usually where some people get the false notion the product owner does all the work to create and maintain the product backlog including, writing all user stories. At one company, I was confronted with the development team’s manager telling me, “are you trying to make us all product owners” when it was suggested the development team could help breakdown and write user stories. This is a common misconception of what the product backlog and the role of the Scrum product owner are all about. If one were to read a bit further, the Scrum Guide clearly doesn’t want this to be a one person band; “The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

The idea that only one person is doing the work is different from one person being responsible for the work. For example, as a parent, you feel responsible for the education of your child but although you help with homework, the larger proportion of the educational tasks are left in the hands of others. As a parent, you are responsible yet trust the education of your child to trained and experienced experts. So too is the work of populating, refining, and prioritizing the product backlog.

“Business people”

“Business people and developers must work together daily throughout the project.” – Principles behind the Agile Manifesto

The business has entrusted their reputation in the Product Manager to manage a product. However, the Product Manger is not usually the sole decision maker when it comes to what to do with the product and when. Below is an insight passed on by Jeff Patton during his talk, “Top Ten Myths of Myths & Misconceptions of Product Ownership“.

Myth 1. You’re the decision maker for what product to build and when.
Reality: You generally lack authority to make decisions; you’re only the decision maker if everyone agrees with your decision.

The best Product Owners [Managers] make decisions based on a synthesis of suggestions and ideas from SME’s, Customers and Users, Business Stakeholders (CEO, Boards, Marketing, Finance, Sales), and the development team.

You’re the glue that holds SME’s, Customers and Users, Business Stakeholders, and development team together
You’re the lubricant that keeps things moving
Basically you stick and slide at the same time

(from my notes of the talk)

The product manager is not alone and gets input from business leaders, product leaders, and management. What sometimes gets forgotten is the development team. The product manager, business leaders, product leaders, and management all have a vested interest in getting the development team on-board with business strategies and goals. The development team, along with of the product manager, are the people who know the product best. The development team is not simply a partner in the business but a full-fledged member of the business team and should be recognized as such. And because the development team is made up of multiple disciplines, the advantages of this relationship is getting a diverse and unique perspective that developers, testers, BA’s and UXD people have of the product and of the customer problems to be solved.

Business decision and policy makers can choose to use or ignore any information obtained from any team member. It’s the difference between Authoritarian Decision-Making and Democratic Decision-Making; the Authoritarian makes the decision and doesn’t ask or care for the opinion of others while the Democratic Decision-Maker gets thoughts and ideas from others but still makes the final decision based on a diversity of ideas and opinions. The product manager can make the most learned decisions when provided with wide view-point of ideas and opinions.

Some points a product manager can experiment with while bringing development team members into the business decision process.

  • Builds business cases with product team, development team, marketing, sales, support, and management to achieve business goals through new product development or marketing.
  • Collaborates with one or more development team member to complete the business plan/Lean Canvas.
  • Collaborates with one or more development team member to gather technical feedback and suggestions for feature road map items and UX concept designs.
  • Provide shared vision and understanding of business attributes of road map items to one or more development team member

“and developers must work together daily”

So while the Product Owner [Manager] is held responsible for the product backlog, he or she must work collaboratively with many others to get the best product to the customers and users. A product manager works with business leaders and other business experts but also utilizes the “developers” to help. Now this is a two way street. Our manager above who asked if developers were to become product owners is not being an obstructionist but is likely supporting a business stance that roles are roles and one does not step across the abyss. Although a very traditional idea, it’s not an idea that will make collaboration and cooperation flourish in the organization. Some additional product manager role insights from Jeff Patton.

Myth 4. You work alone
Reality: Usability is generally determined through Users, UX people, and BA’s; Technically Feasible is generally determined through architects and Engineers; Business Value is generally what the Product Owner brings through conversations with customers and stakeholders.

All these people make up what is called the product team.

Most successful organization define a Product Team. Some dysfunctions of the Product Owner:
  – Don’t socialize decisions;
  – Don’t spend enough time with the team;
  – Don’t spend enough time with the customers

and

Myth 5. You create the backlog alone
Reality: Product Owner works with the product and their most important skill is leadership. Good leaders collaborate & motivates everyone; builds whole team ownership.

Product Owners give clear guidance and engage others to build & prioritize the backlog.
Product Owner not a good name; Product Manager not a good name. The role is not singular in scope or conduct.

(from my notes of the talk)

In organizations I’ve been in, the best behavior for getting the best product to customers was a result of product management and development teams working closely together. This would go beyond collaboration and reach the point where product and development shared an equal desire to deliver value to the customers in order to achieve a business goal. Of course both the product manager and development team bring their unique skill sets into play to reach a symbiosis of sorts. This kind of relationship doesn’t happen overnight and probably won’t be a painless journey, but success can happen. In one role, I was entirely unsuccessful in uniting product and development in this way but even in my failure, the two worked together in harmony, they just didn’t feel the same level of responsibility for defining the value through user stories. Of course, writing user stories is not the point, satisfying the customer is but over the years, I’ve noted development teams usually start from a technical place and need nurture to move beyond this mindset. There’s always room for improvement.

Another challenge is having the product manager to ask for or seek help from the development team, with creating the defining the business case for the product and creating/maintaining the product backlog. Consider for a moment a product manager who can’t let go of the idea that they and they alone create and build a product backlog. This most often is about trust and can manifested itself in the depth of detail of user stories written by the product manager, something that almost certainly guarantees resentment from the development team.  The breakdown in my view begins with the product manager and the development team not equally engaging with the customers and users from the start. The product managers did most of this alone without development. One way to ease the burden of writing stories is to begin introducing development team members into customer interviews, user testing sessions, and user observation sessions.

Another point of concern the product manager might have is a fear the development person might say the wrong thing in front of a customer. This is common fear and one that is not often substantiated with facts. In my view but can easily be overcome by getting the product manager and development team members to agree on behavior. Stress that the developer be allowed in the room during the interview but only for listening and note taking, at least in the beginning. This by far is the easiest way forward as the product manager and development team can build trust. It won’t be long before the product manager asks the development team member if they have any questions for the customer. Another big advantage to this is the development team member’s perspective on what the customer says. In the debrief after an interview, the development team member and product manager will probably find they interpret the same thing differently, which brings a richness to the interview missing if the product manager did it alone.

Getting the development team engaged with business cases and creating user stories isn’t often too a big issue but they generally don’t put up too much of a fight if the product manager insisted on doing it themselves. What important is that work isn’t done in total isolation with results passed from product manager to development team. This is type of hand-off is a key intersection of miscommunication. Results should instead be the result of collaboration and communication. This level of collaboration and communication needs to happen throughout the project, beginning to end, to reach the highest potential.

Some points the development team can experiment with to broaden their business and customer insights.

  • Provide technical feedback on feature road map items and UX concept designs.
  • Support (help create) and provide feedback on Business Plan/Lean Canvas.
  • Create and support User Stories to achieve business goals through new products or product improvements.
  • Provide estimates for the software components of road map items.Provide software estimates for user stories.
  • One or more development team member fully understands the business attributes of a road map item.
  • One or more development team member fully understands the customer pains and how solving these contributes to the business goals.
  • Development team actively participates in product backlog grooming sessions.