The Agile Transformation Conundrum

ParadoxI’ve been thinking recently about what it means to go through an Agile Transformation. The usual interpretation I find is that its a Transformation to using Agile approaches (or doing Agile), or if I’m being generous to being Agile. At first glance, that seems wrong to me for a couple of reasons.

Firstly, it implies that the Transformation has an end state – doing (or being) Agile. Once we are Agile we have Transformed. Yeah! I think that the transformation should be continuous, however. The Transformation is in learning how solve problems, and not learning how to implement solutions. It is learning how to Learn.

Secondly, it implies that Agile as an end state is a primarily tactical endeavour. The focus is on Agile itself, rather than on the aspirations that Agile might help achieve. I prefer to focus on how Agility can strategically help achieve aspirations.

And yet a call myself a Lean & Agile Consultant, because essentially that’s where my experience and skills lie. I don’t consider myself to be an expert in strategy development (although its an area I’m learning more and more about). That seems to be a conundrum because on the one hand I generally work with Agile Transformations, and on the other hand, my focus isn’t on Transforming to Agile.

How to resolve that conundrum? Well I could talk more about Agility Transformations to put more emphasis on strategic agility? Or I could go meta, and talk about transforming to a state where we can continually transform. A Transformability Transformation? Except I’ve just made a word up, so how about an Adaptability Transformation?

Or I could just learn to live with Agile Transformations 🙂

Good Agile/Bad Agile: The Difference and Why It Matters

kernels and bugsThis post is an unapologetic riff on Richard Rumelt’s book Good Strategy/Bad Strategy: The Difference and Why It Matters. The book is a wonderful analysis of what makes a good strategy and how successful organisations use strategy effectively. I found that it reinforced my notion that Agility is a Strategy and so this is also a way to help me organise my thoughts about that from the book. 

Good and Bad Agile

Rumelt describes Bad Strategy as having four major hallmarks:

  • Fluff – meaningless words or platitudes.
  • Failure to face the challenge – not knowing what the problem or opportunity being faced is.
  • Mistaking goals for strategy – simply stating ambitions or wishful thinking.
  • Bad strategy objectives – big buckets which provide no focus and can be used to justify anything (otherwise known as “strategic horoscopes”).

These hallmarks can also describe Bad Agile. For example, when Agile is just used for the sake of it (Agile is the fluff). Or when Agile is just used to do “the wrong thing righter” (failing to face the challenge). Or when Agile is just used to “improve performance” (mistaking goals for strategy). Or when Agile is just part of a variety of initiatives (bad strategy objectives).

Rumelt goes on to describe a Good Strategy as having a kernel with three elements:

  • Diagnosis – understanding the critical challenge or opportunity being faced.
  • Guiding policy – the approach to addressing the challenge or opportunity.
  • Coherent actions – the work to implement the guiding policy.

Again, I believe this kernel can help identify Good Agile. When Agile works well, it should be easy to answer the following questions:

  • What diagnosis is Agile addressing for you? What is the critical challenge or opportunity you are facing?
  • What guiding policy does Agile relate to? How does it help you decide what you should or shouldn’t do?
  • What coherent actions you are taking that are Agile? How are they coordinated to support the strategy?

Sources of Power

Rumelt suggests that

“a good strategy works by harnessing power and applying it where it will have the greatest effect”.

