The intersection of technology and leadership

Category: Systems Thinking (page 1 of 2)

Book Review: Factfulness

Book Review: Factfullness

It was almost a decade ago, I first watched Hans Rosling talk about the ever changing state of the world (see the videos here). He was a poster-child for demonstrating how visuals can bring static data to life. In his last legacy to the world, Rosling published the book, “Factfullness.” Unfortunately he passed away in 2017 due to pancreatic cancer.

Factfullness reflects many of Rosling’s personal stories. It also shares his frustration with a world filled with bias and “fake news.” This book is extremely relevant given the current state of politics both in the UK and the US. 

Factfullness challenges us to push past biased social and news media. Instead we should focus on globally available data such as from the United Nations. In the book, Rosling paints a much more positive view of the world than what the media likes to portray. As he often repeats, “It may still be bad, but it’s significantly better.”

Fuelled with data, Rosling shows us how child mortality is drastically decreasing. He demonstrates how fewer people live in critical poverty. He reminds us how women have better rights today. The book highlights how monkeys are more factful than educated humans. Rosling points out we are less factful because of “Instincts.”

The Gap Instinct describes how we quickly classify something into one of two camps. Examples include being poor/rich, sick/healthy, or us/them. Reality is more of a spectrum, with a majority in the middle and that there’s not that much of a gap. Rosling warns us to be careful of extreme comparisons.

The media fuels the Negativity Instinct. Rosling points out, “Negative news sells.” He contrasts this with an observation that  incremental improvements are not considered newsworthy. In this chapter, he starts using the phrase he later repeats, “It can be both better and bad.” (The situation can still improve, but the world has improved significantly.)

The Straight Line Instinct describes how we think linearly. In the context of an ever growing population, this instinct fuels the fear of overpopulation. Rosling highlights how childbirth rates reduce as a country becomes more prosperous. He challenges us to use data to better understand the shape of data. He gives examples where curves are more like doubling curves, or act like an S-curve. Straight line functions are the exception rather than the rule.

Rosling shares a personal example where the Fear Instinct causes unclear thinking. This reminds me of the Type I thinking (from Thinking Fast and Slow by Daniel Kahneman). Type I thinking means we react in critical situations with poor results. Fears from physical harm, captivity or contamination drive us to act irrationally. Rosling challenges us to differentiate between frightening and dangerous. Danger is risk multiplied by exposure. When we recognise this instinct, seek calmness before making an important decision. 

The Size Instinct focuses our attention on individual numbers out of context. A compelling story or a concrete example leads to us overestimating an impact. Rosling recommends we look at numbers in proportion. We should do relative comparisons, or look at trends rather than numbers alone. Rosling reminds us of the Pareto Principle (80/20 rule) or use rates (e.g. number per person).

The Generalisation Instinct describes our habit to automatically category and generalise. Stereotyping through generalising leads us to incorrect conclusions or unjustified judgements. It also leads us to poorer decisions. GapMinder invented Dollar Street to highlight different categories. Rosling challenges us to look for differences and similiaries across categories. Avoid using categories to justify an assumption.

The Destiny Instinct drives us to believe destiny is pre-determined. This reminds me of the Fixed versus Growth Mindsets, made popular by Carol Dweck. To fight the Destiny Instinct, we must recognise small improvements and changes. We should seek knowledge about how cultures and societies do change over time.

The Single Perspective Instinct drives us to seek a simple solution or answer. I recognise this instinct from my studies in Systems Thinking. A counter against this instinct is to collect different Mental Models. Each Mental Model provides a different perspective on a situation. I loved this quote from this chapter. “The world cannot be understood without numbers, and it cannot be understood with numbers alone.”

The Blame Instinct describes our desire to find a scapegoat, or to point the blame at an individual. It blocks our ability to focus on contributing factors. It also means we are unlikely to prevent similiar problems in the future. Rosling provides great advice here. It reminds me of advice for healthy, blameless post-mortems. “Look for causes, not villains and look for systems, not heroes.” 

The final instinct Rosling describes is the Urgency Instinct. This instinct draws upon Type I thinking and biases for action now rather than later. Rosling reminds us that urgent decisions are rare. He encourages us to take a breath, insist on data and be wary of taking drastic actions. 

I really enjoyed reading this book. Rosling’s personal stories bring vibrancy to the book. He highlights how even “experts” or “highly educated” people fail to act factfully. The book makes us wary of the “Instincts” and provides concrete actions to help us. If you’re interested in learning more about Factfullness, get the book here.

Thanks Jerry Weinberg

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind. 

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.

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.

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.

« Older posts

© 2019 patkua@work

Theme by Anders NorenUp ↑