Reducing Teamicide with Lightning Bolt shaped Teams

Teamicide is the act of purposefully disbanding a team after they are done with a task or project.  While this may not sound particularly negative at first glance, an organization loses the benefit of achieving team productivity and cohesion each time they disband a team.  When teams form, they take time to gel as a team. This is an organizational investment that often isn't realized. 

To gain some perspective, let’s take a moment to review Tuckman's model that discusses the gelling process.  Established by Bruce Tuckman in 1965, this model has four sequential phases (e.g., Forming, Storming, Norming, and Performing) that teams go through to effectively function as a unit, know each other's strengths, self-organize around the work, with optimal flow, and reduced impediments.  Regarding teamicide, if a team hasn't achieved the performing state, they will have invested in the time and team building effort without actually gaining the benefits of a performing team.   The irony is that while companies focus a lot on return on investment (ROI) regarding the product, they inadvertently achieve no ROI since they disband teams and not allow them to achieve performing.   

The next question is, why does management disband teams?  Do they not understand the harm they are doing to their organization when they disband teams?  Do they not respect the benefits of a performing team?  Or maybe they apply a move the team to the work approach when they really should be applying a move the work to the team approach.  Exploring the “move the team to the work” approach, this may occur because either there is a “form a team around a project” mindset or there is a belief that teams don’t have all of the skills or disciplines needed to handle the new types of work.   

How do we solve this problem and gain the most from performing teams?  The first change is to move to (or experiment with) applying the “move work to the team” method.   This assumes that we have teams that have the skills and discipline to handle a variety of work.  Therefore, the second change is to invest in building Lightning Bolt-shaped teams. These are teams where each team member has a primary skill, a secondary skill, and even a tertiary skill. 

The shape of a lightning bolt has one spike going deep (primary skill) and at least 2 additional spikes of lesser depth (secondary and tertiary).   The purpose of having various depths of skills is for the team to be able to handle a broad range of work and for team members to be able to step up and fill gaps that other team members may not have or need help with.  Note: some have used the term “T-shaped” teams, but I find that the lightning bolt shape is more appropriate to the several spikes of skills and the various depths that are needed.  

Creating a lightning bolt-shaped team takes an investment in education.  This takes a commitment to educate each team member in both secondary and tertiary skills.  As an example, let’s say that a developer has a primary skill of programming code.  As a secondary skill, they can also learn how to build database schemas and as a tertiary skill, they can write unit tests and run test cases.  The long-term benefit is that if the team members can develop additional skills, there is a greater likelihood that a team can work on a much wider range of work and be kept together allowing the organization to gain the benefits of a high-performing team.   This can reduce teamicide and increase the organization’s ability to produce more high-quality product.

Have you seen teamicide occurring in your organization?  Have you seen the benefit of allowing a team to remain together long enough to become a high-performing team?  If so, what level of skills were or are prevalent on the team?  

Right-sizing Documentation in an Agile World

Within an Agile context, there is a focus on right-sizing documentation.  This is a response to the bureaucracy that has led to large volumes of project and product documents which are often left unread, are out-of-date the moment they are complete, and seem to have little value to the team.   On the other hand, I have heard folks who are in an Agile context say that no documentation is needed.  The truth is somewhere in between.    

One of the values in Agile is “working software over comprehensive documentation”.  This does not mean that there is no value to the item on the right, but there is more value to the item on the left.  The key is right-sizing the documentation.  Right-sizing means that the level of effort applied to write and maintain the documentation plus the value of that written document should have a greater return on investment (ROI) then not having that information readily available (i.e., the effort it would take reconstruct the information and impact of not having that information for current decisions).   With that in mind, here is some high-level guidance on right-sizing documentation. 

• Documentation should be living and evolutionary and not “sitting on the shelf”.   Move away from the notion that document is “final”.
• Consider some documentation to live at the product level where it may naturally evolve from both sprint to sprint and from release to release. 
• Documentation should take on a collaborative nature.  It should not be written by one person to perfection, and then shared with others.  It should instead be shared often during draft to gain input   
• Update your documentation continuously as new things are learned.  If you learn something that can impact the team or help with decision-making, go to the document and update it. 
• Focus on just barely good enough documentation and avoid big upfront details which typically means a lot of guessing and wasted time.   Barely good enough means document what you currently know.  If you no longer need the document, it is reasonable to retire it. 
• Be concise and lean.  Write in succinct prose and add bullet points if reasonable.  Avoid long and flowing prose which may lose the reader’s attention.
• Documentation can take many forms.  It is not only a Word document, documentation can live on a wiki, in the Agile planning tool, as comments in code, and much more
• Document decisions.  Knowing the decisions helps those who must maintain the product and understand why things were decided or done in a certain way.   
• Realize that there is a difference between internal and external documentation.  External documents may be a User Guide or document that gets delivered to the customer.  These should be considered as “working software” and follow the rules of the done criteria.    