He goes on to describe nine of these powers (although they are not limited to these nine) and it’s worth considering how Agile can enable them.

  • Leverage – the anticipation of what is most pivotal and concentrating effort. Good Agile will focus on identifying and implementing the smallest change (e.g. MVPs) which will result in largest gains.
  • Proximate objects – something close enough to be achievable. Good Agile will help identify clear, small, incremental and iterative releases which can be easily delivered by the organisation
  • Chain-link systems – systems where performance is limited by the weakest link.  Good Agile will address the constraint in the organisation. Understanding chain-link systems is effectively the same as applying Theory of Constraints. 
  • Design – how all the elements of an organisation and its strategy fit together and are co-ordinated to support each other. Good Agile will be part of a larger design, or value stream, and not simply a local team optimisation. Using design is effectively the same as applying Systems Thinking. 
  • Focus – concentrating effort on achieving a breakthrough for a single goal. Good Agile limits work in process in order to help concentrate effort on that single goal to create the breakthrough.
  • Growth – the outcome of growing demand for special capabilities, superior products and skills. Good Agile helps build both the people and products which will result in growth.
  • Advantage – the unique differences and asymmetries which can be exploited to increase value. Good Agile helps exploit, protect or increase demand to gain a competitive advantage. In fact Good Agile can itself be an advantage.
  • Dynamics – anticipating and riding a wave of change. Good Agile helps explore new and different changes and opportunities, and then exploits them.
  • Inertia and Entropy – the resistance to change, and decline into disorder. Good Agile helps organisations overcome their own inertia and entropy, and take advantage of competitors’ inertia and entropy. In effect, having less inertia and entropy than your competition means having a tighter OODA loop.

In general, we can say that Good Agile “works by harnessing power and applying it where it will have the greatest effect”, and it should be possible to answer the following question:

  • What sources of power is your strategy harnessing, and how does Agile help apply it?

Thinking like an Agilist

Rumelt concludes with some thoughts on creating strategy, and what he suggests is

“the most useful shift in viewpoint: thinking about your own thinking”.

He describes this shift from the following perspectives:

  • The Science of Strategy – strategy as a scientific hypothesis rather than a predictable plan.
  • Using Your Head – expanding the scanning horizon for ideas rather than settling on the first idea.
  • Keeping Your Head – using independent judgement to decide the best approach rather than following the crowd.

This is where I see a connection between Good Strategy and Strategy Deployment, which is an approach to testing hypotheses (science as strategy), deliberately exploring multiple options (using your head), and discovering an appropriate, contextual solution (keeping your head).

In summary, Good Agile is deployed strategically by being part of a kernel, with a diagnosis of the critical problem or opportunity being faced, guiding policy which harnesses a source of power, and coherent actions that are evolved through experimenting as opposed to being instantiated by copying.

Trains, Shopping and the Risk of Release Dates

This is a final post originally published on the Rally Blog which I am reposting here to keep an archived copy.

trainsI live in Brighton, on the south coast of the UK, about 50 miles from London. This means that I regularly catch the train for meetings or engagements “in town”. When making the journey, I always look at the timetable. Trains only run every 30-60 minutes, so if I get the timing wrong, then I’m most likely left hanging around at the station. Not a great use of time, especially with the typical British weather. When I get into London and need to catch the tube somewhere, however, it’s a different story. I just head to the right platform and wait for a train, knowing that one should turn up in a few minutes. There’s no need to check the timetable.

What does this have to do with Agile? I was recently on a Q&A panel and fielded a question about how to deal with fixed date and scope projects. The story above hints at the answer…

Managing Variables

Before we come to that, let’s first look at the common ‘Iron Triangle’ variables of time, cost and scope. If the date (and hence time) and scope are fixed, then logic suggests that the only thing we can vary is cost. This typically means adding people, although it could mean throwing money at the problem in some other way. Brooks’s Law, “Adding manpower to a late software project makes it later”, says that this will not work. An Agile approach can mean that any problems meeting the date and scope will be discovered earlier, and hence the effect of Brooks’s Law can be minimised. Colleague Alex Pukinskis recently blogged about how the Rally development team cheated Brooks’s Law with such an approach.

If varying cost isn’t an option, then there are a couple of other options. The first is cutting corners and reducing quality. Note that I am not recommending this option! Having said that, if the date is critical for learning and feedback regarding a value hypothesis, then quality may be less critical, assuming quality will be built in once the value is well understood.

The other variable is fidelity — this is the finesse of the solution. Delivering a low fidelity solution first ensures that scope can be met early. The functionality can then be iterated on to increase fidelity, knowing that when the date arrives — scope is in the bag.

The Alternative

There’s a less obvious solution to the problem, however. Date and scope are often fixed as a reaction to the risk of “missing the train”. We want to be sure of what we get, and when we get it, because if functionality doesn’t make it into a release, we don’t want it left on the platform waiting for the next one. We can address that risk in another way.


