Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Saturday 12 December 2015

What's your thinking style?

Pic Source: Daily Telegraph
I came across this exercise recently from one of my holiday reading, Socrates' Way by Ronald Gross, that I thought it useful to share with others.  

I have always had a personal bias to IQ testing, especially the ones when applying for a job, HR puts you through a battery of tests, aimed at gauging one's IQ / Intelligence. Google & Microsoft too, up until a few years back, used brainteasers & other puzzles to sift out candidates at interview stages... 

So I've always had a natural aversion and impatience to these tests because I didn't feel comfortable with one number to be associated as a measure of me, my whole self...and thus resisted & challenged the point of such tests for the workplace...

The IQ test was supposed to measure your capacity to think and learn and therefore predict your success in school (and the workplace). However, contemporary psychologists have debunked this whole idea of a single capacity called intelligence. You have no one but at least seven intelligences, according to Harvard psychologist Howard Gardner:
  • Linguistic intelligence
  • Logical-mathematical intelligence
  • Spatial intelligence
  • Musical intelligence
  • Bodily-kinesthetic intelligence
  • Intrapersonal intelligence (knowing yourself)
  • Interpersonal intelligence (knowing other people)

Simple Exercise to pinpoint some of your Strengths

Circle/Note the numbers of these descriptions that you fell apply to you:
  1. You easily remember nice turns of phrase or memorable quotes and use them deftly in conversation.
  2. You sense quickly when someone you are with is troubled about something.
  3. You are fascinated by scientific and philosophical questions like "When did time begin?"
  4. You can find your way around a new area or neighbourhood very quickly.
  5. You are regarded as quite graceful and rarely feel awkward in your movements when learning a new sport or dance.
  6. You can sing on key.
  7. You regularly read the science pages of your newspaper and look at magazines on science and technology.
  8. You note other people's errors in using words or grammar, even if you don't correct them.
  9. You often can figure out how something works or how to fix something that's broken without asking for help.
  10. You can readily imagine how other people play the roles they do in their work or families and imaginatively see yourself in their roles.
  11. You can remember in detail the layout and landmarks of places you've visited on vacations.
  12. You enjoy music and have favourite performers.
  13. You like to draw.
  14. You dance well.
  15. You organise things in your kitchen, bathroom, and at your desk according to categories and in patterns.
  16. You feel confident in interpreting what other people do in terms of what they are feeling.
  17. You like to tell stories and are considered a good storyteller.
  18. You sometimes enjoy different sounds in your environment.
  19. When you meet new people, you often make connections.
  20. You feel you have a keen sense of what you can and can't do.
If all three descriptions of these trios apply to you, you probably are strong in that intelligence, even if you haven't cultivated it:
  • 1, 8, 17: linguistic intelligence
  • 6, 12, 18: musical intelligence
  • 3, 7, 15: logical-mathematical intelligence
  • 4, 11, 13: spatial intelligence
  • 5, 9, 14: bodily-kinesthetic intelligence
  • 10, 16, 20: intrapersonal intelligence (knowing yourself)
  • 2, 10, 19:  interpersonal intelligence (knowing others)
When I did the exercise, I'd circled: 1, 2, 3, 7, 8, 9, 10, 13, 15, 16, 18, 19, 20.

Bringing it to the workplace

