Category: Lean

Book Review: Taiichi Ohno’s Workplace Management

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

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

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

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

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.

Thoughts On Øredev

Last week Sweden’s Malmö hosted Øredev for the sixth time. I believe it attracted more than 1400 people, all with varying backgrounds and interests. Unsurprisingly, the majority of attendees turned out to be Swedish and Danish people (with Malmö very well connected to Denmark via their famous Baltic Ocean crossing train).

The Cultural Experiences
Being held in Sweden, the organising committee did well to treat us to some cultural delights including the Swedish sauna-Baltic Ocean run followed up by a delicious traditional fish meal). One of the organising members even welcomed us into their home for drinks before the speakers’ dinner where Glögg continued to keep the cold at bay. The difference of soaking raisins and almonds really surprised me. Malmö’s deputy mayor then welcomed us at their majestic townhall where all the speakers unanimously marvelled at the decadent surroundings. The meal stayed true to the region with first, a regional speciality, black soup (and yes, like black pudding, it has a very special ingredient) before following that up with a hearty roast goose meal and a spiced apple pudding for dessert.

Logistics and Organisation
The organisers impressed me with how smoothly the entire conference ran. Malmö’s Slagthuset (slaughterhouse) hosted the conference for the first time and although not all the spaces turned out ideal (with small walkways between some major rooms), I think it contributed to the friendliness and openness I discovered.

The organisers also did a fabulous job responding to attendee’s needs. For example, on Monday they moved a number of tutorials to warmer rooms after realising the strong draughts let in by workmen who still needed to complete their work. Another example is when they quickly disabled the authentication on the wi-fi when it proved to be another barrier to being connected. Unfortunately the wi-fi turned out to be a little bit flakier throughout the conference.

I also really enjoyed the evening entertainment that flowed into the venue rather than the “move to another location and lose people” approach several other conferences do. This helped to keep the conversation flowing (and we all love our flow!).

Topics
Øredev offered a huge variety of interesting topics with tracks covering mainstream languages such as Java/.Net, NoSQL, Agile & Lean, Collaboration, Patterns, Smart Phones and Architecture with lots of really interesting topics. I’d keep an eye out for their website and trawl the twitterverse (#oredev) for the interesting discussions.

The keynote presenters also turned out really well.

Dr Jeffrey Norris presented what he thought as agile values leading to mission critical success at NASA (Vision, Risk and Commitment) demonstrating through a “wow” 3D demonstration using the ARToolKit. He used the stories of famous inventors, particularly the rise of Graham Alexander Bell to emphasis these elements very effectively.

I saw John Seddon a few months ago and although I’d heard him present pretty much the same talk, appreciated his message was an important one that more people really needed to hear. I think there is great value in spreading his emphasis on holistic system thinking even further in the work that we do. Entertaining and very British, Seddon completed his keynote without leaning on any slides and to a very positive reaction from the audience.

I missed Henrik Kniberg‘s keynote so can’t really comment.

The final keynote came from Atari Corporation geek legend Nolan Bushnell envisaging what the next key software projects would be in the future. I think everyone enjoyed the talk simply because it was Nolan though I think wasn’t as executed as professionally as it could have been.

People to meet
One of the really great parts of Øredev was all the people around you. As one person put it, you could be talking to a person and then suddenly realise that they created X (where X = language, framework, tool, etc) or someone who wrote a lot of the blog entries that you’ve been reading. I think that the conference does a wonderful job of creating a really relaxed atmosphere for people to converse and the speakers are all really approachable and involved in all of the sessions as well.

I have to admit I also really appreciated the opportunities to connect to a number of fellow ThoughtWorks colleagues (both past and present) who I’d either not got a chance to meet, or hadn’t seen for a very long time. This is one of the consequences of working for a global consultancy – you get to communicate and build relationships for a distance yet rarely get to meet people face to face.

iPad observations
One huge point worth noting was the large role that the iPad played during this developer conference. Obviously, being fairly geeky I hadn’t expected so many of them yet it proved to be one of the best devices for capturing notes & particularly useful for reading and contributing tweets. Laptops lose out on both portability and, on average, a very so-so battery life.

Reading tweets to view session using the native iPad twitter client also worked really well without having to use the keyboard or mouse – this is where gestures and multi touch really shined.

My session
Chris Hedgate, organiser for the track on collaboration invited me to speak. Titled, “Tightening the Feedback Loop“, I spoke about how to give and receive more effective interpersonal feedback. I had some great tweets in response and some great feedback on the presentation (meta!) I’m encouraged that more people will be better equipped in their professional and personal life after attending.

Conclusion
I highly recommend presenting and/or attending Oredev. You’ll meet a whole heap of really interesting people and, no doubt, come away with at least an idea or two.

Kaikaku or Kaizen

I hear about two major approaches to introducing agile methods to organisations. Kaikaku (known in lean circles as radical change) is the brute force method of pushing all the change you want upon the organisation. You recognise this when basically the “normal” way of working is flipped on its head and a whole swarm of new practices are introduced.

Kaizen (known in lean circles as continuous improvement) is the softer, gentler approach to change, tweaking one bit here, and one bit there. Think of this as a way of introducing a single practice a time.

Now that we are clear about what is what, comes the interesting question of what is better?

You seem to be faced with two choices. A radical change that seems like a high chance of failure, but could also be a huge success, or smaller incremental change to do this.

In order to answer this question when I join a new team or organisation I like to consider how much their environment supports them in what they want to do. Those with supporting, nurturing or safe environments I would probably head towards Kaikaku, using education and building trust with senior stakeholders to establish longer term safety. You can increase safety and reduce the likelihood of failure if you can bring in a high proportion of the culture you’re looking for. I’ve seen this succeed really well when you have at least 50% of a team with lots of agile experience, something you tend to have when you hire someone like ThoughtWorks.

Work with less than 50% experience mixed support, and you start to decrease safety. At this point, I would start to look towards kaizen methods of improvement. Of course there are many levels at which you might apply kaizen and kaikaku, but consider safety levels when doing so.

You can’t measure everything effectively

Definitely agree with this from the 10 Things I Wish Lean Practitioners Wouldn’t Say in 2010 (via the Lean Blog):

7. “If you can’t measure it, you can’t manage it.”

I don’t believe that statement. I think this phrase should be avoided and it certainly shouldn’t be attributed to Dr. W. Edwards Deming, as it often is mistakenly. Dr. Deming never said this and he, in fact, meant quite the opposite. Some of the most important factors in a system are very difficult, even impossible, to measure. That doesn’t mean you can’t try to manage them. John Hunter, friend and fellow blogger, has the definitive take definitive blog take on this here…

Don’t get me wrong. Metrics are important but they aren’t always most important.

Consequences of Hiding Information

Last week reminded me how hard communication is to get right. Last week reminded me of how important it is to be visible with information as early as possible. Last week reminded me of what happens with the people involved don’t have access to information early.

Successful teams applying agile principles quickly involve those impacted by the situation, equipping them with as much information as early as possible. These teams call upon agile practices such as daily stand up meetings, retrospectives, and frequent showcases to achieve this. Better and earlier access to information helps all parties involved come up with more options. More options creates more opportunities to have better conversations, and more opportunities to collaborate to meet everyone’s needs, and ultimately end up with a solution that everyone is more likely to feel committed to.

Compare this to those teams who hoard information, selecting and filtering the information others hear. Filtering and transforming information limits the number of options, often adding additional stress because the team now how to come up with the perfect option. Even with contributions from others, the pool of options will often be tainted by solutions not entirely appropriate or relevant. More importantly, if the people affected by a decision aren’t involved, they will end up less committed to the solution and often, cause more problems because of resentment.

No one likes to be handed decisions. That’s why the Agile Manifesto emphasises “Individuals and Interactions”, and a key principle of Lean Thinking is “Respect for People”.

The moral? Remember to involve the appropriate people in the decision making process as early as possible. Even if you suspect there is only going to be one solution, be transparent with the information you do have in the hope you may end up with more options, or at least, the outcome is no surprise.

XTC Turns 10

I’m fortunate enough to have recently started back on a project in London* this week. One of the many things that I’ve missed working in London has been access to the variety of communities that you have access to that no other city in the world (even New York City) could ever match. One of the longest running and, and without doubt most influential, on the agile community in the UK is the eXtreme Tuesday Club who celebrated their 10th year of running weekly meet ups in London.

I always find the people there great to talk to and interestingly enough this week there were significantly many more agile coaches than I’ve seen in one place for a while. I hope to be able attend these sorts of gatherings much more frequently now that I’m back in London and would highly recommend this one to any one who happens to be in town on a Tuesday.