Here’s another example. We (ok, well, my wife) generally do a weekly shop at a nearby out-of-town supermarket. Because it’s weekly, we spend time planning by putting together a shopping list, thinking of everything we might need during the week. After all, if we don’t get everything we need, it will be another week until the next shop. This often results in over-stocking and the waste of throwing out unused perishable food.

However, when we go and visit a friend who lives in the small village in the Lake District, we just pop into the local shops every day to get whatever we fancy for that day. There is no need to plan ahead or make decisions on what we are going to eat days in advance. The local produce might be slightly more expensive than the big supermarkets, but it’s higher quality and there’s less wasted food. We trade-off a slight increase in cost for higher quality, deferred decisions and less waste.

So instead of worrying about how to deliver to fixed time, scope and cost constraints (not to mention quality), I would recommend figuring out how to release more frequently.

If your releases are like a tube train, arriving every day or so, then the need to plan time and scope lessens. Planning and implementing in smaller batches significantly reduces the cost, allowing more time to build the desired scope by the desired date. If a feature misses a release, it can just go into the next one straight after.

Try this approach and let me know how it goes!



A Community of Thinkers – For Jean Tabaka

In late 2013, Jean Tabaka, Eric Willeke and Liz Keogh came up with the idea of a Community of Thinkers, with a statement about what that meant to them. Rather than post it centrally, they each posted it individually, and encouraged others to copy and paste if they agreed and supported the notion.

I never did. I don’t know why. But in light of the recent devestating news about Jean’s passing, I have decided better late than never. Jean was a wonderful person. A friend, mentor and colleague. I have many great memories of her kindness and love of life. I learnt so much from her. I am grateful that the outpouring of emotion on social media shows how many lives she touched. This seems like a great way to remember her. What if we could embody the Community of Thinkers?

“A Community of Thinkers”
I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

  • reflect and honor the practitioners who make its existence possible;
  • provide an excellent experience for its members;
  • support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
  • exemplify, as a body, the professional and humane behavior of its members;
  • engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
  • embrace newcomers to the community openly and to celebrate ongoing journeys; and,
  • thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Agility is a Strategy, Agile is a Tactic

Agile Manifesto

Ron Jeffries recently blogged about his reflections on the Agile Manifesto, and what he wished the authors had done and said differently with hindsight. His conclusion was that he would have rather focussed on practices.

I have a different perspective.

My concern with an even stronger focus on practice is that it would lead to even more Cargo Culting than we see already. People simply copying practices they see and hear about in the hope that implementing them by the book will magically lead to them being Agile. We would end up with more teams using the autonomy encouraged by Agile to choose the way they work, but with no alignment to the original goal of improving business results.

Worse still would be even more conversations about things “not being Agile” than we see today. As Jabe Bloom recently tweeted: ‘the statement “X isn’t Agile” fills me with meh‘.

I much prefer Joshua Kerievsky’s take on what he calls Modern Agile. I think he has taken the opposite approach by trying to take what we have learned over the last 20 years and describe the intent. I would describe what he calls disciplines as strategies, and I believe the transformation of an organisation to have greater agility to be an example of what the Lean community call Strategy Deployment.

Let me explain.

Strategy Deployment, like most Lean ideas, has its roots in a Japanese term, Hoshin Kanri. The literal translation is “Direction Management”, but a more colourful translation “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety. Thus Strategy Deployment is an approach to organisational improvement which engages he entire workforce in figuring out how the business can survive and thrive.

Significantly, this means a shift from organisations operating on the basis that senior management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that they know the right answers as a facts, Strategy Deployment assumes that any suggestions are opinions to be explored and challenged, with the possibility that they may turn out to be wrong, and making it acceptable for people to change their mind.

What leadership proposes, therefore, is strategy, using it as a form of enabling constraint to guide and open up possibilities of what could be achieved. This is as opposed to defining tactics as a form of governing constraint, dictating action and closing down any alternatives that could be explored. A useful metaphor here is the one used by Dave Snowden of types of skeleton. An enabling constraint is like an endo-skeleton (e.g. humans) – formed on the inside, maintaining coherence and allowing growth. A governing constraint is like an exoskeleton (e.g. crabs) – formed on the outside, protecting and limiting growth.

