A pilot project is not always the best way to start your agile journey

Many of us would agree that when you are trying to implement a large change, start small. Just as it is easier to swallow a small pill than a huge one, the ability to adopt and sustain change is often simpler when the change involves baby steps.

This approach of small incremental changes applies to agile as well. For example, the improvement experiments which a team identifies during a sprint retrospective should be small to provide quick feedback on whether or not it they are worth pursuing further.

But when I read a recent HBR article by Ron Ashkenas and Nadim Matta on challenges with scaling a successful pilot project, it reminded me that this principle of starting small may not always work with agile transformations.

In the article, the authors listed some key challenges with successfully applying learnings from a pilot project to a larger context including:

• Reluctance from the mass market of stakeholders who are being asked to work in a different manner if the target audience for the pilot is those stakeholders who are likely to be the most receptive to the proposed changes. This is a “crossing the chasm” problem.
• Avoidance of organization blockers or impediments is relatively simple in the context of a single project but is geometrically more difficult as the scope of the change increases.
• Struggle in trying to lift and shift practices and learnings from the pilot project to the varied contexts of multiple different projects.

To this list, I’d add one more.

The primary source of delivery uncertainty to most knowledge-based projects is the predictable availability of the right people with the right skills and the right time. With a pilot, it is possible to stack the staffing deck in our favor by pulling skilled people out of their normal roles to work on the project.

If we don’t replace those staff with temporary backups, it impacts the capacity of each of the teams they were part of and likely won’t improve our relationships with the leaders of those teams. But worse, when the pilot project is over and we start patting ourselves on the back for the improved delivery outcomes, the main reason things went well is not because we were agile, but because we allowed people to focus on one work stream rather than engaging in their usual level of multitasking. When we then try to expand our rollout to multiple projects, the results are less promising because we haven’t addressed how much concurrent work we are taking on.

This shouldn’t discourage you from taking a pilot project approach with your agile transformation, but before promoting the learnings from that pilot, address fundamental work management issues first if you wish to achieve sustainable delivery benefits.

Building virtual teams starts with effective kick-off meetings

Remote teaming is not a new concept but physical distancing restrictions have forced many project managers who had never previously worked with teams of dispersed team members to quickly adapt. While this transition might create a few hiccups with a well established team it will be much more challenging when we are working with teams whose members have never worked together. In such situations, the forming, storming and norming phases can take much longer than it was with the “old normal” but your key stakeholders are unlikely to accept prolonged delays in the team becoming productive.

Culture is defined by all of the individuals who make up the team but what you do as their leader will heavily influence how team development goes.

And this starts with an effective kick-off meeting. If you had run kick-off meetings as a mere formality before, their importance is much greater now.

An effective kick-off meeting helps by:

• Giving each team member a good understanding of the purpose behind the project. It can also be an opportunity for them to ask questions to help them understand how the project’s purpose can connect with their own. Remember that working on activities in an isolated manner without having a good idea of why we are doing this will reduce intrinsic motivation.
• Providing a chance for team members to get to know one another. Ice breakers are one way to do this, but a kick-off meeting is also a good chance to ask everyone to share their fears, uncertainties, doubts and assumptions about the project. This sharing will be a good first step towards building psychological safety within the team.
• Helping the team to develop an initial set of working agreements. Remote work amplifies misunderstandings and missed perceptions. Making decisions such as when to meet, how they will keep you in the loop as to what is going on, how they will work through interpersonal issues will be dealt with and how feedback will be provided won’t eliminate conflicts but it will provide the team with some self-defined guardrails to guide them.
• Learning each team member’s development objectives. Well-run projects provide a great opportunity for personal growth and if you have some idea of what each of your team members is interested in learning, then you can help them by aligning project activities with these learning goals.
• Modeling behaviors you expect other team members to practice. This means focusing more intently on what is being said than you might have with an in-person meeting. Put your phone away and close all other applications on your computer – be mindful, and be present.
• Walking team members through the use of the normal communication tools including appropriate usage and what should be used for communicating in which tool.

Building a new virtual team won’t involve doing something radically different or new compared to what you would have done with a new in-person team, but you will need to focus more effort on certain activities.

 

Thriving at the Edge of Chaos – a review

Over the past couple of years I have regularly heard companies, their portfolios and even individual projects referred to as Complex Adaptive Systems (CAS). With a CAS, understanding of the individual components does not convey an understanding of the whole, and reductionist thinking which can work so well with simple or even complicated systems is of limited use.

Given this, I felt it was somewhat timely when I was invited to review Jonathan Sapir’s new book, Thriving at the Edge of Chaos – Managing Projects as Complex Adaptive Systems.

In the first half of the book, Jonathan does a good job of covering the challenges we face when trying to apply traditional planning approaches to complex projects. His differentiation between complicated and complex contexts, the importance of systems thinking and his walk through of the Cynefin framework make these sections a good primer on the subject.

Whether it is Ian Malcolm’s quote about non-linearity from Jurassic Park, the old joke about the drunk looking for his keys around a lamp post, or the analogy of a fence and treats for a dog as examples of boundaries and attractors, Jonathan provides many quotes, analogies and examples which all help to make a complex (no pun intended) topic approachable for most readers.

A number of the principles he covers in the first half of the book will resonate with both agilists and anti-fragilists including:

• Self-organization
• Simple rules
• Encouraging emergence of solutions
• Preserving optionality
• Distributed control
• Rapid feedback

I liked his guidance that operating at the edge of chaos is where modern organizations should strive to be as excessive control leads to paralysis and eventual obsolescence whereas a lack of any guardrails will often result in chaos. Uber is frequently referenced in the book as almost a “poster child” for living on the edge, but I found the inclusion of Cemex and how they overcame the challenges they were facing in a traditional industry more appealing to me given that the majority of organizations are not founded to disrupt an existing business model.

The second half of the book covers Dr. Eli Goldratt’s Theory of Constraints (ToC) and focuses heavily on its application in Critical Chain Project Management (CCPM).

While CCPM provides good solutions for dealing with common scheduling issues, I did feel that the book could have delved deeper in terms of applying ToC and other models to addressing some of the non-scheduling concerns caused by CAS. There could have also been some guidance provided for leaders who face the challenge where there are multiple resources who are all equally constrained. ToC works well when there is a single bottleneck but with multiple equivalent bottlenecks what should we do?

The following qualifier from the Introduction also raised some concerns: “This book applies primarily to repetitive, as opposed to one-off, never-to-be-done-again projects. It does not apply to software development projects that use agile methodology.” I would argue that some of the most complex projects we have to deliver are highly unique. Also, while many of the ideas shared by Jonathan are already incorporated in agile methods, these approaches haven’t fully solved CAS challenges and the book could have addressed those.

If we accept that complexity is going to continue to increase in delivery, Jonathan’s book provides a solid grounding on the subject and I hope that a future revision will address some of the opportunities I’ve raised.