I have come across the Socratic Method which was used by Eli Goldratt in his Theory of Constraints books (I've got one last book of his to read), and hence started to study the method in more detail, to learn and adapt my own way of thinking, apply the methods to my work and life situations, and use it as tool in my day-to-day consulting engagements and coaching sessions. The agile coaching community also refer deeply to the Socratic Method of asking questions, not providing solutions - and it all starts with knowing one's self. If you know yourself, then you'll be aware of your own strengths & weaknesses, as well as being able to at least relate to others.

In the workplace, we often work with teams - and in the agile methods - we aspire to work in self organising, cross-functional teams. As a leader (Scrum Master, Manager, etc.) it is essential to know the dynamics of the team, right down to individual character strengths and motivational values...why not try this exercise with your whole team?? It's bound to shed new light on things?

Wednesday 11 November 2015

Review: Agile! The Good, the Hype and the Ugly

In October, I spent some time in the company of Bertrand Meyer, author of "Agile!: The Good, the Hype and the Ugly". This book was written to be an independent, impartial and objective study of the various agile methods (scrum, xp, lean, crystal) viewed against the knowledge-base of software engineering methods and principles. The author, being no stranger to software engineering, is well-known in the computer world, across both academia and industry. He took it upon himself to do the research, investigate the agile landscape breadth-and-depth, probing assertions, practices, principles and values using a scientific (and empirical) approach with searching questions, thus providing an overall assessment. This wasn't purely an academic exercise, Meyer walked the path of agile himself, is even a certified as a Scrum Master, his team are using selected methods of agile in their own product development, so it's not like Meyer is throwing the baby out with the bath water! On the contrary, Meyer tries to remain objective, unbiased and fair in his reporting and analysis.

This book may just as well be the first book to read if you're a software manager, entering the agile-space, who's potentially feeling uncomfortable with perhaps some misplaced(?) "baggage" of software engineering, old-school-style projects, as touted by some agilists. Meyer has done almost all the background work for you, covering and assessing the popular agile methods in play today.

I was quite intrigued by the book's title, who wouldn't be!!?? You must admit it is quite EDGY, axe-to-grind, in-your-face-daring-the-agile-pundits - agilistas. I just HAD to get my hands on a copy, I actually waited a long time to buy this book (due to the bad Rand/Dollar exchange rate). I have voraciously read most of the popular books on agile (Schwaber, Cohn, Poppendieck, Rubin, Appelo, Pichler, Derby et. al, you name it), that extol this new thing "agile", often claiming a silent revolution is coming to overtake the industry, that "Software Engineering" should belong to the annals of history, and instead welcome "Software Craftsmanship" as in.  And when I read these signature-series books, I do get caught up in the rush-of-it-all, excited, converted and have actually been a promoter for #agile for ten+ years...I was caught hook, line and sinker!

Then when I came across "Agile! The Good, the Hype and the Ugly" written by a person very well respected in the industry, I had to ask myself, if I may have actually fallen for some hype, maybe I didn't ask probing questions, without having empirical data to substantiate claims. I wanted to find out if I was potentially backing the wrong horse, wanted to check some of my own values, personal-biases or not, of software engineering experiences held weight or not, but most important, the title being so catchy, I was rather curious to find out what the "Hype & Ugly" bits of agile this book claimed were...

Since my background in software is in embedded systems (Set-Top-Box systems) and highly-available-systems (Real-Time-Streaming/Encryption-Services) I grew up with the scientific engineering mindset (BSc. Electronics Engineering & Masters Computer Science), so I often found myself being selective with vanilla Scrum and had in the past, cautioned people against following a particular agile method with extreme dogma, i.e. I maintained a certain amount of discipline and structure was always needed. This is primarily because of the particular domain-experience I was coming from, which wasn't high-level application non-critical development (Mobile apps, WebApps, Websites), or application development that relied on a stable SDK/engines (i.e. the expectation of a stable operating system, database, etc upon which to build applications on top of).

This book, in my view, should be essential reading for any software manager, looking to understand agile methods before diving head-first into a vanilla, textbook-implementations.

For people convinced about agile to-the-letter, this book will be a little edgy for you - one needs a cool head, and openness to accept some of the challenges that Meyer puts forward, especially when it comes to backing up assertions of values/practices/principles or citations of productivity-gains, without sound scientific and empirical data to back up those claims.  Meyer highlights such challenges from some of the books that I myself have held in high esteem for many years, so take it on the chin...

Meyer's style of writing is somewhat academic, factual, but also practical with some nerdy-humour thrown in-between. Meyer has written with sincerity, remained as open-and-unbiased-as-humanly-possible, and made a conscious effort not to promote his own personal projects, products and frameworks. Meyer cuts to the core of uncomfortable-but-some-relevant truths, especially challenging assertions and statements that lack scientific validation, or backed up by empirical studies. He writes with a depth of experience and passion for practical software methods that it forces you to think hard about the course you're on, the things you just accepted and may have taken for granted (e.g. forgoing necessary engineering practices such as a little bit of design up-front to support changing requirements).

You have to be patient with Meyer as he unpacks in some surgical, analytical detail the various topics, in fact, the selling point of the book's title, is actually left right till the last chapter, so you have to read from start-to-finish, because the essence of the Hype, Ugly, Good & Brilliant is saved for the end (building upon his arguments and case-points from the earlier chapters).

I was taken on a roller coaster ride, experiencing moments of pure resonance thinking I am on the same wavelength as this guy riding high, in-phase. 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, to sleep over it. [I am two+ years into consulting as a Systems & Software Engineering Management consultant, doing the odd agile coaching gig here and there, advising on agile systems processes - and here is Meyer taking issue with consultants!]

In keeping with my deep-review style for special books - topics struck certain nerves, either resonating (fully in agreement with Meyer) or feeling of discomfort (not sure, not convinced), so I graphed the below curve, which is how I resonated with Meyer's assertions in the last chapter, specifically the edgy bits: Meyer's UGLY & HYPED assertions:


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 amber 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, resonance wins over discomfort.

[Aside: Here is Meyer's blog post introducing why he wrote this book, you'll find detail about the book's table of contents too]

Here's the detail of these comments, for each topic - In what follows, read as:
Title, Level of Resonance, Level of Discomfort, Comments

The Bad and the Ugly parts of Agile

Tuesday 27 January 2015

To Ringfence or not to Ringfence?


I have been running systems & software engineering projects for some years now, the topic of "ringencing" teams seems to be quite a recurring one. It often comes up during the early stages of startup/initiation, or later into the project when stakeholders get quite nervous and edgy when the project begins to show signs of being in distress (i.e. the launch or completion trajectory doesn't look so good). One of the natural instincts for such management teams is to tighten up control, for example to ringfence all people with central command control within one single delivery team.

So what does it mean to ringfence anyway?

According to Google, enter "define ringfence" gives you:
ring fence
noun
noun: ringfence
  1. 1.
    a fence completely enclosing a farm or piece of land.
    • an effective or comprehensive barrier.
      "he did not say when the merger would be completed or when the ring fence would be abolished"
verb
verb: ringfence
  1. 1.
    enclose (a piece of land) with a ring fence.
  2. 2.
    BRITISH
    guarantee that (funds allocated for a particular purpose) will not be spent on anything else.
    "the government failed to ring-fence the money provided to schools"

I have been on both camps: first as an engineer being assigned to support a project/customer; and later as the manager driving ringfencing agreements with vendors.  As a software engineer, I didn't fully appreciate being assigned to a customer "You will work on only Customer A and nothing else. If you don't have work to do, speak to the customer project manager. We are getting paid exclusively to support this customer, so when you need to fill in your timesheets, we need to know in detail the tasks being billed for. Any item not having direct relevance or is not a direct requirement for the customer will not be billed for". In the product services development business (which is where I spent the bulk of my software engineering career in), this isn't strange at all. Teams get assigned to customer, we work at the behest of the customer, taking work requests in via the customer delivery manager. It does get a bit more challenging though, when your product on offer is actually designed in such a way to be generic with some customisation, such that you only need just one core development team to satisfy, simultaneously, the requests from multiple customers (at the same time), in which case, a ringfenced team makes less sense...but hey, we're being paid to do the work, without the customer, our product is not going to sell, so if customers wants a ringfenced team, we'll give 'em ringfenced teams ;-)

Later on in my career, I started managing software product development, as a team of product development managers, we were often faced with the requirements from customers to guarantee "resources" to their projects. So during the initial start-up, planning & contractual negotiations, we would roughly estimate the project's backlog, and the impact on resource headcount, guaranteeing the customer will have X number of heads ringfenced for the entire duration of the project. The customer would have first right of refusal if and when a situation arose that we'd need to support new customers, or share development work amongst other projects, at the risk of reusing some of the people originally ringfenced and committed.

As a team responsible for product development, the whole point of having a common core product, is that we can easily reuse the same product, with minimal customisation required to deliver on multiple customer projects. Take for example, the business of set-top-box (STB) middleware or the STB application that we sold to many a Pay-TV operator. Using a common product development team, one team would support multiple customers, via one product release. In the case of STB application, if designed correctly, the major differences lay in the look and feel, and custom business logic workflows, the engine components were essentially the same. So we, as a product development team, could with reasonable confidence, guarantee to customers A/B/C, that from a development perspective, the need for a ringfenced team is really undesirable, causing us too much pain - which I will go into later.

However, on the other side of the fence, more recently, I now sit as the customer! When donning the hat of the customer, I am just more comfortable when I have better control, ideally all control! If I'm guaranteed a ringfenced team, the "resources" are totally under my control, focused and dedicated to my delivery. After-all I am paying the vendor to deliver, and I want total control of the delivery team. The better control I have, the better chances of delivery....plain and simple, accepting the challenges being placed on the development teams. What helps is that although I can be the hard customer, I do have a pretty good idea that the development vendors can overcome their perceived challenges and difficulties with the ringfenced approach, because, I myself was in the trenches and made it work. So I often find myself explaining component-architecture and single trunk-codebase management, multiple release streams management, to the technical teams.

And really, when you pause for a moment, and think about the big picture - you just have to appreciate both sides of the argument. The customer wants more control as this will help him/her sleep better at night, the development vendors would like to be left alone, trusted to deliver their product, as they know best how to run their development streams. Trust, however, has to be earned, and I as the customer, need to have a very good relationship with the vendor, as well as the vendor must have proven itself on more than one occasion, that they can come to the party and deliver...If there's been some turbulence in the past with non-delivery, you can be sure that I, as the customer will insist on the ringfenced team (the voice of the software engineer inside me head is silenced by reality of business needs)...In the end though, Delivery always wins!!

Let us look at an illustration the essentially captures how I approach this subject of ringfenced teams:

Saturday 22 November 2014

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.

Tuesday 21 October 2014

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...

Friday 5 September 2014

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?

Tuesday 2 September 2014

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.

Friday 25 July 2014

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...

Sunday 20 July 2014

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??"!


Saturday 21 June 2014

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...

Tuesday 27 May 2014

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

Monday 19 May 2014

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...]

Sunday 4 May 2014

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:

Thursday 17 April 2014

Use Root Cause Analysis (RCA) in Sprint Retrospectives to Improve Quality


A couple of years ago, I wrote an exhaustive piece about how software and systems projects need to focus on effective quality management across the board, covering in some fair amount of detail the various aspects to quality management, drawing on the experiences from a past project of mine as a case study.

In that paper, I closed by touching on how we, the management team, used as an intervention to improve quality of releases, by injecting Root Cause Analysis into the project stream, by embedding a Quality Manager as part of the team (~250 people, 20 odd development teams), whose role was to monitor various aspects of quality, covering escaped defects, quality of defect information, component code quality, build & release process quality, etc. This manager met with component teams on a weekly basis, instigating interventions such as code reviews, mandatory fields to input information into the defect tracking (for better metrics / data mining), proposing static analysis tools, and so on. The result of this intervention saw a marked improvement across the board, right from individual component quality to final system release quality. This was a full time role, the person was deeply technical, very experienced engineer, and had to have the soft skills to deal with multiple personalities and cultures. Because we were distributed across UK (2 sites), Israel, France, India (2 sites), we had in-country quality champions feeding into the quality manager.

In the above-mentioned project, for example, we ended up with something like this (at a point in the project, Release 19, not the end), the snapshot shows progress over 11 System Releases, capturing 33 weeks of data, where each release was time boxed to a three week cycle:

Starting off, in order to do a reasonable job of RCA, we had to trust the quality of data coming in. Our source was the quality of defect information captured in the defect tracking tool, Clearquest. The stacked bar graph on the top of this picture shows how we measured the quality of defect info: Dreadful, Poor, Partial & Good. The goal was to achieve Good, Reliable defect information - over time, through lots of communication and other interventions, we saw an improvement such that there was barely any track of Partial / Poor / Dreadful defects.  The radial graph shown in the bottom, measures the trend of root causes per release, and movement of causes from one release to another. At the end of Release 19, we still had some "Design" causes to get under control, but we'd seen a substantial improvement in the level of "Coding", "Architecture" & "Unknown" issues. For each of the causes, the team implemented interventions, as described here.
In this post, I drill down into a component development team that's only just starting with agile / scrum, to show how the team can adopt similar Root Cause Analysis (RCA) principles in managing the quality of their own component delivery, by leveraging off the Scrum Retrospective as a platform to implement an Inspect & Adapt quality improvement feedback loop. 

Thursday 13 March 2014

In search of low hanging fruit following on from high level retrospective

In my previous post I shared the experience of running a retrospective with a management team who are finding it quite a challenge to maintain a coherent team together that's needed to deliver on an aggressive product roadmap. 

The outcome of the initial sense-making workshop highlighted what in essence, is a longer term vision and strategy for the team, and could be used to establish the goals for this particular team (check out an earlier post on Agile goals). The workshop has indeed left the management team a little nervous about jumping straight in and tackling the BHAGs (Big Hairy Audacious Goals), and felt that we should instead start addressing potential low-hanging fruit first. Of course, this is a natural reaction to change, but not entirely unreasonable. Recall the scorecard assessment shown on the left.

To jump in an solve the "Efficiency of Team Structure" problem is bound to be quite disruptive, especially when the teams have just started experimenting with some internal improvements on their own. Added to that, the department structure that's currently in place, doesn't lend itself well to having fully cross-functional teams. Added to that, some department managers have yet to settle between themselves the expectations & services provided by each area. We can clearly see how going agile puts pressure on traditional segmentation of departments by role, e.g. Development vs Systems Integration vs QA, etc.

Personally I've been advocating for a single, unified, cross-functional team approach for some time, but have faced the classic resistance from managers because its new territory, not really been done before, alarm bells ringing. This hasn't been made easier by the surprising rapid increase in headcount and growth of all the departments, dealing with multiple projects and platforms, that the guys just didn't have time to sit back, and discuss overall strategy & direction for each service area.

We continued to plough ahead, this time, going back directly to the foot soldiers in all teams, where each manager was asked to hold internal team retrospectives, addressing these three questions:

  • What are your current top, pain-in-the-ass issues, your most frustrating bug-bear?
  • What do you think the Root Causes are?
  • What would be a potential solution to the problem?
The topics again sparked some interesting conversations, some people also took feedback quite personally, people came up to me afterwards and shared their emotional frustrations. It is interesting how the different managers and their teams respectively, have different perceptions, expectations and understanding, yet people still tend to work be working together as a team, on the surface. The point of these retrospectives is to highlight these hidden topics, feelings & emotions are quite important. People need to feel comfortable sharing their experiences and opinions, without being intimidated by fellow peers, we also don't want peers to start defending themselves. Lets just get the issues out in the open, and start to process them in a systematic way.

The low-hanging fruit that came out from this: Improvements in Pre-Planning, Improving Control in SI (System Integration). Interestingly, these areas map nicely into the scorecard assessment that encapsulates the eventual goals, covering: Quality of Planning and Level of Control, no surprises there.

As the neutral facilitator, who's run a few of these workshops over the last year, the following is quite evident:

  • Different perceptions & understanding what's required from an Agile Project, including misplaced assumptions
  • Lack of clarity about the department's new structures, understanding the difference between Development, Delivery including quality
  • Clash of expectations (where does agile fit in, when to switch to traditional SI model, etc.)
  • Sentiment of lethargy or inaction - most of the improvement actions have been identified before, but no-one has had time, or had taken ownership of driving the improvement, no follow-through
  • Bigger people, softer issues around team camaraderie
The journey continues…
Above & Below: Outputs from the session


Monday 10 March 2014

High Level Agile Retrospectives: Sense making with the management team


In my previous post "Will the real product owner please stand up?", I sketched the scenario where a
development team is pressed to flex and adapt to product roadmaps that tend to be generally quite aggressive, where a roadmap is generally accepted as template for driving the delivery plan and so the expectation is set at the highest levels of business, which means the team must just get on and deal with it.

This scenario is typical of many software product teams, where the success of the initial product launch was due to a Herculean effort of the entire team, the product gets out on time; and that original pace of delivery then sets the scene & the tone - the precedent is set such that people have the expectation that the team can pull it off again and again.

This is all well and great since the team has inspired confidence that they are committed and can indeed deliver. Little of the legwork and thrashing that went on internally in the development team is known to the business stakeholders, the team would still love to commit to the roadmap, but are quite edgy about the reality and implications of doing so.

We are faced with the classic problem of scaling, the notion that "What got you here, won't get you there!" scenario unless something changes - but people are nervous about abrupt changes, because the teams are currently working through their own internal improvement plans that first need to be seeded for a period of time, reviewed & then evaluated, before committing to subsequent changes into the feedback loop. 

As an Enterprise Program Manager, it is my job to put a high-level plan together that shows the stages of delivering on the product's roadmap. I become comfortable with doing this planning as long as I have confidence in the development & execution processes of the impacted delivery team. Unless I have confidence that the teams understand what's expected, that they have a reasonable processes / template for execution, I will not put my name against a delivery plan, that I know is close to impossible to achieve. 

So I roll up my sleeves, don my consulting hat, and try to facilitate conversations with the development & delivery team. In this post, and the series that will follow, I share my journey with a management team that face interesting challenges with balancing the delivery expectations of the business on the one hand, and growing their young agile development team on the other hand, by applying systems thinking tools of sense-making, to better understand the challenges that await.

I work with the mid-senior managers only, expecting the respective managers to have held internal team conversations before-hand, bringing all their team's issues to the table with the rest of their fellow management peers. Despite the team adopting an Agile/Scrum mindset, it is quite interesting to note that the "one-team approach" is really quite difficult to achieve in practice.

I share the results of the first sense-making workshop, that was guided principally around answering these two questions:
  • Given your current way of working, how much confidence do you have in achieving the roadmap?
  • What ideas can you suggest that we should look into, that if we implemented now, could help us to get close to achieving the roadmap?
Interestingly enough, to my surprise, the answer to the first question was a resounding NO! The team had little confidence the roadmap could be delivered upon, not even a Yes from the product team!  The second question generated some interesting ideas that sparked some healthy dialogue. Upon reflection, it turns out that our problems aren't that unique, sharing quite a lot in common to all development stories you read about. More interesting is that the ideas were not new topics for the teams themselves, showing that how teams can get stuck-in-a-rut, dealing with the everyday pressures that take higher priority over implementing and driving changes. Despite having many internal retrospectives, the same topics were brought up, showing clearly a lack of championing and initiative from within the various teams. Without such initiatives emanating from within the teams, how can management not ignore this, and not take the top-down approach to managing??

Technique used in the workshop
I facilitated the retrospective workshop, playing the impartial neutral person. The people involved were a mix of middle & senior managers spanning product management, software development, systems integration, agile managers, business analysts and quality engineering.  The idea generation workshop lasted two hours, followed by an hour session the next day for sense making. 
I used the concept of "Rounds" where each person gets a chance to speak & offer comment without interruptions. The rule is that everyone must respect each other, no interruptions, and strictly no challenging views - the place must be a safe one where people can speak freely without being afraid of fellow peers or line managers (tricky since it was during performance review time!). Following the initial ideation workshop, the second session was around applying Systems Thinking tools to unpack the ideas.
Systems thinking is around gathering the data into themes, looking for common traits, allocating a main topic by describing the term as a variable. For example, topics touching the subject of "Quality" is grouped as a variable "Level of Quality". Once these variables are identifying, we look for patterns of influence: How does each variable impact the other?? We look for relationships between the variables, using what is called an "Inter relationship or Network" diagram. From that we generate a Scorecard that shows us the core driving variables. From the scorecard, we assess and estimate the amount of effort we're spending in each area. Once that is known, the ones with the least effort, are usually candidates to immediately improve on.
Index cards, stickies and posters are used throughout the workshop.