By being clear on strategy, and allowing and encouraging the whole organisation to use their skills, knowledge and experience to discover appropriate tactics, it is possible to enable autonomy while maintaining alignment. In this light, all the various Agile practices are simply tactics (and very good ones) to help organisations achieve greater agility as a strategic goal.

In other words, Agility is a Strategy, Agile is a Tactic.

Although obviously its not quite a simple as that! I’m not sure that many executives would actually say that greater agility was a strategic goal. However, some of the primary outcomes that agility enables are relevant as strategic goals. I like to use the dimensions identified by Larry Maccherone as a starting point:

  • Productivity – amount of delivery
  • Responsiveness – speed of delivery
  • Predictability – consistency of delivery
  • Quality – delivering the thing right
  • Customer Satisfaction – delivering the right thing
  • Employee Engagement – delivering sustainably

And all of these would help achieve more general strategic goals such as focussing on new markets, regions, technologies, business models etc.

What’s all this got to do with the Agile Manifesto?

It seems to me that what the Manifesto authors had identifies was a different set of strategies to deliver successful software, and a thought experiment, I wondered what the Manifesto might it have looked like if it had been written as a set of strategies. I’m not suggesting actually rewriting it but it seems like an useful idea to explore. This is what I came up with:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work, our strategies have become to:

  • Empower teams around economies of flow
  • Reduce the batch size of value delivery
  • Explore the evolutionary potential of solutions
  • Sense and respond to feedback

Why did I choose those?

Empower teams around economies of flow – “Individual and interactions” is about people, working together as part of a value stream, using their collective expertise to maximise the flow of delivery.

Reduce the batch size of value delivery – “Working software” is about those teams  delivering valuable software early and often in smaller batches, using incremental and iterative approaches.

Explore the evolutionary potential of solutions – “Customer collaboration” is about working closely with customers to discover how to meet their needs through empathy and experimentation.

Sense and respond to feedback – “Responding to change” is about using the smaller batch size for knowledge discovery as well as value delivery, and using that information to create feedback for continuous change.

What would you choose?

This is just one interpretation. It was not an easy exercise deciding what to include, and what to leave out, and its at least the 3rd version I have some up with. I’m sure people will have different opinions. I’d love feedback on what they are! Please leave a comment on what your strategies are to achieve greater agility.

Agile Manifesto Strategies

Applying the Three Horizons to Agile Conferences

Relaxing after Agile2014, Eric Willeke made an off-hand comment about applying the Three Horizons Model to Agile practices. That struck me as interesting and got me wondering about how the concept could be applied to the Agile conference program.

ApplyingI have blogged about the model before as a way of thinking about value (although on reflection I’d now say its more about potential). To summarise:

  • H1 focusses on “extending and defending the core business”
  • H2 focusses on “building emerging businesses”
  • H3 focusses on “creating viable options”

The idea behind the model is to ensure a mix of investment across the horizons. Otherwise, if (or more likely when) the core business dies, it will not be ready with any new and alternative opportunities.


If we take these definitions, but think in terms of Agile practices, rather than businesses we get:

  • H1 focusses on “extending and defending the core practices”
  • H2 focusses on “building emerging practices”
  • H3 focusses on “creating viable options”

In this case, the Agile community would be ensuring a mix of investments across the horizons so that when the current core practices are no longer appropriate or useful, there will be new and alternative ones ready to be used in their place. That leads to the idea of having a conference program which includes an “investment allocation” in the different horizons. For example a 5 track conference could have 3 tracks on H1 topics, 1 track on H2 topics and 1 track on H3 topics giving a 60%/20%/20% allocation. Or a program made up of more traditional role/discipline/interest based tracks could allocate content across the horizons within each track.

The challenge, of course, would be agreeing on what topics are in which horizon. As an example, I might say Scrum and XP are firmly Horizon 1 as tried and tested methods. The various approaches to agility at scale might be Horizon 2 as they are still being explored and refined. Ideas from Beyond Budgeting or Cynefin might be Horizon 3 as they still being understood and experimented with.

The goal would not be to try and suggest any practices or approaches are any better or worse than other. The value would be in ensuring the longevity and continuing success of the Agile movement.

Feature Injection, Fidelity and Story Mapping

I’ve recently stumbled into a way of describing mid-range planning with a few teams which combines the language of feature injection, fidelity and story-mapping. As it seems to have been a successful way of communicating how to think about the strategic approach to incrementing and iterating through the work, I thought it would be worth writing down. Before I get into the combination, first an overview of what I mean my feature injection, fidelity and story-mapping.

Feature Injection

Liz Keogh has written a nice summary of Feature Injection. The main take-away is the language around starting with high level needs before working down to low level solutions.

Vision > Goals > Capabilities > Features > Scenarios > Stories

The key levels that I find valuable are those of capabilities and features leading scenarios and stories. I have noticed that I swap scenarios and stories around compared to Liz. I tend to think of scenarios as being detailed examples of stories rather than stories being the detailed description of scenarios. Something to talk to Liz about next time I see her. Either way, the approach is to start with a high level, more impact-based understanding, and gradually inject more granularity until you get to the actual output you want.


I first wrote about fidelity a couple of years back. I draw it differently now so here’s an updated description.

We regularly refer to vertical-slicing with agile approaches, where the vertical-slices are functional pieces which cut through the horizontal architectural layers.

photo 1

I find that teams who use vertical slicing, still often tend to increment the vertical slices so that they risk ending up with a product which is built up of vertical slices, yet still only 90% complete.

photo 2

One way I describe avoiding this is to make each slice thinner, and spread the slices across the overall scope before going back an filling in the gaps. Each thinner slices is a low-fidelity slice, and filling in the gaps increases the fidelity.

photo 3

Another way is to think of it, using a similar 3-d approach to my original post, is for the depth dimension to represent fidelity. Thus the first pass across the vertical-slices is a very shallow-fidelity one, and further passes increase the depth of the fidelity axis.

photo 4

Given that we are now slicing across the depth dimension, and depth gives us perspective, I’m thinking of calling this “perspective slicing”. Each slice gives a different perspective of the whole system.

I’ve also found the term fidelity useful just from a conversational aspect. Simple discussing what fidelity means for a particular product or service, and how it is different from quality, raises some good awareness of the approach. In particular, that a low-fidelity solution (e.g. one which has a basic interface or low robustness) can and should be high-quality (e.g. have a clean design and be sufficiently tested).

Story Mapping

Jeff Patton best describes the technique he calls story mapping in his own article. Essentially its a way of adding more context to a backlog by visualising both the breakdown of work from large user activities down to small user sub-tasks and task details, the relative necessity of those sub-tasks and details, and the overall relationships between the large user activities. The story map is used to focus on starting to build an early walking skeleton of the whole product or system.

Combining the Ideas

The combination of feature injection, fidelity and story mapping ideas isn’t really anything ground-breaking, or spectacularly new. In fact Jeff Patton’s description of what he calls a release readiness assessment is very similar. The way I do it is to use the feature injection language of capabilities and features to describe the higher levels of the story-map, replacing what Jeff describes as activities and tasks. Jeff’s sub-tasks or task details then become stories or scenarios and they are ordered by increasing fidelity rather than necessity. Thus the walking skeleton is a low fidelity perspective slice across all the capabilities and features of the solution. Further iterations increase the fidelity with further perspective slices.


Let me know what you have done which is similar or different!

Management Improvement Carnival

I’m honoured to have been asked by John Hunter to host an edition of his Management Improvement Carnival. That means that I get to pick a number of links to posts and articles on relevant topics. Here they are…

Agile Fluency

One set of posts that caught my eye was on Agile Fluency. The original post by James Shore and Diana Larsen proposes “a model of Agile fluency that will help you achieve Agile’s benefits. Fluency evolves through four distinct stages, each with its own benefits, costs of adoption, and key metrics”. Dave Nicolette responded that ” the gist of the article appears to be that we can effect organizational improvement in a large company by driving change from the level of individual software development teams. The major problem with that idea, in my opinion, is the bottom-up approach.” James then further clarified, by saying “Dave argues that the individual software teams in IT cannot drive bottom-up organizational change. I agree. Organizational change must occur if you want to achieve three- or four-star fluency, but our article doesn’t describe how to do so. It just says it’s necessary.”

