Easy in theory, difficult in practice

Regardless of what type of work your team does, work boards can be a helpful tool. But just because they can be helpful doesn't mean they are always implemented well.

The most common mistake is when teams don't keep their work boards up to date with the actual status of work that is being done. Increasing transparency is a great way for stakeholders to understand what is going on and to increase their level of trust in teams. But if the information being presented is out of date or inaccurate, it reduces the team's credibility and increases the likelihood of these stakeholders asking for separate, redundant status updates. When a work item changes status the work board should be updated immediately. For example, if the team has capacity to pull a new work item from their work queue, the item should be moved on the board just before work actually commences on that item.

Another challenge relates to whose responsibility it is to keep the board up to date. The moment it becomes the job of a coordinator or lead to do so, we reintroduce the overhead of having someone chase team members for status updates. I have seen Scrum Masters who will take time out during a daily Scrum/standup event to update the team's work board after a team member has mentioned that it doesn't accurately show the status of their work items. Everyone on the team is responsible for updating the work board based on the work they are doing.

If the work board columns are aligned with the roles of team members, that is not ideal. A work board's columns should reflect the progressive value being added to a work item till it is complete and very rarely would this evolution map cleanly to the team member's individual roles. The Goldilocks' principle also applies to the columns. Have too few, and stakeholders may not get sufficient visibility into work item status and work items might stall for longer than desired without impediments being addressed. Set up too many and it encourages silo-thinking on the part of team members and can result in increased work in progress.

Having a dedicated blocked column is also not a good idea. Blocked is not a normal step in the evolution of a work item and by moving partially completed work items over to a separate column it can affect flow as a natural tendency of a team might be to pull more work items from the queue rather than unblocking the stalled work item. A better approach would be to highlight blocked items within their active work columns.

The next sin relates to work item aging. Ideally, once the team has completed a reasonable number of work items, they will be able to determine what is a reasonable amount of time for a work item of a certain size to remain active. If there isn't some way for the team and stakeholders to see how long a work item has remained in an active column (i.e. something other than Not Started or Done), then it is hard to proactively determine whether it has been aging longer than it should.

Finally, cluttering a work item card with too much information increases the potential for stakeholder confusion and for inaccurate data. At the bare minimum, a work item card should contain the description of the work to be done, key dates (e.g. requested, started), whether it is blocked or not, and which team members are working on it. Anything beyond this can be helpful, but also increases the effort required for team members to keep information current and accurate.

Work boards can be a powerful tool to help a team visualize their work flow, but as always, with great power comes great responsibility.

Whether you call them work boards, Scrum boards or Kanban boards, visualizing work using physical boards or online tools is a common practice for both operational and project teams.

Such boards can provide a number of benefits including:

• Helping team members to see what work remains to be done
• Giving them an opportunity to pull work items at their pace as capacity frees up
• Focusing the team's attention on blocked work items
• Providing stakeholders with a lightweight, pull-based method of understanding what's going on

But there are as many different ways for boards to be set up as there are ways in which teams do their work. And sometimes, the way a board is configured might not be optimal for the way the team works.

One example of this is the decision to use or to not use multiple columns to reflect items being worked on.

If a team has adopted the Scrum framework, is made up of generalizing specialists and is engaged in cross-functional activity where multiple team members collaborate to complete work items, then having a single In Progress column works well, especially when their work items are completed in a "small" amount of time.

But, if that same board is used by a team made up of specialists who often work solo on different work items, or where the work items take more than a small amount of time to be completed, the team and stakeholders will miss some useful information. In such instances it might be better to replace the In Progress column with individual columns representing the main steps of adding value to the work item.

Another decision is how to represent work items which are blocked due to factors either within or outside of the control of the team. Some teams will flag the work item within the column they are currently in. This is sometimes done by changing the color of the work item.

Other teams will choose to use a Blocked column and move stalled work items to that column. There has been a lot written about the evils of using a Blocked column including:

• It encourages the team to keep pulling in new work items rather than focusing on un-blocking the stalled work items and over time, the Blocked column becomes a garbage can
• Blocked is not a value-adding step in the process of completing work items