What might get documented in an Agile world?  The major documentation comes in the forms of user stories and epics.  This includes writing the user story in canonical form, with details, and acceptance criteria.  Technically, another significant form of documentation is the code itself. It should be written in team agreed coding standards with appropriate comments that specify what the code does (or simply and clearly enough that don't need explanation) and why it was written a certain why.  Remember that code needs to be maintained so if someone has to "figure out" what you wrote and why in order to support the code, then it is problematic.

You should consider lean versions of your architecture, coding, and test strategies that help inform the team of ways of working. Impediments that require effort to fix should be documented.  Items such as coding standards, an overview of your working processes and policies, done criteria such also be documented and shared. 

What do you think of this guidance?  Do they make sense?  Do you have any other tips?

Who makes the Best Product Owner?

In one of my recent articles entitled Who makes the best ScrumMaster?, I discussed the attributes needed to make an effective ScrumMaster and what traditional roles may play the ScrumMaster best. From the feedback, those who can best exemplify the attributes of a ScrumMaster made the best ScrumMaster and it did not appear to be strongly aligned with any particular traditional role.

In this article, the focus is the Product Owner role. Much like the ScrumMaster, the Product Owner role is very important to a successfully running Agile team. In fact as teams consider adopting Agile, who plays the Product Owner is critical to gaining the benefits of Agile due to the importance of identifying customer value and enacting the customer validation activities to ensure we are building something that the customer actually wants.

What are some important attributes of an effective Product Owner? A Product Owner recognizes what customers want and translates their needs into meaningful epics and user stories (aka, requirements). A Product Owner must intuitively adapt requirements (aka, user stories) when customer needs and market conditions change, to ensure what is built and delivered aligns with customer needs. This may sound obvious but the Product Owner must have the wherewithal to ensure that the organization in which the team works in will positively support and welcome change. A Product Owner must have the attributes to be a good voice-of-the-customer (VoC) and communicate the customer needs to the Team so they can build what the customer needs. It can be quite challenging to commit time to customers and team members.  Some attributes that an effective Product Owner must have include:

• Parsing customer and business problems and turn them into meaningful user stories  
• Working with sales and marketing to get their ideas into the backlog
• Establishing a directional Product Roadmap and Product Strategy
• Understanding the business marketplace
• Understanding and interacting with the customer domain 
• Establishing effective Customer validation (e.g., end-of-sprint reviews/demos, alphas, etc.) to ensure you are building a product the customer wants   
• Understanding that it takes a trusting environment where problems can be raised without fear of blame, retribution, or judgement, with an emphasis of healing, collaboration, and problem solving  
• Facilitating and influencing the work without coercion, assigning, or dictating

So the question arises, is there a traditional role that plays the Product Owner the best? Let’s examine a few of these roles.

Business Analyst as Product Owner?

What does a traditional Business Analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders in order to understand their needs, and to recommend solutions that meets these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. They also act as a liaison between business and technical groups. It is because of the work a Business Analyst already does and in particular their focus on requirements and their liaison role between the business and technical groups that makes them a good candidate for the Product Owner role. A traditional BA would have to gain the experience in working in an Agile manner including the continuous requirements elicitation process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Product Manager as Product Owner?

What does a traditional Product Manager (PM) do? A PM examines the market, the competition, and customer needs and establishes the product direction that is considered valuable to the market and the customers therein. A good PM focuses on the financial considerations including the return on investment (ROI). In addition, the PM is involved in the requirements gathering and management process. It is because of the work a Product Manager already does particularly their focus on what is considered valuable by the customer that makes them a good candidate for the Product Owner role. A traditional PM may not have the experience in working in an Agile manner including a continuous requirements gathering process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Project Manager as Product Owner?

What does a traditional Project Manager (PjM) do? The primary responsibility of a Project Manager is to plan and execute a project from the beginning to closure. A PjM focuses on the project costs, schedule, and scope. A PjM may also help build the project objectives, help manage the requirements management process, manage project risks, issues, and dependencies. While there are some attributes a PjM brings that can help in the Product Owner role, there is very little direct customer focus which is a big part of the Product Owner role so this experience would have to be gained. A PjM may have to unlearn some "assigning work" and "driving the work" as this can inhibit the team's ability to become self-organizing.

Technical Manager as Product Owner?

I have found that some Technical Managers (TM) provide aspects of product ownership to their work. The Technical Manager may get input from Product Managers, Sales, and Marketing and then crafts them into meaningful customer needs.  While there are some attributes a TM brings that can help in the Product Owner role such as crafting a product or service direction, there may be little direct customer focus which is a big part of the Product Owner role. This experience would have to be gained. In addition, a TM will need to break from the "team are my direct reports" mindset and "assigning the work" as this can inhibit the ability for the team to become self-organizing.

Other Roles as Product Owner?
There are other roles that may be considered.  A select example are those in the marketing space (e.g., Market Researcher), service space (e.g., Service Consultant), user or customer experience space (e.g., UX Designer), and entrepreneurs. These are roles that understand the market, customers, and the continuous feedback from the customer.  As organizations have various roles in this capacity, it is worth investigating those current roles that are customer facing and understand how to translate feedback and strategy into user stories. 

Summary

IMHO, those who have played either a Business Analyst or Product Manager can become an effective Product Owner. However, anyone who has played a role where they work with customers to collect their needs and then work with teams to build products or solutions that meet those needs can evolve into an effective Product Owner. I would suggest that anyone who becomes a Product Owner (or is interested in doing so) should consider taking Agile Product Owner education, reading related books, and/or gaining guidance in this area through an Agile Coach in order to help them better understand this role and the activities they will need to perform in order to play this role effectively.