Category: Systems Thinking (Page 1 of 2)

Book Review of An Elegant Puzzle: Systems of Engineering Management by Will Larson

August 14, 2019 / Patrick / 0 Comments

Introduction

When you say the word, “management,” it’s easy to drum up terrible images. Dilbert, Ferris Bueller’s Day Off, The Office and Silicon Valley reinforce these bad stereotypes. Poor leadership and management is common as people transition into a different role for the very first time. As the old saying goes, “It’s not a promotion, it’s a role change.” Great management may be emotionally exhausting but is also extremely rewarding. Unfortunately I can’t point to enough material about what great management looks like. That’s why I’m excited by “An Elegant Puzzle: Systems of Engineering Management.”

The beautiful book cover of An Elegant Puzzle (image courtesy of @lethain)

In my constant journey of learning, I stumbled across Will’s blog. Add it to your RSS feeds today (assuming you still use one these days!) If not, at least go back and peruse the great entries Will published. It was through his blog that I learned about his upcoming book and joined the waiting list. I bought it as soon as it came out and pleased to say I’ll be recommending it from here on.

Managing engineering teams is different from many other fields. Software systems interconnect via invisible API, data or tech dependencies. While the pace of software increases, so does the tech stack complexity. Any reasonable software product demands strong collaboration across many people. All these people often have very different backgrounds and skill-sets. Harmonising and optimising this ever-changing environment demands managers understand complex adaptive systems.

When I read Will recommending Systems thinking early on, I knew this was going to be a good read. You can’t manage modern software organisations with Tayloristic mental models.

What’s in this book?

The book contains five main sections Organizations, Tools, Approaches, Culture and Careers.

Organizations

This section covers many elements of effective organisation of engineering teams. It discusses optimal team sizes, breaking points, varying structures and trade-offs. Many people underestimate the impact of the poorly designed organisation. Yet many people suffer within them. This topic is also close to my heart, as an advocate for the Inverse Conway’s Manoeuvre and the Target Operating Model (TOM) I recently wrote about.

Tools

This section is the largest in the book. It offers a broad range of concrete and actionable advice. This section covers everything from systems thinking, basics of product management, vision and strategies, metrics, how to deal with migrations and reorgs amongst many more.

This section highlighted the author’s variety and breadth of experience. Not all engineering management will find themselves in each of these situations. It’s useful to have tools to approach these situations in advance.

Approaches

I like to describe this section as the author’s personal style to engineering management. It covers how to handle execution, personal philosophy’s, managing in growth and common traps.

Of all the sections, I found this the most opinionated. It may or may not suit you, the reader.

Culture

This section covers deliberate approaches to cultivating culture. An example is the opportunities you create and who you offer these opportunities to. Another example is reflecting on the representatives you have with your leadership team. A final example are the ranges of policies and the impact that has on the types of freedom.

In this section, I learned the concept of negative and positive freedoms. These are sometimes referred to as negative or positive liberties. Negative freedom is the freedom from external constraints, freedom of interference, or absence of external limits. An example of negative freedom is the USA’s right to free speech.

Positive freedom (or liberty) is the ability to act on one’s free will, or the absence of internal limits. Examples of positive freedom include personal growth and self-mastery. This article has some great examples of positive freedom.

Careers

This section covers everything to do with the employee lifecycle at a company. It covers sourcing, recruiting, interviewing, performance management and career growth.

My thoughts on the book?

This book will appeal to a broad range of people. Those considering engineering management will taste the different set of responsibilities expected in the role. Existing engineering managers will grow their toolkit and discover new ideas. Directors or VP Engineering will particularly benefit with concrete approaches to managing managers.

This is an opinionated book. The author offers approaches that worked for them across many situations. You won’t find a rule book or a guided how-to. Instead, you will find a wealth of experience packaged into actionable chunks. This may or may not be relevant to your current situation. It may or may not suit your own personal style. That is part of the difficult and challenge of effective management. An Elegant Puzzle offers you a head start.

What would I like to see done differently?

I understand how hard it is to write a book, and it’s rarely perfect. Two of my issues stem from reading the book in its digital form. Unfortunately the printed copy was not available in Germany, where I’m currently living. My first is the regret of not experiencing the beautifully designed front cover. I’m sure it’s a better experience in real life than on the Kindle. My second issue also stemmed from this, with some of the visuals being hard to read on the kindle. My final issue was the constant use of the word, “resources,” when I’m pretty confident the author meant, “people.” At least in many cases.

Highly recommended. Grab a copy now!

Agile methods and practices went mainstream over the last two decades. We’ve improved our architectural, technical and processes landscape. It’s time we pushed our management and leadership practices even further. An Elegant Puzzle is a great addition to the field of engineering management.

Get a copy of the book here.

What hypergrowth is like at N26

March 13, 2019 / Patrick / 2 Comments