I wanted to understand what approaches were most used and ran another poll in PMI's LinkedIn Project, Program and Portfolio Management group.

Out of the twenty-six responses I received, 62% indicated they used a simple three column (To Do, In Progress, Done) board. 19% indicated they did the same but also used a Blocked column. And the final 19% of respondents indicated they used multiple columns for active work items as well as a Blocked column. No one indicated they used multiple columns for active work items with no Blocked column.

As Scrum continues to be the most popular agile framework, the majority response for the first choice is not surprising. What is surprising is that more than a third of the sample were using a Blocked column in spite of its downsides.

Context counts whether we are choosing a delivery life cycle or individual tools and techniques.

Rather than blindly adopting a work board configuration, take the time to understand what best fits the team's context and their objectives for visualizing the work and work flow.

Changing one's house meets the PMBOK® Guide definition of being a temporary unique endeavor producing a product, service or result. And like any project, tailoring needs to be considered when deciding on the life cycle, the roles, governance and practices which will be used to deliver the project.

We are in the midst of moving to a different city and just winging it is not a viable option as the complexity and financial stakes involved means that applying "some" project management discipline is wise.

Choosing our new house was a prerequisite project and one for which an adaptive approach made sense. While we had a general vision of what we wanted, we were unwilling to lock down all requirements at the onset as we were constrained by what was available on the housing market. Cost was our primary constraint, then scope and finally time. Our understanding of what we wanted evolved over the life of the project and we received frequent feedback based on our visits to different properties.

Once our house was purchased, the move project has followed a predictive approach. Full planning up front does not make sense given the high likelihood of changes so a rolling wave approach was chosen.

I have been acting as the project manager, while my wife and I have shared the role of sponsor. Co-sponsorship is rarely a good idea with most projects, but exceptions are made for every rule, and in this case, key stakeholder satisfaction trumped single point of accountability!

Given the scale and scope of the project, most decision-making has been made by the two sponsors with the exception of those which require external review or approval such as securing a bridge loan.

While we did not produce a formal charter, my wife and I did take the time upfront to discuss the who, what, where and why of the project to a sufficient level that there wouldn't be any misunderstandings later on. An integrated project management plan was unnecessary, but once our new house was purchased I created an MS Excel workbook which has been used for planning, tracking and communication purposes. Changes have been frequent and have been reviewed with appropriate stakeholders and approved by both sponsors. Work streams which have been performed by us are managed using a pull-based approach from a very simple work board.

For scope management, a simple work breakdown structure was created to identify the major work streams which were later decomposed down to individual work items. Given that a progressive elaboration approach has been utilized, certain work streams were fully defined early on whereas others have been decomposed over time.

Cost estimation and budgeting has followed a typical top-down/bottom-up approach. For example, an analogous estimate was determined for renovations and upgrades based on our past experience with our previous two houses. However, once scope decomposition of that work stream had progressed to a sufficient level, cost estimates were derived for work packages and those estimates rolled up to an overall amount. Budgeting and tracking has been done within the same MS Excel workbook as is used for scope planning.

Given the limited number of dependencies between work items, a network diagram and Gantt chart would be overkill so schedule planning has been done with a task list containing planned start/finish dates, staffing and progress information. In most cases, activities are short duration and so a 0/100 progress reporting approach has been utilized. With a fixed closing date, certain work streams have been time constrained and hence having activities start as soon as possible has been a good strategy to respond to schedule risk.

In my next article, I will cover the remaining six PMBOK knowledge areas for our home move project!

Whether your team follows a specific framework or has taken a mix-and-match approach with its practices, a tenet of agile is the use of short feedback loops to support inspection and adaptation.

Whether your team sets a regular cadence for external product reviews or they are conducted on a just-in-time basis, it is important to get actionable feedback. But conducting a review is not just a matter of bringing people together.

While there are probably more than just these ways of messing up reviews, here are seven which I’ve witnessed.

