The Trust Curve as a tool to start relations

I have recently taken up an engagement that involves a project rescue intervention as the overall integration program manager responsible to bring in various technical teams and components represented from different business units (each with their own priorities & project deliverables), that when integrated together delivers greater business value as a whole (than each component servicing its own business process in isolation) - an awesome yet complicated system. The stakeholders have set high expectations, hoping to bring in some structure and alignment to the teams by setting up a program stream that would centrally command and control the deliveries - taking on the classic Steerco approach.

So I needed to setup a formal kick-off workshop, get everyone in a room together to flesh out as much as possible (review where each independent project stream is, what's to do, architecture, design, integration backlogs, etc.) thus culminating in a unified program plan. I had one problem though: I sensed a lot of tension and nervousness between the teams, there was quite a bit of history around expectations not being met, poor communications, etc. I just did not get the feeling that everyone trusted each other, there was a lot of suspicion going on. And now with this management intervention of having a lead integration program manager, people had their reservations. For me as this integration program manager, I needed to start the stream off on a good note, establishing a level of trust (that was apparently nonexistent), and get the core team leads gelling together to form the core delivery team. I anticipated a lot of tension that could surface in the main kickoff workshop, so I decided to run a retrospective prior to the official workshop, as a way to pre-empt the emotional discussions that, if left unchecked, would eventually derail the formal planning workshop.

In doing so, I started to look at retrospective tools that could help me approach the subject looking up (Getting Value Out of Agile Retrospectives - A Toolbox of Retrospective Exercises by Linders/Goncalves and Agile Retrospectives by Derby/Larsen). I also sought advice & counsel from a good friend, colleague and agile-coach-cum-mentor of mine: Farid@Crossbolt - explained my challenges, and in ten minutes, he provided excellent suggestions around team building activities as the first prize, second prize is address the elephant-in-the-room directly through a retro, where we could talk around a simple curve, call it the "Trust Curve". I settled on the latter suggestion (my original approach) of doing the retro since we just couldn't afford any time/money for the team building activity.

I have since then shown the Trust Curve to a few people, and have received some really good feedback, and hence this blog post. I want to share this simple, yet powerful picture that can be used as a starting point in setting the stage in building new relations, in an open & mature manner:

Trust Curve

The above picture tries to show the different positions of trust, that you could use to frame the conversation. Engineers understand pictures, especially a curve - that at first glance, appears so simple, yet profoundly powerful if you allow yourself to be open to critical reflection. The picture tries to show a journey of how trust will develop through a course of a relationship.

Managing software project teams through transition: Roles & Responsibilities

In this post I talk about a recent engagement with a client around settling on a framework to understand the roles & responsibilities in the development organisation. It was an activity that lasted the tune of just over 12 months to reach a point where everyone impacted could agree with the outcomes. It was really quite a journey with many individuals across the board from senior managers to engineers. The end result was a framework, based on the RACI model, that not only showed the RACI matrix, but also output high-level job descriptions for each key role, that acted as handy input to job-specs that could be tied in with people's objectives, in terms of their personal development plan for performance appraisals management.

The context that triggers this activity is in my view, quite common for any young entity that has just started on the path to software product development (the project team effectively shapes up the future direction & structure for the organisation) - i.e. their first real stab at doing in-house product development. Usually what happens is the project grows & ramps-up as required (building various teams required to get the delivery done), the project, in effect shapes up the future structure of the organisation. I've been in this story a few times already in my career: Work on a next generation concept, build a team, deliver, then re-shape the organisation to focus on this product as the mainstream focus, transforming the project structure into an effective organisational functional model...

In this particular scenario, the situation was around a new unit that was setup to deliver their first major product deployment (Set Top Box (STB) software - completely developed locally in-house), and as part of the experience, the team operated with a fair amount of autonomy for several months (experimenting with agile/scrum) finding their feet, until the business ran out of patience sensing that if things continued as is, the promise made to the business wasn't going to materialise (delayed), and so thus intervened by "management directive", almost pulling the rug from right underneath the team. The project switched focus to a highly-driven delivery mindset, where the team freedom was curtailed to a point that all technical decisions were made through a single entity, called the "Launch Director", who's only focus is to do-what-it-takes to get the product out-to-market, running with complete freedom to cut-and-chop processes (in the guise of efficiency improvements) to get the job done.

In retrospect, this was the right call made by senior leadership - a gap was identified around the lack of a key resource accountable for aligning the technical delivery, a strong driving force was required to reign in the stray streams to get them all pulling in the right direction. Going forward however, we kept the role under "Delivery Owner" to be considered for large-scale new project initiatives.

So the team came eventually out in the end, a little scarred, battle-hardened, with the product delivered to market as an extremely huge success, which would not have been possible had the launch director intervention not been implemented.

Our challenge was how to move forward, with the launch director moving on, leaving this product development team to put the pieces together and continue...

How does the team pick up where it left off? Before the switch to delivery mode, the teams were just entering a rhythm, they knew who the players were, the key project managers, product owners, technical leads, etc. Once the launch director kicked-in, most of those roles faded into the background, people overshadowed, disempowered, meant to just follow the lead, taking direction from management. Coping with this change upset the trajectory the teams were hoping to achieve with their agile/scrum intentions (whilst those sensitive to agile principles can indeed sympathise with the team, it has been my experience that even with best intentions of managers adopting agile teams, there comes a time when a delivery mindset, driven by senior stakeholders, takes priority, delivery must happen!).

So how do you fill the void, dismantle and regroup, redistribute the roles & responsibilities to a point that can sustain the teams going forward in keeping with this mindset of agile/scrum values, and ensure that when the next major product release needs to go-to-market, that they don't fall into the same operational, escalated emergency mode of working: i.e. crisis-delivery mode?? How do you prevent the house of cards from toppling down?

There's no easy answer really, apart from having loads of conversations, being patient with the rebuilding process, a lot of co-ordinating and re-enforcing repeated messaging around respecting boundaries, etc, etc. A lot of feedback loops, discussions do help, but people expect more - eventually one has to reach a point of some certainty, by taking time out to flesh out in writing, the roles / responsibilities / expectations from all.

Suffice to say that this is really a journey through transition - I've taken this particular organisation to a point that enough of a framework is in place to provide the necessary guard rails...

Note: As a consultant I share my work experiences through my writings, whilst respecting my clients, I take time to present generic descriptions that has applicability to general software management experiences. I am by no means passing a value judgement on my client, rather sharing the outcome of the experience that could be helpful to people faced with similar challenges...

The point of this post is to share the learnings of this experience, and not undermine the specifics of the project, this isn't a rant post at all. As a matter-of-fact, the result of establishing this RACI matrix and unpacking the team's roles and responsibilities, has led to the team achieving a major milestone release, without needing the previous management intervention: Between the product, development, test, integration streams, and empowerment of the Release Manager role - this team has come together quite nicely... I've actually been asked to help facilitate this RACI process with other departments within the business unit.

P.S. If you're new to this site, I write about Set Top Box software development topics. Please search through my blog for background reading on the nature & context of digital TV software projects...

Take a chance, leap, put yourself out there

I came across this graphic that resonated with me on so many levels. It also epitomizes myself to an extent, that the poster itself makes good for another "About Me" post...

More on Project RAG Status Conventions

In a previous post, I laid out some of my rules for implementing a RAG status, which when used with discipline, can greatly help in project communications especially with demystifying areas or workstreams for your project team. I would still recommend any aspiring project manager to learn about the RAG status, it has become part of project management lore, and tradition in some organisations, where people expect to see some kind of RAG. Familiarity is good, but don't be too pedantic about it!

I am not so sure about RAG any more...I've come to love-and-hate the RAG...It's a tool that I impress on my project managers to use, but I feel less inclined to use the RAG in upwards-communications. Of course, it depends...

I've been running projects for close to ten years now, starting with the usual small pieces of work, 3-6 month projects, 2-4 teams, one customer; then moving on to large teams (20+) scattered around the world, multiple projects with multiple teams, 12-24 months projects. So I've come to appreciate the softer side of management, to the extent that, RAG status is almost meaningless to people not responsible for managing projects or workstreams. You can waste a lot of time justifying why you as a project manager (PM), have settled to communicate the status using the said-colour (say Red), and that it is entirely within your right as PM to use your judgement, after-all, it is something that you gotta deliver!

Managing stakeholder expectations is key to the success of any project, ultimately the stakeholder is happy that his/her expectation has been met. This is a little challenging especially when there's multiple stakeholders who hold the same pecking order in the org structure, and are contributing teams to a unified project, multiple departments coming together to deliver a huge feature, end-to-end. Getting consensus at this level is always troublesome, do you really want everyone to buy-in to the why you communicate a project's status??  You can of course try, get them together, talk them through your flow-charts and state models, explaining what "On Target - Risk" means and why it's Amber, or what does "Slipping - Not Yet Mitigated" Red means, or "Slip but expect to Complete" Amber means. 

You can even explain how your Excel / MS Project Gantt includes the twenty odd sub projects tracking every single detail, bubbling up to each milestone, and how you run macros to determine if dates are being met, exceeded, and the algorithm you use to group individual task-level RAG items up to represent the group status of a parent milestone (and explain why you might have some Red tasks, but overall the milestone is still Amber or even Green). You could even explain your Critical Path items, PM 101 discussions, explaining why "Red - Slipping not yet mitigated" is a call to action for the stakeholders to actually do something, to help you recover things that is potentially beyond your control...

Hit Squads as a bridge to agility

If you've read some of my previous posts, you will know that I write mostly about software projects in the world of digital TV set top box (STB), broadcast headend systems, including internet TV, Video-On-Demand (VOD) and over-the-top (OTT) projects. There is a tremendous amount of software running in these components, end-to-end, from the STB device (which in itself is a complicated system), to the headend/backend server-side components.

The development teams are usually not under one roof, are less likely to come from single suppliers, with their own methods of working, their own release / test cycles. It is difficult, but not impossible, to establish a regular cadence for the overall delivery stream. Some teams may be following agile/scrum, without continuous delivery - and others prefer to work in a more staged, requirements-up-front / development / test / integration cycles.

There are cases however, where a large part of the development, test, integration & delivery teams are in-house, but segmented by classic functional organisation structures that result in silo-based mentality. I've seen this in a few places, especially when for example, PayTV operators take ownership for product development in-house. The application development team for instance may be following scrum/agile, other teams however, don't.

The situation is almost always the same in such projects: Driven by a Hard deadline. Typical development cycles until feature complete. Enter test/integration cycle (this is usually the first time you know the true status of all the key features and functional areas - expect trouble). You find out there's issues, you're not even close to being feature complete.

The deadline isn't going to move and you've eaten up your development schedule (you're now into the time to stabilise and in what should be surgical mode). Sequential processes with silo'ed teams are a hindrance - you need a quick way to uncover issues, resolve them quickly, providing quick feedback into the project stream. There's pockets of agile/scrum in some teams, but not everyone is convinced that is the way to go. You don't want to disrupt the teams completely yet at the same time promote a different style of working.

What can you use as a bridge-to-agility without getting into the whole methodology debate??

Enter the Hit Squad Team (or also known as Tiger Team) - a concept that I've used on more than one occasion. If managed well, the benefits of having cross-functional teams are obvious. The lessons you take from here are used in your next delivery project, likely to become the preferred choice of working. I've seen this transition take shape & became the norm, without having to religiously convert people to a new mindset - I've also learnt it aint that easy. As many more before me have warned, what worked for one organisation isn't necessarily going to work for others. Still though, if you're operating in a similar technology space or problem domain like STB development, it wouldn't hurt to try this out...

What's a Hit Squad then?