It’s an understatement to say that N26 is experiencing hypergrowth. In August 2017, we had 450,000 customers. We now have more than 2.3 million customers, with many more joining everyday. We’ve almost quadrupled the number of people in tech in that very same time.

It is my first experience of working in a hypergrowth company as a permanent employee. Although the US has its large share of hypergrowth companies, Europe has very few. In this post, I want to share some lessons learned and insights.

What is hypergrowth?

You can find several definitions of hypergrowth on the internet. I like to describe it as a company experiencing a doubling effect in growth. Some refer to this as the snowball effect.

Or simply put:

“The game changes really, really, really fast.”
Patrick Kua

What does it feel like?

I’m sure I picked up this analogy elsewhere, but I can’t find the reference. Regardless, the imagery stuck with me.

“Working in hypergrowth feels like you’re building the spaceship as its flying”
Unknown source

Hypergrowth can feel chaotic. The organisation doesn’t grow at the same rate, so you feel where bottlenecks emerge. At the same time, a few weeks later, the constraint is often resolved and moved to a different area. Hypergrowth means constant but rapid change. Upon returning from a week’s holiday, many people ask, “What’s changed?” They know that somewhere a team structure, process, or decision has changed.

Hypergrowth means uncertainty. I am comfortable stating what I think may happen in three or six months time. I’m also used to being wrong. I try to put statements about the future into context, explaining possible alternatives.

Hypergrowth demands new capabilities and skills. I read how an organisation grows exponentially faster than individuals. I’ve seen this first hand. Skills take time to develop mastery. An organisation requires that skill now. Although you can wait for people to learn all the required skills, I’ve learned you need to support both. Allow people to grow, but also bring in expertise to learn from. This is why I am a big fan of pair programming (or pairing in general). It’s a great way of transferring experience across people.

Why work in an environment like this?

You may be reading this and wonder, “Why on earth would I want to work in an environment like this?” Here are five reasons why it’s worth it:

New problems to solve – Engineers love tackling new problems. Our product changes all the time. We improve the security build into our product. We look at ways to scale our systems and improve our ways of working.
New skills to develop – New problems and a changing environment forces people to build new skills. I have seen so many people grow in many different ways.
See a business “grow up” – Every six months, it’s like working with a new company. At the same time, you have personal relationships across the business. This means you’re now always starting from scratch. What started out as a single person may now be a whole team. What was once a whole team may now be an entire department.
Ability to have a big impact – Our founders have a broad mission. It’s exciting to work on something that millions of people use. It’s also great to be a B2C product where you get to use your own product too!
Everyone can be a leader – Some people may get hung up on titles. Like I wrote in a previous blog post, everyone can be a leader. There are always opportunities to show acts of leadership and have immediate impact.

How we support people

Although everyone owns their personal career paths, I’ve tried to support people as much as I can. I run an explicit Tech Lead Development Program. This gives people explicit expectations and tools about how people in or heading towards a Tech Lead can improve their impact. Leaders build other leaders. We’ve been deliberate in how we structure our Product and Tech teams. I introduced a Target Operating Model. The Target Operating Model represents a written down mental model of how we’d like to work. This often incorporates new roles, structures and explains the why and the what. Although we experience hypergrowth, it doesn’t mean we do so without trying to shape it.

We listen for feedback throughout the organisation. The leadership team takes a company wide pulse on a quarterly basis. Tech teams use retrospectives to take on improvements. Organisational smells outside of influence of a team get escalated and we try to deal with them as much as we can.

I tried to create as much transparency as possible. We have a shared product roadmap. As a company there are updates about events announced at the start of each week. We end the week with company wide celebrations.

Is this for you?

I will admit that this environment is not for everyone. Our environment may be suitable if:

You are looking for new and interesting challenges; or
You love an environment with constant change; or
You want to work in a place which tries to manage this intentionally; or
You are looking to rapidly grow and show acts of leadership.

We are always looking for new talent to add to our culture. Join me on our mission, to build the bank the world loves to use. Look at our open roles and apply now.

Book Review: Factfulness

October 14, 2018 / Patrick

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

August 11, 2018 / Patrick

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”

July 16, 2013 / Patrick / 0 Comments

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.

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

July 8, 2013 / Patrick / 0 Comments

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.

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

July 2, 2013 / Patrick / 0 Comments

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

August 19, 2012 / Patrick / 1 Comment

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):

Thinking, Fast and Slow – A book on cognitive bias, thinking and decision making
Human Systems Dynamics – Looking at how people shape mental models
Organizing Genius – Another book on team stuff and the secrets behind “brainstorming”
Birth of the Chaordic Age – The story behind VISA
Perceptual Control Theory – Another resource on mental models, influence and decision making.

Talking Feature Leads

July 15, 2012 / Patrick / 11 Comments

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

March 31, 2012 / Patrick / 4 Comments

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.