1. The only attendee is a Product Owner (or similar role representing the voice of the customer). While we expect that Product Owners are knowledgeable, their feedback is one step removed from that of real external stakeholders. The Product Owner can judge whether the product is meeting needs, but the team loses the benefit of asking questions such as “What new ideas for the product does this feature give you?” or “How could we make this feature add more value to you?“. In addition, Product Owner feedback should be received by the team on (ideally) a daily basis rather than having a special event just for that purpose.
2. Cramming too much into a review and not allowing stakeholders sufficient time to digest what they’ve seen. As teams get better at delivering, they might be able to complete more work in the same amount of time. In such cases, the frequency of external reviews should be increased so the content reviewed is less and the content covered should be organized in some prioritized order.
3. Holding a demo rather than a two-way exchange. If the only purpose of a review is to show what the team has completed, that could be recorded and provided to stakeholders to watch at their leisure. The real value of a review is the rich back and forth discussions which happen between team members and stakeholders and between different stakeholders based on what they are seeing. Using powerful, open-ended questions is one way to ensure that the knowledge sharing doesn’t just happen in one direction.
4. Having the wrong people in the review. It is almost as bad to have the wrong external stakeholders in the room as it is to have none. If personas are being used to facilitate requirements discovery, there should be representation for each persona if the content of what’s being reviewed impacts them. And because a review is a working session and not just a forum for sharing information, we don’t want to have too many people in the room either.
5. Making commitments during the review. It can be tempting for a team member or the Product Owner to try to curry favor from a powerful external stakeholder by committing to a specific product change or to a release date, but this is not the right forum for it. Desired content and target dates can be captured but the Product Owner and team should take the time to understand the impacts of such changes.
6. Open criticism of the team’s work. It is natural for an external stakeholder to get frustrated if their expectations weren’t met for the content being reviewed. Such feedback is crucial to help the team improve over time. But if that criticism is provided in an abusive manner, the team’s morale and productivity will take a hit.
7. Not taking sufficient time to analyze what was learned during a review. If we are using up valuable stakeholder time, it behooves us to use their feedback well. It might be convenient to hold a retrospective or similar event immediately after a review but this might not allow the team and Product Owner the time required to properly digest the feedback they received.

Well-run reviews are a key ingredient of building the right product for our customers, so avoiding these seven sins will go a long way to getting real value out of these critical events.

Emphasizing flow through the reduction or elimination of batching of work items is desirable but this is not always efficient or practical.

So what are some of the factors which might force us to batch work items?

Whether it is equipment, materials or people's time, constraints are a common reason for batching work.

Let's say we wanted to build a fence for a customer. While it might be better for the home owner for us to complete the full work for one section of fence at a time so that if the work spans multiple days the homeowner would progressively be receiving value, we might be forced to dig all the post holes first because we only have the use of an auger on the first day.

Maybe we are writing a software application which needs to have both English and French messages and we have no one on our team who can do the translation. If we only have access to a translation service for a week, we might need to batch the translation of all the screen messages and until that is done we can't ship the product.

Sometimes there might be a mandatory dependency that prevents completion of subsequent work activities till a preceding one is completed for the entire batch. When building a house, you would normally wait for the entire concrete foundation to be ready before we'd start building on top of it. When frosting a cake, it doesn't matter if half of the cake is baked - we'd wait till it is fully baked.

Economies of scale or a minimum requirement on how many work items can be efficiently produced might be another reason to batch work.

If I want to bake cupcakes, although the cycle time to bake and frost one cupcake is likely to be less than that of completing a dozen identical ones, the costs of wasted energy and ingredients from doing them one at a time would start to add up. Unless I have a customer who is willing to pay me that much more to justify producing single cupcakes, I'm likely to make them in batches.

This applies even if I'm trying a recipe for the very first time. While the volume of ingredient wastage would be reduced by baking a single cupcake, the benefits of baking a batch are still greater.

Or maybe I need to print some color business cards for newly hired staff from a printing agency. While there would be a per card cost, the overhead costs of setup, proofing and shipping might justify waiting till there are a few new hires rather that printing each set individually.

While some of these factors might present opportunities for continuous improvement to our delivery process, others are unlikely to be reduced or eliminated. We may wish to avoid batch work, but we do need to be pragmatic and accept that context counts.