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?

Project Premortems

I recently ran, what was probably a first in South Africa (?) (SA readers please reply if you've seen this implemented in other companies), and definitely a first for the company in question, a project premortem. I had asked around the various stakeholders which included people with decades of working experience, and no-one had known about this concept of "project premortems". Sure, people were familiar with project postmortems (or end-of-project reviews, more recently called "Retrospectives" in agile parlance) but this "premortem" concept was an enigma, as it was to me, before I came across the concept from a book (2014 release) I read earlier this year, Scaling up Excellence by Robert Sutton & Huggy Rao. Although this book's core messages are around scaling up organisations, a lot of the findings are equally applicable to the context of running large, complex projects. In my world, I manage large technical programs that involves many separate business units, clients & third-parties, with large development teams...The idea is now seeded in the company, people are talking about it, and it was well received by some CEOs, who have started using this concept in their high-level steering meetings (awesome)...

I am a huge fan of Sutton, having first come across his work in Good Boss, Bad Boss: How to Be the Best... and Learn from the Worst and The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn't. I also keep up with his blog at work matters, follow him on twitter & listen to podcasts whenever he talks at Stanford's ETL lectures, and he is also my personal connection on LinkedIn.

As a program manager I have run various planning scenario workshops in my time, the classic risk brainstorming sessions, best-worst-case scenarios, etc - but I had never labelled the event as a "project pre-mortem", the name resonates with so many people because of their encounters with the classic project management tool of "project post-mortems". Not only the naming resonated well, the concept and implementation of this activity is in harmony with Management 3.0 concepts and practices of inclusion & transparency in agile practices. I was looking forward to changing tact, to experiment and try this out on a bunch of people (old-timers and youngsters) who are relatively receptive to new ideas and ways-of-working. It wasn't a complete success especially finding time out from a busy project that's already in motion, people came to the workshop a little skeptical, felt out-of-their-comfort zone, but nevertheless respected the process and participated as best as they could.

What's a "premortem" then?
Before I describe my custom implementation of this premortem, quoting Scaling up Excellence, Chapter 8, "Look Back from the Future", pages 264-265:

...We close with an additional twist, a mind trick that goads and guides people to act on what they know and, in turn, amplifies their odds of success. We build on Nobel winner Daniel Kahneman's favorite approach for making better decisions. This may sound weird, but it's a form of imaginary time travel. It is called "the premortem". Kahneman credits psychologist Gary Klein with inventing the premortem technique and applying it to help many project teams avert real failures and the ugly postmortems that often follow.

A scaling premortem works something like this: when your team is on the verge of making and implementing a big decision, call a meeting and ask each member to imagine that is is, say, a year later. Split them into two groups. Have one group imagine that the effort was an unmitigated disaster. Have the other one pretend it was a roaring success. Ask each member to work independently and generate reasons, or better yet, write a story, about why the success or failure occurred.  Instruct them to be as detailed as possible and, as Klein emphasizes, to identify causes that they wouldn't usually mention "for fear of being impolitic". Next, have each person in the "failure" group read his or her list or story aloud, and record and collate the reasons. Repeat this process with the "success" group. Finally use the reasons from both groups to strengthen your scaling plan. If you uncover overwhelming and impassable roadblocks, then go back to the drawing board...

How I customised the premortem for our context
As highlighted earlier, I help co-ordinate and steer large-scale projects that involve a few teams from different business units (with their own CEOs/CTOs), that must come together to develop a technical platform (set top box) and product/brand features (which is not owned by the engineering team responsible for the STB) and various operational management entities. We have over 150 people working on the project, scattered across the business. The project has been ongoing for a few months already, we've had team-wide or component-wide risk sessions, retrospectives and work was well underway. With an imminent release ahead of us, I wanted to hold this premortem with the primary focus of surfacing any issues / concerns that have either fell through the cracks, or swept under the carpet (which is often the case), ensuring we identify accountable owners for maintaining control and steering of topics to result in a positive outcome.

Leave it all behind

I have a favourite T-shirt that has imprinted on the back, the words "Leave it all behind". I came across this shirt ten years ago, when I saw it, I just felt I should get it, the slogan profoundly resonated with me on so many levels, as if it was created just for me! It became my favourite Friday casual dress to work. Ten years on, and it still remains a favourite, so much so, that my wife went out and produced a replica for me as a father's day gift. A friend recently probed why this particular tee resonates with me so much...on what level, what/why does Leave it all Behind signify - so I tried to explain to him, and now I want to share this part of me, publicly on my blog, for all to see.

Yikes, isn't this risky thing to do? Why on earth expose myself like this?

Well, one of the reasons for starting this blog, was to push me to my limits, to the edge of my comfort zone, embracing the public of the internet, being inspired by the writings of Jeff Jarvis, people (friends, colleagues, potential recruiters, clients, etc.), to experiment in this new world...

So here goes a new "About me" post...

Work-Life
If you've read other posts about me, you will have learnt that I've worked hard to get where I am today, with an almost relentless passion to push myself to the limits, to never give up, hard work, determination & grit. Part of this desire lies with my tendency to leave my past life behind, do what it takes to break-away from the underprivileged, below middle-class, above-poverty line life that I grew up in. In doing so however, I realised that working too hard all the time isn't everything, that work too, should be just left behind:

• I try not to take work home in the evenings or weekends - I leave it all behind.
• Work can wait (I generally average around 10 work-hours a day), there are other important things to consider in my life: my family, my own personal space for spirituality, and my hobbies, interests (like reading, blogging, self-learning) and my desire to experiment with new ideas to look at starting-up my own business one day.
• When I'm at the office, I give it my all, my 150% attention to detail, follow-through, focused and try to be hyper-productive. I set myself goals for each day, aim to get everything done and dusted - and leave the office switching my mind off from work.
• I learnt this the hard way. I worked on a few death-march like projects when I used to work in the UK. Worked to the point of burn out on more than one occasion, the constant is that the work will always be there tomorrow. Leave it all behind, start fresh tomorrow.
• I try to switch off from work when I'm at home, it has become easier over the years. No more do I wake up at 3AM writing up emails, planning the days work, solving problems. Although sometimes I can't help myself when I'm really passionate about an idea, but most of the time, I leave it all behind and don't let work be the focus of my life...even now that I'm a consultant and don't have the comfort of a permanent pay cheque, holidays or insurance - I still have a good night's sleep.
• Don't let things at work affect me too personally
• I once was on a project that had SLAs in place for engineers to be on-site supporting the customer in the states (LA). I was looking forward to my two weeks stint as I'd never been to America before, and I was the senior engineer on the project anyway - it so happened that at the time of this event, my in-laws made their first trip to the UK. The timing of the US Visa application didn't make forward planing any easier, so I was left with a choice of staying back and fulfilling the rights of my wife and in-laws, or leaving them for two weeks and go to America. I chose the former, choosing to Leave it all behind at work. Yes, it did take a toll at the office, my commitment was questioned, at the end of the day, another engineer went in my place, engineers are a dime-a-dozen, parents & family are priceless.
• For over two years I ran a daily morning power meeting, 9AM-10AM, with really difficult managers, characters and personalities. I fell below most of them in the pecking order, yet I had to co-ordinate, assign them actions and get updates. Sometimes there were heated debates, sarcastic remarks (this was the UK of course), I would be left drained after the meeting...I learnt to shrug it off, Leave it all behind
• Even today, I run my meetings and workshops - people show up or not, pitch up complaining about not having enough time to do real work, etc - I'm not phased. My meetings have purpose, there's always a goal with expected outcomes, I give people advance notice, time to prepare. I'm human, I do take note of comments, value feedback and take criticism to self-reflect and improve things, but my point is, I don't let negative experiences in the work place affect me when I leave the office - I leave it all behind.
• Don't get too stuck in projects, there will always be another project down the line
• On more than one occasion, I took a break from core projects by transitioning just before final launch / go-live. 
• In one instance, I had done all the work leading up to the release, the last issues needed closing out, there wasn't much to do and I didn't want to wait till the end to see through maintenance phase, there was another job waiting for me. So I left just before launch.
• Another instance, the project had taken on a few more managers that I was transitioning and handing over work to, I felt that my personal life was suffering, so had requested a month's leave to go back home to South Africa, to see family, to re-energise, and also fix a couple relationship problems. It was a difficult choice to make, I gave a lot of energy to that project, and to leave the project just a couple months before go-live and handover the reigns to other project managers, just didn't feel right...but there were other pressing matters to sort out, so I left it all behind.
• There will be other projects, my contribution to the projects is shown by the legacy I leave behind.
• A good project manager knows when to handover the baton to others, and is willing to leave a project when the tipping point is within reach, when you're confident the worst is over, and the project is on a path to completing.
• Be prepared to switch, take the risk & leap-of-faith
• I left my home country, South Africa, because I saw a brighter future for me overseas, financially and professionally. I left my entire life behind, ventured into unknown territory, alone to see what will happen - I left it all behind
• I fell in love with Dublin, Ireland - I thought I was going to live and work there for the rest of my life. Sadly, the work-situation wasn't that great, I experienced my first lay-off, which was a great learning experience. I learnt never to get comfortable, be prepared to leave it all behind and start fresh
• I decided to switch from a senior embedded software engineer position to being a junior software engineer in enterprise / server applications space. I was on the road to promotion and being a senior/lead in embedded set top box projects, I left it all behind and started anew in a new team, new product space, new domain...and I never looked back. That experience rounded me in so many ways, to the point of working for the best self-organised, high-performing team I've ever worked with.
• I had the perfect job before deciding to leave the UK, I had reached my goal of working for blue-sky, start-up like projects, the advanced technologies labs team that looked ten years ahead. Free to dream and invent new things. The competition to land that job was great. I had left management all behind and returned to coding, working on accessibility projects, doing tangible value-add stuff. Two months into the job, another personal decision materialises: to return back to South Africa, after spending ten years building up a career (and a life: had my own house, excellent relations across the business spread across four countries, kids of school-going age, good friends) I left it all behind.
• Most recently, I made a switch into being an independent consultant - it wasn't easy leaving it all behind, as I was turning down a very good permanent senior position in the company, we had just completed a major product delivery, I was set to go places...but personally, company politicking-aside, I felt I could achieve more for myself, on a personal & professional level, so I left it all behind to start afresh as a consultant, opportunities abound in South Africa, especially with the skills-knowledge-competency gaps in the country.
• Choose my own work
• I would like to reach a point where I can cherry-pick the work I take on, aspiring towards working a 20 hour-or-less work-week, to focus more on things that add value to me, leaving the rest behind.

Personal / Spritual

Part of my growing up, I knew what it meant not to have things. It thought me self-control, discipline and a sense of awareness that life isn't all that easy - sometimes dreams, desires and fantasy must be left behind because of the facts-of-life & reality of the situation (such as apartheid). I left behind my desire to study medicine because I couldn't afford to, had no money. I left behind that college dream and was prepared to work-and-pave-my-way, until an opportunity presented itself...

In my teenage years and early adult-life, I came into contact with people on the Sufi path, focusing on inner reflection and perfecting one's self. To let go of the ego, see this world as just a temporary stage, to strive to being a better human being, letting go of the ego ("Nafs"). These experiences shaped the path I would tread, to be willing to leave it all behind when required. In my years 20-25, I would seek out contentment, meditating each evening - to reach a point of being satisfied with my lot, of having just enough - whilst at the same time seeking out that balance of surviving in the world of work, and maintaining a spiritual path.

There's a saying that's attributed to Jesus (we Muslims hold Jesus in high esteem, as a prophet and messenger of God), that goes like this:

Jesus, son of Mary (on whom be peace) said: "The world is a bridge, pass over it, but build no houses upon it. He who hopes for a day, may hope for eternity; but the world endures but an hour. Spend it in prayer, for the rest is unseen"

For a while that saying struck a chord with me, and may have delayed some of the grand ambitions I'd had earlier. Nowadays, I choose not to lead such a detached life, I'm aware of the temptations but accept I have to focus on achieving as much as I can in this world, at the same time not losing sight of the bigger picture, that this life is just temporary.

What is interesting is that Islam stresses the temporary nature of life, right from the moment of birth. When a child is born, the Azan/Iqamah (call to prayer) is read to the child as early as possible. When we die, the prayer service held, called the "Janaaza" prayer, omits the call to prayer. The reason is that the call to prayer was already given to you at the time birth, re-iterating the short nature of life: you enter this world to leave this world...be prepared to leave it all behind.

I use Leave it all Behind as the trigger when praying the Salaat (form of prayer that partly entails physical actions standing, bowing, prostrating - being mindful to God) that starts off by lifting both arms up, hands to the ears - the act of doing so signifies taking all the world and pushing it behind you, leaving everything behind to clear your mind and focus on the task at hand, of being fully present for prayer...

So spiritually, you can see where my personal biases come from - which has ingrained this personality trait.

Other personal experiences that re-enforced this message of Leave it all Behind is when I chose to leave my past life of being a bachelor, with many friends, including other women friends, past relationships behind - and focus on my new life, with my wife and kids. As difficult as it was to let go of past relationships, there is more value to my preserving and maintaining my own family life....

On the practical side of things, I also try to live lean-and-mean. I try not to hoard (my only guilty pleasure is a collection of printed books and journals that keep growing and growing) stuff - if I've not used a piece of clothing, furniture, gadget, etc in the last six months or so, I get rid of it. I keep the bare minimum required for me to survive, the less baggage I have, the better to Leave it all behind...

Core competencies/behaviours for System Integration Engineers & Release Managers

I have written in the past on system integration topics, you can click on "Integration" in the tag cloud... 

It is interesting how some of the topics keep recurring throughout ones working life, recently, I've had to observe, deal, control and to an extent mediate on issues that shouldn't really have happened - this is in the area of Software Integration & Release Management, which in short, is not an easy role to take on in any project, let alone one with a hard delivery expectation with the whole world watching...people become stressed, nervous, emotional with knee-jerk reactions, etc, etc.

A major emphasis of Release Management & Software Integration/Delivery is on managing stakeholder expectations, above and below. To do this one expects a certain level of core competencies, which I believe is around these core topics:

• Great judgement when it comes to soft, people skills (be weary of pissing people off, triggering emotive responses & causing undue panic)
• Clear, unambiguous communications: knowing what to communicate & when (filter out reports, allow time for things to settle)
• Measured, personally self-motivated & control (it isn't easy being under fire all the time)

I've sketched a picture of what this world looks like, it shows just the world of set-top-box integration, it gets more intense as you go through to the worlds of end-to-end integration, where there's multiple systems involved (not just the STB), multiple customers, and way more front-line fire you have to deal with:

The picture should say it all:

• Release Managers are on the front line when it comes to committing to a project delivery timeline. They front many customers, including some senior stakeholders. Release Managers work closely with System Integration (SI), in fact, should rely heavily on the output from SI
• System Integration not only front hard timeline commitments from the Release Managers, but also, have a direct line-of-sight to stakeholders. To be in SI, you need to have competencies not only on technical toolset, but a fair amount of personal qualities, including very clear communications style, to front queries from stakeholders.
• The Development vendors are usually shielded from a lot of the fire that SI face, although these vendors must deliver quickly and resolve the burning issues in a timely manner. Some projects allow for direct access to development teams by stakeholders, however, it is not always the best strategy. SI is usually the protector and conduit, often buffering the development teams. Release Managers still manage vendor planning though.

What do I expect, as a minimum, behaviours of a System Integration Engineer??

• DRIVEN - I think this sums it all!
• Self starter, ramps up in no more than two weeks delivering value
• Grit, rigour & diligent, hardcore problem-solver
• Not easily demotivated, although big enough to seek help when truly stuck
• "To be Blocked is to admit defeat!" kind-of-attitude
• Go the extra mile to solve problem
• Be able to take a high level problem and run with it, even if the problem is unconstrained & unbounded
• Passionate about problem solving and debugging
• Clear communicator at all levels
• Works well under pressure & stress
• Comfortable with client-facing interactions
• Doesn't take "if it ain't broken, don't fix it" too literally. Expect tools, scripts to be created to add value, instead of accepting status quo
• Must grasp source code / software design patterns quickly, even if it has to be done through a process of re-engineering
• Does not have to be told twice what to do
• Dependable, ability to work with multiple tasks concurrently often with competing priorities
• Ability to work with third parties, including managing & directing external parties
• Does not depend on too much guidance from team lead or project manager
• Thick skinned to pick up on nuances of politics and management dynamics 
• Does not panic, is in control of emotions, tackles problems in a clear, calm manner
• Fully committed to delivery expectations of project, striving to keep customers happy

What do I expect, as a minimum, from a Release Manager??

• All of the above traits from SI plus:
• SENSIBLE sums it up!
• Level headed.
• Keen eye for detail, but not to the extent of micromanaging teams
• Must understand the boundaries, limits of influence (sphere of influence)
• Communications must be unambiguous - do not invite panic!
• Must be able to sit in hot seat with calm composure
• Must intervene tactfully & gracefully in conflict scenarios within the team but also more importantly with third parties / vendors
• Must be familiar with people management - take time to get to know people on the team
• Very good listening - be sure to understand what technical people are reporting / expressing, filtering out noise
• Not to escalate unnecessarily
• Be prepared to say "I am not sure, but will find out"
• Be prepared to protect the teams - avoid dictating, be cognisant that people have personal lives, and may have baggage to deal with
• Seek out guidance when not sure, speak to peers & colleagues who may have experience to help you along the journey
• Must be capable of realistic strategic planning, but not in isolation of the team
• Should have a led a team of skilled engineers of 5-12-20 people in the past with at least 3-5 years experience as a team leader
• Should have been involved with development / integration with a realistically accepted time frame (at least 3 years)
• Should have software domain knowledge in terms of best practices, even if its from other similar software systems
• Must be able to lead and manage all types of people
• Must be able to plan using past experiences & learnings
• Must use knowledge & experience of own proven practices & processes to up skill team if processes are lacking or immature

KPIs/Metrics for Set Top Box Application Development teams

I have learnt some interesting insights into the life of consulting, especially around change management, organisational transformation, leading, influencing and inspiring mindset shifts. One of the challenges is meeting a team that is on a level of maturity that is screaming out for intervention, and having that self-control to contain myself from blurting "I told you guys this three years ago! And only now you're seeing the light! You need to listen more!".
As a coach, one has to be patient, and live the journey with the team, this is okay, I accept that. And yes, it is quite rewarding to see the team come off age, mature and eventually implement, performing, if not outperforming, your own expectations.
However, it is somewhat a little more challenging to have hard delivery timeline pressures thrust upon you, knowing that a team isn't prepared yet (not at the right maturity level, will need micro managing and lots of admin/management overhead), or have the building blocks in place to not only deliver, but to continue on, post-launch with a sustainable way of working...
So the journey has to be lived and walked through with the teams, even though you as an expert know the destination already, even if it maybe 3-5 years to get there...

The story has been repeated in my lifetime a few times already: New product, one customer, hackathon to deliver, deliver, then the struggle of maintenance & support, and the rush to support new products & customers...
Example:
We start with a fairly young application development team, responsible for Java development of a Set Top Box EPG / User Interface. We try out this new thing called Scrum and aim to operate using the Scrum/Agile framework, we lack the supporting engineering tools & processes to manage quality (no real time to focus on CI, automated unit tests, etc) - we deliver against the odds to make an impossible launch happen. We hoped we'd have time to settle, fix the mistakes and improve working processes in time for the next release, but the work continues to pile on. Not only do we have to deliver subsequent releases, but now have to support other products as well, with the same sized team. Management want to hear none of "Refactor, Rework, Technical Debt" - on top of that, management decide to implement Key Performance Indicators (KPIs) as a way of measuring productivity...

This story isn't new, I've seen this repeated a few times especially with STB product development. You start with what looks like an elegant design, over promise the capabilities, a real demanding customer comes along with an insane delivery target, the elegant design gets infected with hacks, the hacks turns into product, the product launches, customer is happy, expectations are now set in stone. The app is reused for other products, the customers increase. The team size remains the same. We are asked to deliver more with the same "resources" and deliver with improved quality. We will be measured by the quality of our component delivery. This, whilst all the time, running parallel streams often with simultaneous or overlapping component releases for one or more hardware products (Zappers, PVRs, etc.) - Sound familiar?? Probably not as unique to set top box software development right??

What do you as a development manager do? You just embarked on the road to Agile/Scrum. You have a massive backlog of technical debt. Your team isn't performing at the level or maturity it should. Management is pressing on some metrics from you that you must use to justify progress towards increased productivity...

Apply MVP to any project in life or work

Courtesy of Henrik Kniberg, brilliant illustration

When it comes to product development, or any other project, nothing shows it better than this picture:

In the case of set top box products, we usually start with basic STB, aspiring to the advanced:

- Always satisfy "watch TV"

- Single tuner SD zapper

- 1+ tuner video recorder

- n+ tuners PVR

- HD user interface

- + animation

- + 3D OpenGL ES graphics

- + connectivity: USB, Ethernet

- + video on demand

- + home network streaming

- + remote management & diagnostics

- + recommendations engines

The above list is your stock standard product roadmap. To get there we always  release the basic minimum viable product, interestingly the constant expectation throughout each iteration must preserve "can I watch TV??"!

Experimenting with Visual Notes, sketch notes, inspired by Lynne Cazaly

This week I spent a five days out from work-time to attend an IBM Technical Bootcamp on MDM: Master Data Management. This is an investment in myself for my own learning and growth, in case I need to branch out into enterprise data management, leaving the world of set top box software (one day!). MDM is quite a niche bit of technology, with a lot of potential for growth, seeing the world is moving toward big data, data harmonisation and overall customer/product data governance. The market in South Africa is still small however, so I will have to monitor this one for a while...at least I came out with enough knowledge and technical understanding, including the internal architecture of an MDM system, which, a week ago, I didn't really have...

Anyway, the point of this post is really to share with you my current progress in my own journey of returning back to being creative again (I never took any art lessons or courses by the way). I have previously shared some of my sketches from childhood (left pic), which has been dormant for a long long time. Not so long ago, I came across the work of Lynne Cazaly on visual facilitation, and now I find myself quite inspired by visual note-taking, hoping to use this technique in my own facilitation workshops one day.

I am currently working through Lynne's book "Visual Mojo", as well as Mike Rohde's "The Sketchnote Handbook". I have also David Sibbet's "Visual Leaders" on my todo list once I've worked through the first two.

Inspired by Lynne's encouraging words as well as Rohde's own personal transformation from detailed note taking (which I used to), I decided to give this visual note-taking thing a shot, and use it for the MDM Technical Bootcamp. Equipped with a simple notebook, and two black felt tip pens (0.1 & 0.8 Mitsibushi Pencil Uni Pin Fine Lines which I've had for 5 years unused), and only halfway through both Visual Mojo & Sketchnotes, I took the plunge, and daring to share my very first attempt with you!

What do you think eh??

Incremental VS Iterative Development

Earlier this month, whilst paging through one of the books (Impact Mapping) on my reading table, I came across an interesting reference to an illustration that Adzic attributes to Jeff Patton, on the difference between incremental versus iterative development, which I found quite striking, and in keeping with pretty much most of my own experience in software development projects as both a developer as well as a manager of such projects. So I took out my phone, snapped it, and tweeted. Lo and behold, this quick tweet has been retweeted 74 times and favourited 36 times and counting -- no hashtags, no @anyone, so it seems the picture has resonated with a few people! 

(If you were one of the people that RT'ed, thanks!)

Here is the pic:

Attributed to Jeff Patton from Adzic's "Impact Mapping", Page 29

My next experiment is now to capture a conversation around this topic through this blog post, lets see if it drives some attention, starting with my perspective:

I favour more Iterative over Incremental, although context matters

My software development/management experience  of ~15 years is largely biased by playing in only one domain: Software & Systems development for Digital TV products: Set Top Box software (Operating System & User Applications like the EPG), and Headend Server Side products like VOD-encryption servers, IP-Streaming systems. I have tinkered with new technologies and some open source projects. 

And in all those experiences, we focused some time and energy in upfront design (iterating with experimentation) and architecture, so much so, that we focused on high level design of the core, fundamental infrastructure that would stand the test of time, with at least a five year horizon. Of course there is a lot of experimentation in the early phases, especially with trying to reach the initial point of having the broad framework in place, the pipelines roughly sketched out, as in the first block: A figure of a lady (that eventually becomes the Mona Lisa) sketched out, provides the broad vision of where we're heading towards, and then we iterate bit-by-bit in development the functionality, slowly painting the more solid picture. We could also stop at any point and consider our part done, because the essence of the architecture, end-to-end was in place, core functionality was always available. 

That is, at the outset, you can tell what the outcome was going to be, "a sketch / painting of a lady". 

With STB (Set Top Box) software in particular, there are not only well known standards that must

Vision: Mile-Wide Inch Thick?

be implemented, the market is so mature that there is a lot of prior art out there, so when implementing new features for a STB, there is really no need for discovery, it is not as unknown as say, implementing some brand new technology or disruptive feature. 

If the feature is new to the STB, you can be pretty sure the feature may already exist in some other form like a PC, tablet or smartphone, or even a webapp. Much of the STB roadmap, big-hitting features, are not that groundbreaking, hence there is no need to reinvent the wheel. In such cases, the architecture and design can be pretty much outlined upfront, and then proceed with iterative development.

I've been in many projects as this, so much so, that this has become a default way of running such delivery projects, and that's why I wrote promoting up-front architecture and design in this post. It's a personal bias, I know, it's been the bulk of my experience operating in a systems engineering domain...

So yes, I am all for fleshing out the foundation design, architecture and skeleton framework in just enough detail so we can see where we'd like to head to, and then iteratively add functionality until at such point we can say we're done...

MVP?

Looking at the Incremental stream, imagine if the first starting block was a quarter and not half: we wouldn't really know where we're heading, so with incremental development, we need to do just enough up-to-a-point where we have some kind of idea of the outcome, enough to guide us mentally to maintain some coherent view at the end. In cases of extreme uncertainty, trial and error, where you're not sure if the idea is going to fly or not, sure you can take the incremental approach. 

This is especially valuable when the product offering is new, and you're looking for quick feedback, are you on the right track, do you need to change tact, etc? So you start with what usually is a Minimum Viable Product (MVP), do the bare minimum (but fully developed according to the MVP), release, get & measure feedback, learn, adapt, implement -- loops until the product takes shape. Going this route may result in something that is not coherent at all (from where you started), looks like an amorphous blob, but still valuable as a product, because you incrementally navigated through the feedback loops and come up with something that is actually going to be used... 

I've not had as much exposure to this incremental experience as I've had with iterative development, although there is also merit in doing so as well, as you can fail early, fail fast which is especially useful in chartering new terrain...

What has been the bulk of your experience? How/What have you learnt in your own journey? Please share by posting your thoughts directly in the comments...

Review: The People's Scrum by Tobias Mayer

This month I spent some time in the company of Tobias Mayer, author of "The People's Scrum" which is a collection of writings from his blog posts, grouped into themes, that speak about ideas, topics and challenges around organisation's transformation along the scrum journey, driving home a striking message that time's are changing, a silent revolution is brewing. 

I chanced upon this book by accident, browsing some tweets on #agile, saw a picture of the book cover, and it struck me as odd and interesting. Have never heard of Tobias Mayer before, I was intrigued - decided to follow him on Twitter, and buy the book on impulse. Mind you, it was really good that I did!

Tobias' style of writing is literally quite deep: written with words of sincerity, openness and passion, he cuts to the core of uncomfortable-but-so-relevant truths. He writes with a depth of experience that is so poignant that it forces you to think hard about the course you're on, the things you just accept and take for granted.

I was taken on quite a roller coaster ride, experiencing moments of pure resonation thinking I am on the same wavelength as this guy (I'm not that weird after all, just been the odd one out in most of my workplaces), riding high, in-phase, I'm on the right track!!

Yet also, there were instances when I felt a little edgy, somewhat uncomfortable, noticeably shifting my position as I lay in bed reading at night. Stopping, putting the book aside, sleep over it. I have just started my stint into consulting, not a specific agile coach per se, it is one tool in my toolbox of consulting ;-) so it was enlightening & awakening at the same time to see what could be in store for me  personally (i.e. self-realisation of what true happiness means, does the road to consultancy end in permanent employment I wonder?) as well as professionally (much of the experiences shared by Mayer rings a bell as I've experienced similar).

Being deeply touched by the nature of this book and Mayer's genuine disclosure of personal experiences, I decided to take a chance and do somewhat of a different book review. Because the topics struck certain nerves, either resonating (fully in agreement with Mayer) or feeling of discomfort (not sure, not convinced), I thought, let me present a review based on a picture that describes these feelings - so I graphed something that looks like this:

The blue area shows the feel-good, things that resonated with me, the extent of which I agreed and was comfortable with the ideas. The red spots show the areas that made me feel uncomfortable, my level of discomfort, that either I'm not convinced, or have some personal biases that's potentially blinding me from seeing the points. On the whole though, resonation wins over discomfort.

I assessed my feelings in almost real time as I read each article - I didn't spend much time processing and deep thinking, debating or self-reflecting in too much detail. I responded with gut feel, instincts, and of course, the life/work experiences I've had along the way - take it as a rough first-cut!

Here's the detail of these comments, for each article (I've not had the time to break these into separate links yet): In what follows, read as:
Section, Title, Level of Resonance, Level of Discomfort, Comments

Achieving continuous product delivery in Set Top Box (STB) software projects: Challenges & Expectations

The story all software product development teams face at some point in their journey, not necessarily unique to digital Set Top Box (STB) software development: So you entered the product development space, setup a small team that delivered the unimaginable - you got your product out in record time. Customers are pouring in, marketing & strategy are imposing an aggressive roadmap. You've set the pace, possibly surviving through possible death-march-like project deliveries, and now you're expected to do more: Scale! You need to scale your product development & operations to support an aggressive business roadmap, the competition is intense, you're charged with figuring out how to deliver releases to market as frequently as possible in one calendar year - so you set the target of a releasing every quarter, or rather, inherited a Product Roadmap that showed Market Launches every quarter…

You barely survived getting one release to market with quite a small team, how do you scale your operations to satisfy the business demands? What behaviours and habits do you change? What changes can you make to your current practices? You must've been using some form of Lean/Agile technique to meet the original aggressive delivery, is the process that was used before enough, can it scale to get you from where you are now, to where you want to be? What are the implications of achieving continuous product release flow, in an environment, that is typically unique to Set Top Box hardware & software development?

In this post I highlight just one possible framework that cuts through all the areas involved in product engineering of Set Top Box software releases. I will not go into detail behind the intricacies of this environment (search my blog to learn about that) - instead I will map out by using a few pictures that shows the scenarios around achieving continuous product releases to market.

The pay TV space is becoming highly competitive, especially with the likes of online / OTT (over-the-top) players like Hulu, Netflix, Amazon, etc - such that traditional operators are hard pressed to up their game from providing the clunky, almost archaic standard TV experience to a more slicker user experience, offering advanced features, integrated with traditional linear services with additional services aimed at stifling the modern competition. No longer can these traditional pay TV providers release new software once a year at least, users having become used to frequent updates with new features on their smart devices every few months, people are becoming more and more impatient with bugs that go unfixed for some time…Nowadays, it is expected that set top boxes are updated with new features as often as possible. 

With this in mind, how does one structure a product engineering department to cope with this demand? How should projects be managed? What do we expect from teams? What are the implications of reaching continuous delivery? Where does a typical agile/scrum team fit in? Is Scrum even a preferred method, or do we choose a hybrid model?

[This is still very much a work in progress, made public to get feedback/advice from other practitioners out there...]

Focusing on the soft, people side in coaching agile teams

In my day-to-day work I generally impart advice and guidance to all types of teams that play a part in the projects that I run, though it seems to be from the point of a "program manager parting some guidance on development / integration topics" - it is expected from the role, not strictly being measured by the progress I make with it, considered as free-and-impartial advice. I have very recently however, landed my first official gig as an Agile coach, taking on a group of fairly young people (split into two teams, but part as one group). I was at first a little edgy with this engagement to be honest, since my exposure to date involved middle managers & team leads, whereas this involves interacting with a fairly young, dynamic & fresh "Gen Y" bunch, and to top it off, are not involved in Software / Systems engineering, instead operate at the Business Intelligence / Customer Experience process area.

I'm hoping I can share this new journey as part of this blog, so here goes. I am, by the way, the third coach to be assigned to this team, so in my first two-hour session, I decided to focus on the classic retrospective: What have you learnt to date?, What would you like to learn? What's your goals? Lets create a backlog for this journey that we can measure progress over each week?? The audience was a mixed batch of people, some having been exposed to a years coaching already, others only a couple of months, having recently joined the team.

I also wanted to touch on the people, softer topics first as a measure to break the ice, get to know everyone, and see where it goes. It turns out though, that the soft topics took the entire session, people were quite engaged, quite a few topics, comments and innuendos surfaced that pointed to deeper people / team challenges so solve in the background, at the same time, thinking about how to promote process improvements with value stream mapping, etc. I had sat in on two previous coaching sessions where we created the team's process map, that still needs to be rationalised.

In the end, we left off with a few exercises for the team to go away and come back to the next retrospective with feedback around: Team Charter & Appreciation Agreements. I also ended by asking for direct feedback for my own self-learning, reflection & improvement.

Appreciation Agreements

One of the first things I do when running retrospectives and other workshops (planning, brainstorming, post-mortems, etc) is to set the stage for the session by introducing the working agreements, or appreciation agreements. This is necessary and vital to creating an atmosphere for collaboration, openness, trust and respect. Some of people in the team were already familiar with this topic, but expressed appreciation for doing the refresher since they "learnt about it before, had never followed through and consistently implemented it in practice". The stuff that came out of this conversation was enlightening, pointers parked as exercises for the team. I covered the following key points that seems to be a common starting point for setting the scene, pretty self-explanatory: