patkua@work

The intersection of technology and leadership

Category: Lean (Page 1 of 3)

Book Review: The Lean Enterprise

February 9, 2015 / / 1 Comment

This weekend I finished reading a copy of The Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly.

Top level summary: If you want to learn about the truly agile organisation, this is the book that shows you what it looks like.

The Lean Enterprise

I have read many books about agile, lean and organisations that build software, but this is the first that really brings it all together. Other books tend to be either too theoretical (founded from either Drucker or Taiichi Ohno) or with a very practical toolkit in a very narrow domain.

This book is aimed at executives and managers or organisations – the people with the authority to change to change the system. We know from W. Edwards Deming:

A bad system will beat a good person every time.

Like a book that was actually test driven by real-life questions, it provides answers to questions executives and managers ask time and time again.

The book is packed with information and provides solutions to problems that organisations, doing agile software development, struggle with in other parts of their organisation. Better yet they offer many examples of companies who are doing it right, proving that it is not just theory and that it can be done in many ways. There are many great stories from many industries demonstrating how different approaches can be yet still exhibit the lean attitude and culture that is so essential to success. I am also glad how much the authors focus on the importance of culture (and what people can do about it) and not just a single focus on either theory or tools.

The authors have done their research well, with excellent, tangible examples of lean concepts, practices and tools linked to much more detailed reading in a referenced article, paper or book. I would almost buy this book only to give people the reading list in the back – it is really that good. I have read many of the books referenced, and I remember how they challenged and changed my thinking in a positive way. After this book, my own personal reading list is also much richer.

What makes this book especially stand out for me is the pragmatic nature of the book. Even though, to many readers, the contents may appear idealistic or too unrealistic, the authors have given many examples of companies doing it, refer to many case studies or experiences where they have seen the practices and principles at work and shown their own insights into the challenges or dangers that lie ahead. This last part speaks volumes to the authors sharing their experiences about the questions some organisations have not even asked yet and advice on how to solve it. One good example is the paradoxical nature of balancing exploration through prototyping (discovery) against the disciplined nature of continuous delivery (e.g. additional work of well refactored code, tests and scripted deployments).

When I got to the end of the book, I knew that I would need to re-read the book for a deeper understanding because it is so rich with concepts and tools – some I have not had the chance to try out.

A perfect match for the target audience it was written for and a book that will continue to be relevant for many years to come.

Disrupt yourself, or someone else will

October 25, 2013 / / 0 Comments

A couple of days ago, Apple announced their new range of iPads including a mini with a retina display and a lighter, thinner full-sized iPad. Notice anything strange about their prices?

iPad2 Pricing

As can see the new mini retina priced at exactly the same price point as the (old) ipad2. Seem strange? You’re not the only one to think so as outlined by a comment from this appleinsider article.

Comment

This isn’t the first time Apple have priced a new product at the same as an older product (and probably won’t be the last).

The Innovator’s Dilemma
In the book, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, the author shows organisations that fail to embrace new technologies because they focus on the success of a single product or technology.

By offering these lines (new and old) Apple effectively segments their market into the early adopters of technology while providing (older and probably less appealing) options to all others. A conflict of features (retina display in a smaller form factor) makes users decide what is more important to them.

By removing the older iPad2, they effectively force consumers to move to the new platform and some of their customers may be happy with the existing product. Apple is effectively disrupting themself before their competition can.

Uses our cognitive biases

Having the same price point for a newer technology also taps into the anchoring cognitive bias (sometimes called the relativity trap).

Without the older product in the lineup, the newer products would not appear so appealing. The “anchor” of the older product is effectively pushing people to the newer products.

A person would ask:

Why would I buy older technology for the same price?

and then make the trade off for a smaller size, or if they want a newer size, pay another premium for it.

Showdown: Systems Thinking vs Root Cause Analysis

July 2, 2013 / / 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.

Fight
Image courtesy of tamboku under the Creative Commons licence

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

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

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

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

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

Being agile instead of doing agile

May 23, 2013 / / 10 Comments

My last delivery gig was a great reminder about keeping the principles and values of the Agile Manifesto in mind. It was unlike any agile method that you would probably recognise.

We were building a prototype system to demonstrate the capabilities of a technical standard and the data that it contained. Our main stakeholders, both relatively non-technical knew the type of audience the prototype was intended to influence and making a technical standard come to life with an interactive prototype was our remit. We had free reign of how we worked, the technology we used but our approach consistently remained true to the agile set of values and principles – focused on value through the demonstration of working software in a collaborative and adaptive manner.

I think about how we worked at the end of the project, and it looked nothing like how we worked at the start of the project.

Communication was key

Our small team was highly distributed – our two stakeholders located in one part of Switzerland, two of our team members (mostly working) in Germany, one of our team members moving between London, Germany and the client and myself where, during one week was in London, Manchester and then Germany. We knew communication was going to be tough. Our first step was ensuring we kicked the work as a team together in the same place. We spent the first week working with a large variety of industry stakeholders, understanding their concerns, the issues the new standard was going to address, and trying to get into the heads of our own stakeholders about what they were trying to do. This time turned out to be essential in guiding our future work and helped us connect the “what” to the “why”.

With our high level of distribution, we knew that we would need to do multiple channels of communication. We started off with daily stand-ups using video conferencing software with our stakeholders, which later turned into daily showcases at some point to help us further plan more work. When one of our team members moved remotely, we even did daily afternoon stand-ups to ensure that we kept synced with any major shifts in the day.

We experimented with many forms of chat software early on. We tried google hangout (but it seemed to turn one of our machines into furnace), we tried group skype, we tried google chat and we ended up settling up on chatzy as a way of having a persistent chat. We evolved a protocol of trying to have conversations in the chat room, so that when our remote member came back from meetings with stakeholders, they could easily answer and respond.

We experimented (probably half-way into the project) with leaving our video conferencing software (GoTo Meeting) on when one of our members were remote so that it felt like they were in the room and they could see us in the room. A spare laptop (our build server) and a simple crate fixture to prop it up so they could see us worked well.

We gave up using a physical wall in favour of an online card wall (Trello) as a mechanism for sharing work. Our ability to concurrently edit/update that turned out a great way of capturing and sharing notes.

Daily planning and story-writing sessions

Our “stories” were small. Our technical team of two developers, a user experience/front-end designer could churn through a lot in this context (moving between 20-40 stories per week) and we worked hard to ensure that we identified and split stories based on new needs and feedback from our stakeholders.

When we first started off, we started off doing a story-writing session to tackle our initial user journeys. The first session, I remember being remote and we were still able to “sit down” as a group and do a brainstorm. We set aside fifteen minutes, and split in two sites (me remote) and the rest of the team in one place we all got index cards out and brainstormed potential user stories. I used the in-built video camera in my laptop to share my index cards and they did the reverse as we talked through each one via video conferencing software. At some point, further on in the prototype, we moved to a daily planning session where we’d capture ideas directly into our online card wall.

Continuous Deployment

We still had a small build pipeline into production with a handful of unit tests to sanity check our final product that would automatically deploy the latest build into our “production” environment. I’m not sure, but I would guess that we deployed into production at least twenty times a day (as a team) and our stakeholders were surprised to see the system evolve even as they were interacting with it.

Even during some showcases, we were able to fix small issues (such as wording, placement) and have it appear a few minutes later.

Automated unit tests for quick feedback and design

Given it was a prototype, we were clear we didn’t need to have as much automated testing in place for a system that would have a very short shelf life. For us, testing goes beyond validating the behaviour you expect to a mechanism to drive design. If it’s hard to test, there’s probably something about the design that needs to change. For us, our tests provided two mechanisms – fast feedback about when to address code smells, and the other was to validate the simulated data model that needed to represent “realistic data.”

Given the domain our prototype worked in, our clients needed a balance where they didn’t want any real examples, but they wanted “realistic” samples. This means that we ended up modelling our customer’s domain in a way that let us generate new datasets easily. As an example, when we needed to extrapolate a “points based system” based on constraints that someone ran a search by, we only needed to touch one class to generate data that we tested as quite realistic against end users of the system. Prices had a relationship between the brand of the product and class of service, and this was just as easily modelled. Our unit tests allowed us to evolve characteristics of our model before plugging in new inputs to generate different outputs.

Poly-skilling or anyone could fulfill any responsibility

We all took part in story-writing. We started off with our analyst taking care of tracking progress, but we quickly moved that responsibility to a developer so that they could better use of their time testing the system with end users, and distilling the feedback from the large number of sources.

Our user experience designer was fantastically competent as a front-end developer and even let us lonely developers have a go at reworking some icons that needed adapting based on user feedback because his time was better spent looking at overall flow.

We took time out as a group to take part in exploratory testing trying to find weird user-nuances, edge bugs compiling them into a google spreadsheet before working with our stakeholders to feed them back into work.

Everyone on the team had a go at facilitating retrospectives and organising the feedback sessions that gave us the steer on which further direction to move in.

As a team, we made sure that everything that needed to happen happened without being precious about who did it.

Continuous reflection and continual improvement

Although we held a small handful of retrospectives, they weren’t our only opportunity to improve. If someone wanted to try something, we gave it a go for a day and then worked out if we wanted to continue doing it. Some things died off if someone felt we weren’t getting value from it. Other things just continued on because it seemed to work for us.

Developing social connections in the team

One activity we used to kick off our team was also to be explicit about some of our natural preferences – such as what sort of chronotype we were.

I think one thing that worked really well for us was having lunch together when we were in the same location. Mostly this was in Germany, which has a culture of having a sit-down lunch rather than the grab-and-go culture in the UK. I think this helped us bond as a team, and we grew to know each other more, sense each other’s working preferences and just get a chance to know each other much more.

What is Failure Demand in Software Development

May 23, 2013 / / 4 Comments

The idea of “Failure Demand” comes from systems thinker, John Seddon, who describes it as “unnecessary burden on the system.” By looking at removing failure demand on a system, you free up more capacity to focus on value added work. Much of failure demand also maps to the lead concept of “waste” although not all “waste” is the same as failure demand.

Some classic examples (and tell-tale signs) I see with companies include:

  • Poor quality work – Features that are not tested, or well designed end up generating bugs. A smell to look for is lots of issues reported by end users. Lots of errors in production logs are also another great smell for detecting this.
  • Features designed without thinking about User Experience – Without putting the end user of a system in mind, many organisations build functionality without exploring how/why an end user of their system will end up using it. Working with an effective user experience capability means simpler, clearer interfaces that help end users get the job done. Smells to look out for include interfaces that have too many additions or features added to it.
  • Requirements solely driven by a Product Manager – Many organisations rely solely on the HiPPO (the Highest Paid Person’s Opinion) to drive requirements. Although a Product Manager role is still useful for other reasons, faster experimentation and data collection of testing hypothesis is of use. Look out for smells like long release cycles, date driven requirements, or large backlog requests of detailed “user requirements” specified by the Product Manager without real involvement or feedback from end users.
  • Misunderstandings – As a software organisation grows, the communication channels significantly increase. When people do not validate their understandings with each other, they end up doing more rework than necessary. Depending on how complex the problem space is, using visual models, workshops that explore a certain approach and simply showing progress constantly (daily or weekly basis) help to resolve this.

What other examples of failure demand do you see? Please leave a comment.

Book Review: Taiichi Ohno’s Workplace Management

May 5, 2013 / / 0 Comments

Workplace Management On my most recent plane trip, I got a chance to read Taiichi Ohnos Workplace Management: Special 100th Birthday Edition. It’s a book, translated and written down from a series of narratives and distilled into a small set of digestible chapters full of short stories. It has a pretty great representation of many of his ideas, and is a great read about the philosophy and attitude behind Toyota, and ultimately the movement classified as lean thinking/manufacturing, etc.

I found the book sometimes jarring, perhaps it’s just the conversational style and the translation that means it’s a bit halting. The constant references to manufacturing terminology also makes it slow to digest, but I find it fascinating to see how many of these ideas easily translate into the world of software as well. The book touches upon a little bit of thing when he goes on to analyse the difficulties of the “white collar workers” and how it’s much harder for them to “go to the gemba” to see the results.

Much of the advice is still appropriate today. Many take aways reinforce many of the ideas espoused by many of the lean movements such as tool makers should not be separated from the tool users, or they end up creating tools that are not useful. The idea that improvement cannot be mandated centrally, away from the “gemba” but must be done by the people “on the gemba”.

The book also starts off with his attitudes towards people being human, the the problems that we have with our own mental models or misconceptions that lead us to be wrong. Chapters like “The wise men mend their ways” and “If you are wrong, admit it” are good examples of how to cope with these human traits.

The book is a short read, and is full of nice little soundbites. Probably my favourite out of the book is:

“There are so many things in this world that we cannot know until we try something. Very often after we try we find that the results are completely the opposite of what we expected, and this is because having misconceptions is part of what it means to be human”, in the Chapter: “If you are wrong, admit it”

Looking back at a year with a client

December 7, 2012 / / 1 Comment

Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.

Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:

  • 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
  • Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
  • 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
  • Marketing deadlines announced well before the development team had been engaged – A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
  • PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.

Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:

  • Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
  • Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
  • Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
  • Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.

At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:

  • Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
  • Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
  • DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
  • Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
  • Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
  • Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
  • Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.

Other particular things I’m proud of the team:

  • Taming the Hippo – Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
  • Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
  • Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.

Things that I would like to be different:

  • Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
  • Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
  • Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.

Poka-Yoke Your Developers

July 3, 2011 / / 0 Comments

Poka-Yoke is a term coming from lean manufacturing and is about error-proofing, or preventing an error happening in the first place. A few weeks ago, we were working on fixing those flaky tests. A cause is the bad testing strategy, trying to set mocks on objects held by spring globaltons.

The previous developers had apparently known about this and went through diligently fixing each tests by ensuring that any test setting a mock was reset to its proper form. Unfortunately this knowledge wasn’t passed on to our team, and wasn’t obvious from the intent of the tests. More than that, it was easy to add new tests of this style and forget to reset the objects registered in spring.

Wanting to apply Poka-Yoka to our situation, we wrote something that would check the precondition that there were no side effects from other tests. Our implementation meant adding a @Before method to the base class these classes all shared that would cycle through all objects registered in spring, noting if any of their internal fields had been left mocked. If anything was detected, our assertion failed message contained a message that would explain why it was there and what to do about it. By adding this in, we actually found three existing tests that failed to clean up properly after themselves.

Poka-Yoka is fairly easy. When thinking about applying it, think about a solution that prevents the error happening more than once. Ideally this means that error is unavoidable (in our situation – this would mean changing the testing pattern across all tests), or at least by bare minimum, provide feedback when a person repeats the mistake.

Boosting Hyper Productive Teams

March 29, 2011 / / 0 Comments

I’ve been in the fortunate position of building up a small team since the start of the year. It’s the first “official” tech lead role I’ve had for a couple of years and I’m proud to say that we have a pretty rockin’ team. Blending and appreciating lean ideas into how we work mean that we’re in a pretty good position all around.

Building what matters
The project work for this client meant tight deadlines. For once, it’s not just because the detached marketing arm committed to some random date without asking about how likely it would be. This one was based on pure legal compliance by a certain date. Although arguably arbitrary, it certainly has some merit (e.g. if we don’t do this, we simply cannot operate business in this country). All my UX buddies will be proud, championing the end user and what is it that need to be able to meet compliance. This neatly fits in with the systems thinking point of view – rather than building what we think we need, talking to people who actually did similar jobs and finding out what their problems and way of thinking was. We drilled out some personas, worked out some user stories, attempting as best to map them out.

Building strong teams
Teams are forged around a common purpose. Not because they simply sit in the same room. Calling a group of people a team does nothing to change they are, in fact, just a group of people. Although it took a while for the entire team to settle into shape (we had one join in here or there), we tried building a Team Charter to help understand what it is we valued in each other, and what our expectations were of each other. We took time to make clear roles, responsibilities, and who most people expected to fulfill those responsibilities, remembering that roles do not map 1:1 to people.

I think it’s helped that everyone comes from such diverse backgrounds. We have two British people, one German, one Polish, one Indian, one Pakistani and myself, the Australian. It’s useful to find common interests and cultural interchange as another team building exercise.

Preventing impediments and swarming around those that appear
Risk mitigation and issue management isn’t about simply identifying them in some spreadsheet and leaving them away. Instead, it’s about the rigourous act of trying to prevent them from happening as early as possible and dealing with them. We knew pretty early that the development time to meet this criteria would be tight, so we focused on ensuring as smooth a flow of work through the cycle. I won’t admit that we used kanban without explicit work-in-progress limits, however this doesn’t mean that we didn’t apply the Theory of Constraints. We choose development (coding) as our bottleneck, creating tools to optimise testing, and ensuring minimal rework by being thorough in putting work ready to be picked up. Me (as tech lead), our QA, and BA would sit down to tackle features from different angles and building consensus with our Product Manager. As a result, I can’t think of many stories where we discovered information too late, or ended up with large amount of rework. I hope that everyone else has appreciated the flow.

Two weeks away and things still ran fine
It’s a strong test that I always ask people in leadership positions. How would you feel if you couldn’t talk to your team/organisation for a day? For a week? For two weeks? With a properly built team/organisation people should be capable of working out problems without you. I would worry about not just the signal, but what it says about your leadership style, if teams could not last without you. Fortunately one week of skiing and another week for a conference and I came back to a team happily churning along (although there was one event early on that seemed to knock the team’s confidence).

Retrospecting on the Retrospectives
Strangely enough, we’ve only run about two or three proper retrospectives. The first time, our QA remarked on how this had been their first session where the Went Well’s far out numbered the Less Well’s. For the other one, the only things that came up in the Less Well’s were organisational things we knew about, and had either actions pending for or were things we realistically weren’t going to be able to change.

Experimenting
I strongly believe most organisations waste human talent, passion and energy when you can’t create a good environment for them. I feel like we’ve done a pretty good job. We finished development complete of our critical legal requirements two weeks early with one developer less than originally planned and nearly through the next “nice-to-have” tranche of work.

I believe most teams would benefit the most by removing impediments, and creating flow. Unfortunately I don’t think most teams get there. However, once you are there, I believe the next best thing you can do is to experiment and trial new things. I’m trying to encourage our PM to let go of estimation and working out how to encourage just the right level of experimentation.

Systems Thinking: The Leaders Summit

November 25, 2010 / / 0 Comments

I was fortunate enough to attend The Leaders Summit organised by John Seddon’s company, Vanguard. The day unfolded with plenty of people talking about applying systems thinking/lean thinking to various environments.

Given Seddon’s experience with the public sector, I wasn’t surprised by the large number of people from other public sector organisations. In fact, given the perceived ineffectiveness of many public services, I’m all for this enthusiasm and interest.

Some of my key takeaways follow, however it’s definitely worth while checking out the, very much more detailed and thorough, blogging from Benjamin Mitchell here.

Change is hard – agile transformations, same for systems thinking transformations
A lot of the presenters talked about the difficult positions they were in before looking toward systems thinking. They all had their critics, all the usual people not wanting to do things differently, and support or lack of support from management. For example, one speaker, Denise Lyons from East Devon District Council encountered the “That’s how we’ve always done it around here” mentality.

Another speaker had to sneak their change program through existing mechanisms for change and business efficiencies. Even the questions asked by the audience reflected this.

I found this interesting as these are often the same problems we see, trying to introduce agile values into the software delivery capabilities of organisations. Even many of methods for helping people with change were the same.

Pragmatic Improvement
One of the questions we often struggle with, applying lean and agile to the software delivery part of an organisation, is should we really be working on the entire organisation structure. Listening to some of the speakers is that it’s worth starting somewhere and build on that success.

Rob Brown talks about the long changes still to go rolling systems thinking out to the rest of the organisation, but there was plenty of value already generated by implementing it in that area. For example, they still have to deal with the HR challenges of annual appraisals and all the budgeting games of the larger organisation.

All the speakers emphasised the way of starting small, and building on that success. Of course, this still ensures that you take as large of a systemic view as much as possible. Some of the constraints will be out of your control.

Labels don’t really matter
As much as everyone used the labels of the Vanguard consultants, I found it refreshing to hear about people really understanding the ideas behind lean thinking from a systems perspective without getting too hung up on the labels. One of the people talked about instead of “interventions”, they did “reviews”. It was also refreshing to get Dr Steven Allder, someone who came to systems and lean thinking through Peter Senge who didn’t use the same labels but you could see the same thinking behind it.

« Older posts

© 2024 patkua@work

Theme by Anders Noren — Up ↑