Archive

Monthly Archives: November 2011

Software Kitchen Nightmares

[From the Archive: Originally posted at Amplify.com Nov 20, 2011]

Explaining FlowChain Via A Restaurant Analogy

I love Gordon Ramsay’s TV series “Kitchen Nightmares” (including the USA version).

As well as being entertaining, I share Gordon’s obvious passion for helping folks improve their businesses (in my case, technology-related businesses – not restaurants!). The series illustrate in an almost visceral way the key issues facing any business, and a simple means to address these issues.

He follows much the same strategy in each encounter, a strategy which guides the changes he proposes to owners:

  • Understand what the customers actually want in the way of food, prices, dining experience, etc..
  • Change the restaurant’s offerings to more closely match that demand.
  • Get the management and workers to care about what they’re doing again (intrinsic motivation).
  • Sort out the kitchen so it has the capacity and capability to meet the expected increase in demand.

It’s the latter point which I’m going to use, as an analogy, to illustrate FlowChain and how the FlowChain perspective can benefit technology businesses. (In this post, for the sake of clarity, I’ll talk exclusively about the software development aspects of producing or enhancing a technology-based product or service).

Things In Common

In a restaurant kitchen, orders from customers arrive at the pass.

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole kitchen, synchronised by e.g. the Head Chef, works to prepare each element of the highest-priority orders. As elements become ready, they arrive at the pass, where they are assembled and checked before being dispatched, in small batches (one course for one table at a time), to front-of-house and the waiting diners.

In a FlowChain context, orders (in the guise of, say, new user stories) enter the software development department (or maybe it’s called the IT department – that’s an issue for another day).

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole department works to prepare each element of the highest-priority orders. As elements become ready (with Continuous Integration we can skip a separate assembly step, and with e.g. TDD/BDD we can skip much or all of the checking) the orders are dispatched to the waiting customers. (With Continuous Deployment we can skip much of the dispatch step, too).

So, the essential aspects which these two scenarios (kitchen, software development department) have in common are:

  • Incoming orders arrive with unpredictable variation in e.g. size, timing, priority and requested customisations.
  • There’s a constantly-changing, enterprise-wide backlog of pending orders.
  • Workers assign themselves to the highest-priority items, depending on their skills.
  • Customers do not want, nor expect, their entire meal to arrive at once.
  • Customers do expect to have a single course for the whole table arrive at the same time.
  • Continuous operation, day-in, day-out.

Benefits

The benefits of this approach include:

  • Elimination of overheads such as project management (no projects!) and programme management (no brawls over resources for competing projects).
  • Elimination of project set-up and tear-down overhead (no project teams!).
  • Reduction in delays due to e.g. elimination of handovers and sequential processing.
  • Much improved flow (of valuable user-stories to customers). Increased flexibility in responding to customer needs.
  • Improved collaboration between workers, and between front-of- house and the delivery unit.
  • Provides opportunities for learning and, especially, multi-skilling, in the workforce.
  • Requires leadership (although not necessarily ONE leader), not management.

Of course, as we described in Gordon’s strategy, building a successful business as a whole means we have simultaneously to attend to a range of issues, not just simply ensure that the “delivery” part of the organisation has sufficient capability to play its part in the new scheme of things.

And please accept that this is ONLY an analogy, to help explain FlowChain a little better. A software development department is not a kitchen, and the issues – whilst similar in some aspects – are sufficiently different that I for one would not want to run a software shop in the same way as a restaurant kitchen.

– Bob

The Nature of Time-boxing

[From the Archive: Originally posted at Amplify.com Nov 18, 2011]

Time-boxing seems like such a simple concept. A team – with their Product Owner – gives themselves a fixed period of time, say two weeks, to:

  • figure out what’s the most important things to next add to their working product
  • build those things
  • integrate them into the working product

(Note: I’m not going to digress about the need for *working* software in this particular post. Maybe another day).

But there are some hidden dynamics at play, underneath this simple- looking veneer.

This post is about just one of those dynamics, namely, the interplay of time-boxing and commitment.

Many Scrum practitioners (and their customers even more so) have come to believe that if a Scrum Team fails to completely deliver ALL the items it has planned for a given time-box (Sprint), then it has “failed” in some way. Failed, indeed, to “meet it commitments”.

This viewpoint leads to increasingly dysfunctional behaviours, as describe recently by @yuvalyert (Yuval Yeret) in this blog post.

