patkua@work

The intersection of technology and leadership

Category: Systems Thinking

Book review: “This is service design thinking”

A couple of years ago, a very kind Product Manager gave me a book called “This is Service Design Thinking.” It was shrink-wrapped and everything after they had received it on a training course. I finally got around to reading it this weekend. The book is beautifully made… hard cover, thick pages and even with little coloured book mark ribbons strewn throughout.

I consider myself lucky, having worked with many different user experience folk who have helped shape my understanding of Service Design and this book helped to add a few more tools to my toolkit and a nice way of trying to shape it. When we write software, we already incorporate a lot of the design thinking concepts – really trying to understand the “touch points” that a customer has with an organisation and how software fits into these different needs. We don’t always get to work at a high level of an organisation – something that I believe is necessary if you are truly going to help shape or influence an organisation’s service offering to customers. Software is only one part of the puzzle. However it is becoming more and more relevant as software (or hosted software) starts to become a major or only channel for service delivery to customers.

This is Service Design Thinki

We already make use of many of the tools described, but a few new ones to me included:

  • Service safaris – A nice name for the technique of visiting people to observe them interacting with an existing service.
  • Cultural probes – The “probe” in a scientific sense but basically a kit given to customers to allow them to take snapshots of their own life in the context of a service to build a greater awareness of what’s important to them. These probes stay with candidates for a while but a researcher may send texts or emails to prompt for a different insight. Requires constant attention to the information being submitted back
  • Expectation maps – Building a visualisation of what a customer expects when they interact with a service. Useful for comparing different expectations across different touchpoints, or offerings.
  • Desktop walkthrough – I haven’t seen this technique probably because it seems to demand more preparation than others. Basically this is a 3D small scale model of a service environment that allows people to interact with it. I can see this being highly engaging.
  • Service Roleplay – A scenario where staff members are asked to enact several situations where they might come into contact with a customer. Video is often used to provide feedback and act as a basis for discussion.
  • Customer lifecycle maps – A holistic view of a customer’s relationship with a service provider. Their example one maps out loyalty over time. I can see the map being annotated by events to trigger insight

I really enjoyed the book. There are some nice studies at the end. I did protest at the simplified description of “Agile software development” but it’s small detail in the larger set of things. My only gripe is that the beauty of the book comes at the price of being significantly heavy to lug around.

Book Review: Rethinking the Future

I recently finished the book, “Rethinking the Future” and I have to say how impressed I was by the book. The book is structured as a collection of essays from different well-known leaders and authors in different fields. I knew many, but not all, of the contributors and, as a result, the book offers a wide variety of perspectives. Some that complement, others that contrast with each author’s very opinionated view of the “future.” Bearing in mind this edition of the book was published in 1998, I find it interesting to see how still relevant many of the writings are today.

Rethinking the Future

Definitely focused as a business book, the contents are divided into different chapters trying to envisage the future from many different angles includes the way that businesses work, competition, control and complexity, leadership, markets and the world view. The book resonates very strongly with some of the works recently published such as truly understands what motivates people (i.e. Dan Pink’s Drive), or the need for management to balance even more and more states of paradox (e.g. Jim Highsmith’s Adaptive Leadership).

I don’t necessarily agree with all of the contributions in the book, particularly the idea of being focused on a single thing as described in the chapter, “Focused in a Fuzzy World.” I agree some focus is important, but I also believe in order to innovate, you sometimes have to unfocus. I see this as the problem often described by the Innovator’s Dilemma.

Showdown: Systems Thinking vs Root Cause Analysis

I gave a presentation in Recife about Systems Thinking and had a great question about where does root cause analysis fit in versus systems thinking which describes emergent behaviour and that there may be no single cause to the system behaviour.

Fight
Image courtesy of tamboku under the Creative Commons licence

Firstly I like the quote from statistician George E.P. Box, “essentially all models are wrong, but some are useful.”

What I like about the root cause analysis is how it teaches you to not react to symptoms. It encourages you to look at the relationship between observations and move deeper. All of this is subjective interpretation and, like systems thinking, depends on how a person draws the relationships. From this perspective, they are similar.

Many people describe the five whys as a technique and one that I draw upon more often. I prefer the fishbone method of root cause analysis because it helps encourage you to think that there may be more than one cause for an effect you see.

When you take the results of root cause analysis and try to see if there are any cyclic relationships, you might end up identifying more effective leverage points where breaking, accelerating or dampening a reinforcing loop with a small effort might have a significant impact on the system.