Cynefin Agile Lean Mashups

One of the areas I have been involved in recently is in exploring how we can use ideas from social and complexity science to inform the theory and practice of Agile and Lean. This months CALM Beta event was specifically aimed at using Dave Snowden’s work with Cyenfin to do this. Dave has recently been blogging about his latest thinking on Complexity.

Employee Ranking

This link from Forbes has been doing the rounds in my twittersphere, describing how “a management system known as “stack ranking”—a program that forces every unit to declare a certain percentage of employees as top performers, good performers, average, and poor—effectively crippled Microsoft’s ability to innovate”. In response, Jabe Bloom described how “it’s been three years since we last ranked employees or gave performance reviews at TLC, and we think it’s working reasonably well.”

Agile Book

One of my colleagues, Bob Gower, has been putting together a book about Agile Business, including contributions from a number of Rally Coaches. “An important part of Agile is shipping things in a continuous and real-time manner. This is our effort of practicing what we preach. We are releasing the first increment of the book at the Agile 2012 conference to test how you think we’ve done—it’s not a complete copy of the book but enough we hope to whet your appetite.”

Introduction to Waterfall

Finally, here’s something fun I put together recently to help explain waterfall.


An Introduction to Waterfall

I was recently joking with some colleagues about what an “Introduction to Waterfall” course might look like. It turned out to be quite a simple proposition, so I quickly threw some slides together which I feel should be shared with the wide community.

Download the PowerPoint from slideshare for full effect, and please feel free to add some slide variations of your own!

Note: By waterfall, I mean “large-batch with stage-gate”. And remember this isn’t to be taken seriously – there may be contexts where that approach is appropriate…

Cynefin, Agile & Lean Mashups

IMG_05742012 certainly started with a bang for me (lets hope it doesn’t end with a bang!). After a relaxing Christmas and New Year, I was up at 6am on January 2nd to head for Almens in the Swiss Alps, and an intense few days with Simon Bennett, Steve Freeman, Joseph Pelrine and Dave Snowden. We gathered at Joseph’s house to discuss a common interest, namely how do we apply complexity science, and in particular the Cynefin framework, to Agile and Lean development.

Early on, Simon suggested the name CALM, and it stuck almost immediately. I like it for a couple of reasons. Mashups invokes the idea of “a creative combination or mixing of content from different sources”. That’s exactly what we want to do, and its the creative aspect that particularly appeals to me. A Cynefin, Agile and Lean Mashup will inevitably be created contextually. CALM also subtly counterbalances the XP extreme notion. While that’s not an intentional focus, I find it a mildly amusing reference.

My interest in Cynefin began back in around 2004 when Dave first spoke at XPDays London, and while back then I wasn’t smart enough to realise the full implications, fortunately others like Steve and Joseph were. I met Dave again at ScanAgile in 2009 and last year at the LeanSSC and ALE conferences. Simon also gave a great talk linking Scrum and Complexity more concretely at Agile2011, and I that’s when I finally figured out how Cynefin could match my interest in exploring the underlying theories behind Agile and Lean, and more specifically Kanban Thinking.

My personal goal for being involved in the meeting was to move Cynefin, and complexity science, from being something which is used as a justification, to something which provides meaningful explanation, and ultimately to new application. To keep the industry advancing, and to be able to apply Agile and Lean principles in increasingly challenging organisations, we need theory informed practices, as well as learning from our current success by evolving practice informed theory. In other words we need to take a scientific approach, which ties in nicely with my recent presentations on the Science of Kanban, which should make it to a blog post soon.

The primary outcome of the CALM meeting was the creation of CALMalpha. This is a two day residential conference to be held on the 16th and 17th of February 2012 at Wokefield Park in the United Kingdom. The alpha represents the notion that this is an initial safe-to-fail experiment where we hope to explore the subject in more detail, as we seek to find coherence, coalescence and convergence around what we do in the future.

More detail, including prices and booking information, can be found on the eventbrite page. I hope to see you there!