For all the successful development projects in which I have been involved, we have always treated time-boxing as a means to curtail overruns of effort, especially with respect to individual items (deliverables). That is to say, during Sprint Planning the folks involved in working on a given Sprint deliverable (for example, a User Story) agree amongst themselves – and with the rest of the team – on how long they will spend on that item (Note: NOT how long they expect to take to bring that item to some kind of completion, or state-of-readiness. I.E NOT an “estimate”). So, the Team commits to spending some finite amount of time on the item, NOT to completing it. We have found this distinction to be crucial.

We also apply this same perspective to the Sprint as a whole. We commit to spending two weeks (no more, no less) of our collective best efforts on working towards the Sprint Goal. We do NOT commit to delivering specific things in a fully-finished state. (Aside: It’s kind of important that everyone – Team, Product Owner, stakeholders, management, customers, etc. – all understand this clearly, with regular reminders).

Of course, if during the Sprint it begins to look like some items will not be completed in their allotted (mini) time-boxes, then the Team, the Product Owner (and maybe other stakeholders too) can have a discussion about what to do. This, for me, is one key aspect of being Agile (correcting course as necessary, even whilst “in flight”).

This does mean that some Sprints will deliver less (integrate less functionality into the working product) than expected. And some will deliver more than expected. Swings and roundabouts :).

This is the nature of software development.

– Bob

PERMA and the Positive Business

[From the Archive: Originally posted at Amplify.com Nov 5, 2011]

In his great, recent book “Flourish“, Prof Martin Seligman introduces the idea of “Positive Business” – an idea aimed at “broadening what MBAs care about” – i.e. beyond mere money, towards the five different pursuits which he posits comprehensively constitutes “well-being” (and for which he uses the acronym PERMA):

  • Positive emotion
  • Engagement
  • positive Relationships
  • Meaning
  • positive Accomplishment

Upon reading this, it immediately struck a chord with me, surfacing some subconscious thoughts I had been accumulating whilst reading his book up to that point. For me, Rightshifting is inseparable from the idea of creating workplaces where well-being (of employees, for sure, but also of all other stakeholders) is at the core of the work experience. As Prof Seligman states:

”If you want well-being, you will not get it if you care only about accomplishment [e.g. profit]. If we want our [Management] students to flourish, we must teach that the positive business and the individuals therein must cultivate meaning, engagement, positive emotion, and positive relations – as well as tending to profit.”

Aside: John Kay in his book “Obliquity” goes even further, positing that accomplishment, such as profit, desirable as it is, often best comes about obliquely – as a fortuitous by-product of the search for other things.

Prof. Seligman goes on to write (paraphrasing): “Even if rich profits and growth are not forthcoming, individual and collective well-being may well remain stable, or even rise, on balance.”

Quoting Friedrich Nietzche’s concept of “The Child Reborn” he then asks:

“To what can we say ‘yes’? What can every human being affirm? We can all say ‘yes’ to more positive emotion; we can all say ‘yes’ to more engagement; we can all say ‘yes’ to better relationships; we can all say ‘yes’ to more meaning in life and we can all say ‘yes’ to more positive accomplishments. In short, we can all say ‘yes’ to more well- being.”

Amen to that.

+1 for Flourishing.

+1 for the Positive Business.

– Bob

A Round-up of European Lean/Agile Conferences

 [From the Archive: Originally posted at Amplify.com Nov 3, 2011]
I’ve been speaking at a bunch of Lean/Agile conferences across Europe recently (e.g. October 2011). Some of the organisers have asked me for my feedback (I applaud folks who listen to their customers and want to improve). So here’s my feedback on each of the events I attended, in the “Perfection Game” format:

Lean/Kanban Benelux

What I liked

  • The venue
  • That everyone was in the same hotel
  • The production quality of the videos
  • The audio and projection facilities for the session speakers
  • The Hotel lounge
  • Belgian beer and food
  • The camaraderie common to all the attendees
  • Meeting many Twitter friends in meatspace
  • The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

  • Reliable Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
      • Ditto the above, plus live tweeting
  • Hotel and conference venue closer together (within a short walking distance)
  • Better air-conditioning in the conference venue
    • I guess we could not have anticipated a heat wave in October, but the venue was often way too hot for me.
  • Better Hotel management
    • Although the hotel decor, bar service, food, etc was great, the Radisson Astrid seemed poorly organised and run overall (i.e. great staff were defeated by a dysfunctional system).
  • Absence of personal attacks from some of the speakers on the work and – more perniciously, on the integrity – of some of their fellow speakers. I am speaking in particular of Dave Snowdon as the major offender (literally).
    • Maybe some formal “polite request” of speakers to refrain from this kind of thing might help?
  • Less confusion and uncertainty over speakers’ arrangements, expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage (big screen), during all sessions.