After studying complexity theory, an interesting approach at looking at these models is never thinking about them in a mode of conflict. Instead, you should be looking at where there is value and trying to apply them where you can realise that value. Never look at models as competing (OR-mode) thinking. View them as complementary (AND-mode thinking)

Reflections on Agile 2012

Another year, another agile conference. It’s time for reflecting on the conference and uncovering lessons learned. Dallas, Texas hosted this year’s Agile Conference. More accurately, the Gaylord Texan Resort in Grapevine hosted this year’s Agile Conference. Loved by many at the conference (notably less so by Europeans) the resort reminds me of the Eden Project and a weird biosphere (see picture below) that is self-contained and fully air-conditioned. Although maybe this wasn’t such a bad thing with a West Nile virus outbreak in Dallas.

Needless to say that I stepped out quite a bit to try to get some fresh, if not, refreshingly humid air.

Onto the conference. It was very well organised, very well run and even rapidly responded to feedback (such as moving rooms when demand proved too much for some of the anticipated sessions. Food came out very promptly in the different breaks. We didn’t have to queue too long and the variety was pretty good. The only breakdown was probably the Tuesday lunchtime where it wasn’t clear we had to get our own food and with a limited number of on-site restaurants in our self-enclosed bubble world, proved to be a bit of a tight squeeze in schedule.

The people at the conference seemed to be a bit of a mix. Mainly lots of consultants like myself sharing their experiences, but as one person noted, an extraordinary number of agile coaches all apparently looking for work. On the other extreme there seemed to be lots of companies adopting agile and lots of people selling tools and training to help them.

Lots of parallel tracks meant lots of choice for many people but I often found it hard to find things that worked for me. I’m less interested in “enterprise agile adoption”, and more interested in the practices pushing the boundaries, or the deep insight offered by people. The few technical sessions I went seemed to be aimed at a bit more of an introductory audience. I particularly avoided any of the “do this with scrum” or “do this with kanban” as these appeared by be pushing.

In terms of keynotes, I thought they did a great job of assembling some diverse and interesting sessions. Although Bob Sutton (No A**hole Rule author) felt like he didn’t do much preparation for his keynote from the text heavy slides that jumped at different paces, he had some good anecdotes and stories to share. My biggest takeaway from that session was thinking about taking away practices just as much as adding practices, something that I think I do implicitly but should try to do more explicitly. The other keynotes were pretty inspiring as well, with Dr. Sunita Maheshwari behind Telerad talking about her accidental experiment moving into doing remote radiology to support the night-shift need of hospitals in the US and the interesting growth of their business. The other really inspirational keynote was by Joe Justice, the guy behind the amazing Wikispeed project taking sets of agile practices and principles back into the car-making industry. I felt he really knew his stuff, and it’s amazing how you can tell someone who really understands the values and trying to live them in different ways and then translating them into a different world. Very cool stuff that you should check out.

In terms of other workshop sessions, I left half way through many of them as the ideas were either too slow, or not at all interesting (such as one on Agile Enterprise Architecture that spent 30 minutes trying to go back to the age-old debate of defining Enterprise Architecture.)

Two of my most favourite sessions was one by Linda Rising who gave a very heart-felt and personal Q&A session that left many people in tears. Her stories are always very personal, and I really admire her ability to look beyond someone’s words and really uncover the true question they are asking with a usually insightful answer as well! The other session was listening to the great work that Luke Hohmann of Innovation Games has been doing with the San Jose government to change the way they make decisions about where the money goes through the use of games and play. Very awesome stuff.

I had my session in the last possible slot on the Thursday and had a large number of well known people in competing slots such as Jeff Sutherland, Esther Derby and Diana Larsen. I’m very happy with the turn out as we had a lot of fun playing games from the Systems Thinking Playbook including a number of insightful conversations about systems thinking concepts and how they apply to our working life. One of my most favourite exercises (Harvest) that demonstrates the Tragedy of the Commons archectype played its course and we finished in just three years (iterations) only due to a constraint I added early into the game. I love this exercise for its potential for variation and the insightful conversations about how this applies to agile teams, organisations and functions.

You often can’t come away from conferences without new references, so here’s the list of books and web resources I noted down (but obviously my summary is without actually reading into it, so YMMV):

Talking Feature Leads

On my current project, I’ve tried something a little bit different inspired by the work of Feature Driven Development (FDD). Although sometimes cited as an agile methodology, my perception is that it is one of the lesser talked-about methodologies. On my current project we have been trying the idea of Feature Leads for the last four to five months, and I’m pretty happy with how it has turned out.

Feature teams versus Feature Leads
FDD often talks about Feature Teams – or a team that works on the design and implementation of a feature area. Since FDD heavily emphasises more modelling up-front, these tasks also often talk about Feature Teams leading the UML modelling and design documentation that goes along with it. In our circumstance, I didn’t think it made sense to have any real Feature Teams, namely because it was a greenfield project and there wasn’t any clear way features stayed independent of each other. I favoured the XP practice of Collective Code Ownership over what specialisation a Feature Team may bring together. I wanted the best of both worlds, so I introduced the team to the idea of a Feature Lead.

What does a Feature Lead do?
Our team had a good mix of experience, and introducing the “idea” of Feature Lead without communicating some of the responsibilities would definitely lead to some trouble. When I first introduced the Feature Lead term, I outlined a list of responsibilities that would come with it. I even printed a list to give to each Feature Lead to act as the starting point for a Standard Work checklist.

I included the following activities:

  • Explore all the use cases – Arrange workshops with the business owner to understand all business objectives the are trying to accomplish. Design a solution with that stakeholder, balancing business process supported by technology. Challenge assumptions about technology constraints and solutions, and avoid building software if there isn’t a clear need (i.e. we don’t want to build the wrong thing faster). Work with me (as the overall Technical Leader) to validate the solution. Consider the end-to-end flow including business people who need to be involved in set-up, on-going maintenance or business support as well as expected outcome.
  • Explore the impact on deployment and architecture – Does the business needs/technical solution warrant a change in architecture?
  • Identify spikes as early as possible – Are there any investigations we need to explore to create more options, or to validate assumptions before committing to a solution? Separate work that is not estimable into a spike and a story (and highlight the dependency on the spike).
  • Consider external configuration – Will this work require new configuration work? How often will it change? Where will we store it?
  • Who/where is the authoritative source? – If there is new data, or a new data store, be clear about which system is the authoritative source
  • Does it make sense to re-write the backlog items? – We had already been given backlog items broken down, but often we found them with an assumed solution in place. After exploring what the business really wanted to do, the nature of the stories would most likely change.
  • Verify assumptions against new stories – With the set of stories identified, work to validate all assumptions with the business stakeholder.

How I worked with Feature Leads

After the pair iterated over possibilities and designs, I would review their solution and stories with them, ensuring that cross-functional requirements such as security, performance, etc were all taken into account and represented. I would also work with the Feature Leads to ensure the overall design worked with the other Feature Leads and that we never diverged.

Once validated, I worked with the different Feature Leads to organise a Feature Walkthrough, talking about the business problems, the outcomes and how the stories fit together to make a comprehensive solution. This Feature Walkthrough distributed knowledge to the entire team so that they had enough context to pick up a story in any feature area and understood how it worked.

Feature Lead + 1
To ensure that we never had a bus factor of one, we always identified two Feature Leads (a primary and a secondary). Both needed to involved in the design and discussions as well as the story identification process so that if one went away on holiday, or was ill, that feature area would not come to a halt. As a fallback, I would also pick up the solution if both were away.

How has it turned out?
I am personally really proud of the team, and the way that the Feature Leads lead the design. We had some great solutions and ideas, and their outputs allowed the entire team to continue to own the codebase as a whole. There are so many other dimensions to talk about, but will get around to writing about them separately.

8 years at ThoughtWorks

Friday marked eight years since working at ThoughtWorks and thought it’d be a useful exercise to reflect on it. During that time, I’ve seen the company grow and the number of opportunities grow with it as well. I was at the pub last night (one of those ThoughtWorks UK traditions) and was trying to explain my role to someone. On my business card, it’s the title of Generalising Specialist. I’m a developer most of the time and although as a Technical Leader you don’t develop 100% of the time (who does?) I still get to do a huge amount.

Reflecting on the past
I’ve had plenty of opportunities to do a lot of public speaking and was proud to be invited to speak at Øredev, QCon and this year to Goto Aarhus (formerly JAOO). I see it as a great way to share knowledge and contribute back to the development community and to continue to spread great ideas. As I always tell people there is a lot of value in being a meme-carrier and helping introduce memes into newer communities.

At the same time, I’ve worked as a trainer, facilitator and an advisor doing some short term pure consulting engagements working with CTOs and CIOs on how they run their software organisation, how they’ve architected their software systems and helping them build a roadmap to a better pace. My passion for Systems Thinking, Lean thinking and the belief of constantly being open to new approaches and ideas helps me see and explain things that others often get stuck on.

Work wise, I’ve now worked in many places. Last year I spent a significant portion of that time in Germany, Berlin to be exact. It’s not the best place to learn German, but my passion for learning drove me to self-learn enough that I can hold a conversation in a bar reasonably well. I’ve got plenty more to go before I can start writing any blog entries or immerse myself in a completely German speaking work environment but pretty happy with the progress so far. Overall I’ve worked in Australia, Canada, Denmark, Germany and the United Kingdom for my clients with travel for conferences to many more.

I continue to appreciate the different opportunities and the continuous mix of people that I get to work with. As an example, we have a project of about 15 people all representing about 12 different nationalities. We have four females on our project (2 of which are developers) and so many interesting approaches and conversations with a consistent focus on trying to do the right thing for the client. I have to always remind myself other companies or contractors do not stand for the same values and I constantly appreciate.

Thinking about the future
Although I’ve been published in a book before, my goal is to finish a book, The Retrospective Handbook some time this year. Leave a comment to let me know what you think or tell me about your interest.

I will continue to write code, although this year I plan to specifically deepen my javascript and ruby skills. I will continue applying systems thinking but deepen its application into the software realm and how it can be made more appropriate.

I plan on cutting back on the number of speaking engagements. Last year it was almost one or more every month and the variety proved rather stressful at times when trying to balance life and work.

Systems Diagramming Tools

Just a quick reminder to myself about a number of tools available to people interested in Systems Thinking:

  • Flying Logic (Commerical) – My favourite so far with nice looks, and an emphasis on building the diagram collaboratively instead of simply focusing on output. It automatically adjusts the layout when adding in nodes for minimal line-cross overs. Can be a be nauseating sometimes.
  • Graphviz (Free) – Simple looping diagram that’s easy to automate. Not was good representation for causal loops if you want to discriminate amplifying/dampening cycles, but good bang for buck
  • Omnigraffle (Commercial) – Diagramming tools that makes very snazzy diagrams. Less powerful on automatic layout than Flying Logic. Mostly manual.

Book Review: Quality Software Management: Systems Thinking

I’ve been interested in Systems Thinking explicitly for the last two or three years. I haven’t had many good books I could recommend to anyone other than “The Fifth Discipline.” Last year, I inherited a wealth of Jerry Weinberg books from fellow geek, Romilly Cocking and just got around to digesting a very classic book, Quality Software Management: Systems Thinking. Weinberg, whether or not you know it, has had a huge effect on our industry. He has written many books on wide ranging topics, and being a participant/organiser of the Amplify Your Effectiveness (AYE) conference continues to influence many leaders.

Anyway, back to the book.

Hard cover books are always a lot more intimidating than their soft covered brethren. Perhaps it’s the sheer bulky that does it. Fortunately the text is rather large and with only about 280 pages of content, easily consumed on a number of continental flights between the “no-electronic gadgets” zone.

I’ll admit that describing Systems Thinking is hard. Walking through, what Weinberg calls, Diagrams of Effects are intuitive when he explains them step by step, however I find it hard to describe the process and never have been very confident in some of the ones that I have used.

The Mechanics of Systems Thinking Diagrams
One tip that Weinberg talks about is thinking about the things in the boxes as things that you could measure (or you do measure) and their relationship between each other. Giving the item in a circle a name has been a challenge for me, and Weinberg presents a heuristic I feel I can make better use of.

Unlike models I’ve seen from places like Soft Systems Dynamics, Weinberg doesn’t use a plus or a minus, and maybe you’ll find his notations work for you. I can’t say they worked or didn’t exactly work for me. I did appreciate the different take on making the secondary, or implicit loops more explicit by attaching repeating loops to the lines they amplify, rather than to the entity they end up with.

In other Systems Thinking Diagrams, people sometimes note a delayed effect, something I was surprised didn’t really turn up in the book to a great deal. I don’t know whether or not this was intentional or not. A new difference I learned though was putting on another notation for diagramming where managerial decision/input affects the Systems Diagram. The way that Weinberg wrote about using this brought a little bit more of a humane aspect to it.

Repeating the role of Mental Models
In the Fifth Discipline, I didn’t really understand the importance of Mental Models related to the point of the Learning Organisation. After chatting to Mark Needham recently on the way that people interpret different things, and seeing how crucial this was to interpreting and drawing Systems Thinking Diagrams in Weinberg’s books, I better understand why these two things cannot be detached. In fact, it was very timely with the question that XP2011 keynote, Esther Derby kept asking, “In what world would this make sense?” to see things from a different Mental Model.

Weinberg tells a really good story about how these Mental Models effect the observation. He recalls a story talking to a manager who’s managed to work out how to distinguish good programmers from the bad ones. The manager starts talking about how he’s noticed how some programmers talk a lot to end users, or to other programmers. A grinning Weinberg, nodding at the manager’s observation slowly stops as he comes to realise how the manager don’t think of these inquisitive, communicative programmer’s as the better ones, unlike what Weinberg (and maybe you and I were thinking). Same observations, different interpretation.

Reconfirmation of in built human biases
We are full of biases that we aren’t even aware of. Many of Weinberg’s anecdotes remind me of some in particular. For example, he talks about how managers running projects that continue to fail, blame it on “bad luck”, or “something out of their control”, whilst taking personal credit for those that do succeed. This is a really good example of the Fundamental Attribution Error.

Things that didn’t work for me
Throughout the book, Weinberg refers to Pattern 1 and Pattern 2 type organisations. Even though he explained them early on in the book, I found it difficult to anchor any real meaning to them by the time I’d finished the book. I would have liked to have seen him give them better names and use them throughout. It’s a minor detail, however I did notice this slowing down my reading.

Summary
I’d recommend this, still highly relevant, book to people involved in IT today. Though it’s published in the early 90s, I’m surprised at how many of the stories are still relevant. It not only explains the basics of thinking with systems using models anyone can relate to. It also explains those systems diagrams that apply to the software problems of today.

Summary of XP2011

First full day of XP2011 was a pretty full schedule as I had to prepare for two lightning talks on different subjects. Fortunately both of the topics were very close to my heart, one about learning using the Dreyfus Model (slides) and the other about Systems Thinking (slides). The second day started off with a great breakfast selection at the conference hotel before kicking into the keynote by Esther Derby. Clearly jetlagged, Derby used a set of hand drawn slides to explain her topic, “No Silver Bullets”.

Her presentation style was very conversational and I can’t say that the crowd responded very well to this. Perhaps it was their jetlag as well, or the way the room had been set up. Nevertheless, through many of her stories, I still saw many heads nodding and a really great response on twitter to the things that she was saying.

I’ve followed Derby’s writing for years and could only wish more people would be exposed to them. As a result, I found many of the topics and opinions I found interesting reinforced, such as failing to address the management layer inevitably means agile adoption hits a hard ceiling. Or the oscillating behaviour that results when managers attempt to react to a system with long delays in its feedback cycle. I appreciated the very vivid term, “Bang! Bang!”-management style describing the style of managers who seem to have only two distinct and opposing reactions to a system, unable to moderate their use and wait for systems to find a new equilibrium. If you imagine these two opposing reactions the result of a huge iron lever being flipped, hopefully you can imagine where the noise comes from.

Derby covered lots of different areas, quoting a few people like Donella H Meadows, “The original purpose of hierarchies was to serve the sub systems, not the other way around.” And the work that George Lakoff does with word association with metaphors in our everyday use. Raising self awareness of your own in built biases and metaphors is another key thing she emphasised focusing on the judgements, habits, feelings, thoughts, mental models, beliefs, rules and values we tend to be intrinsically governed by. I particularly liked the phrase she uses to help people uncover their own and others’ mental models, “In what world would this make sense?”

She told one great story about the dangers of measurements as targets, using the example of the manager who decided to “Grade developer estimates”. This manager decided to give A’s to those who estimated on time, B’s to those who estimated over time, and C’s to those who estimated under time. Of course, you can imagine what magically happened as people’s grades mysteriously improved.

She also reminded me of the work of Ackoff, who I need to revisit, and the great work that he’s written about Systems Thinking. I have only been able to refer to the Fifth Discipline as a Systems Thinking book, but I really need to read his other ones to see if they would be of use, or are more accessible.

The rest of the day was a bit of a blur. A couple of highlights included seeing Marcus Ahnve take the work Luca Grulla and Brian Blignaut did with TDDing javascript to the next level and doing a demo of BDD.

David J. Anderson also reminded me of the importance to think in terms of the languages executives speak in order to better get our message across. He reminded me of all the great things that Ross Pettit has to say, although I think Anderson’s analysis on accounting for software development costs doesn’t seem to match with some of the data I’ve heard from Pettit.

There was so much more to the conference. Always the way great conversations emerged and the wonderful atmosphere of the hotel adding to the uniqueness to this event.

© 2017 patkua@work

Theme by Anders NorenUp ↑