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