Magrails Manchester

What I liked

  • The organisers: Lovely people who went way beyond the extra mile to make me feel welcome and valued.
  • The venue (in general, but not the room layout – see below)
  • That all sessions were videoed
  • That there was just a single session track – great!
  • The Magrails website – great job, guys!
  • The audio and projection facilities for the session speakers (barring the audio glitches)
  • Attention to detail, especially the handouts / conference bag
  • Tee-shirt (quality!)
  • The audience. A very attentive, inquisitive and widely knowledgeable bunch

Overall score out of ten: 7.5

What would have made me give a ’10’ score

  • Much more attention to the social dimension
    • Example: Late-night chatting in the hotel bar (didn’t happen)
    • Example: Over-breakfast chatting in the hotel (happened marginally – thanks Jason!)
    • Example: Evening events held somewhere quiet, calm and cosy, to facilitate conversations
  • A better layout for the session room (long and thin made it difficult to engage with the speaker in the far distance)
    • Personally, as a “speaker” who likes to get close up and personal (engaged) with an audience, I would have like it to be “in the round”.
  • A panel session as part of the day’s schedule (or maybe an early-evening thing)
  • Everyone in the same hotel
  • Reliable Hotel Wifi
    • As I could not get a 3G signal in the hotel, I may as well have been a visitor from another country. Under such circumstances Wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
    • Ditto the above, plus live tweeting
  • Hotel and conference venue closer together (within a short walking distance)
  • Better Hotel management
    • Although the hotel decor, bar service, food, etc was OK (but not great), the Radisson (Park Inn Hotel) seemed poorly organised and run overall (i.e. nice staff were defeated by a dysfunctional system).
  • Real-time display of the conference tweet streams, on stage, during all sessions
  • Not being barred from charging things to my hotel bill just because the Hotel had lost the billing details.
  • A reliable taxi firm
  • More Buzz during the second (workshop) day.
    • OK, it was a Saturday, and I guess some folks had hangovers from the previous night, but the buzz of the previous day seemed conspicuous by its absence.
  • More effective “policing” of the day’s schedule (sessions overran)
  • Mike-up the audience (or as a minimum ensure speakers repeat ALL questions so all can hear)
  • Opportunity for Open space session(s) and/or lightning talks aka Pecha Kuchas

Lean/Kanban Munich

What I liked

  • The venue
  • That everyone could get to the Alpen Hotel quickly and easily
  • That some of the sessions were videoed
  • The audio facilities for the session speakers
  • German beer
  • The camaraderie common to all attendees.
  • Meeting many Twitter friends in meatspace
  • The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

  • Reliable and convenient Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
    • This was particularly poor.
  • All sessions videoed (especially mine :}
  • Quicker publication of videos, slide packs after the event
  • Better (suggested?) Hotel
    • Avoid the Metropol 😦
  • Less confusion and uncertainty over speakers’ expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
  • A lounge area (specifically, with comfy seating) at the conference venue

LESS Stockholm

What I liked

  • The “volunteer” nature of the event – thanks to all those who made it so great 🙂
  • Everyone in the same hotel
  • Outstanding catering facilities, especially the fruit, drinks, amuse bouches, and cake
  • The audio facilities for the session speakers (when they were used)
  • The camaraderie common to all attendees and organisers alike
  • Strengthening many Twitter friendships in meatspace
  • The roster of great speakers

Overall score out of ten: 7.5

What would have made me give a ’10’ score

  • A chance to see something of Stockholm
  • Better beer
  • More cake! 🙂
  • Not getting bounced out of the bar in the late evening “because of Swedish alcohol laws”
  • Better session rooms
    • Rooms were too bland and impersonal
    • Room B1 was imo too wide and shallow and too small for keynotes
    • Other session rooms were too large
    • All projection screens were way too high
    • Lighting of e.g. the speakers themselves was poor. Needed spotlights!
  • Sessions videoed
    • I really hated having to miss sessions from the multiple tracks in the knowledge that I’d not ever have the chance to catch them on video later.
  • Convenient Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
    • Telia’s wifi service was (generally) reliable, but a UX nightmare (continually having to reauthorise).
  • That the Hotel had refrained from remodelling their bar area during the time we were there
    • Particularly all the banging (demolition noise) during breakfaster and lunch
  • More clarity re: speakers’ expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
  • Cheaper airport transfers. The Arlanda Express is way too pricey.

Happy as always to answer any questions, etc.

– Bob
%d bloggers like this: