We decided to invite Collin (our agile coach) to our UX Weekly London event recently to get his thoughts on some of the areas we’re grappling with on our journey to become a more Lean and Agile studio. There were lots of questions asked and we've included some of the best below - obviously with Collin's responses.
1. Why is Lean the best way of working?
Elg (Visual Designer)
Before I answer that question, let’s get on the same page about what we mean by Lean. Lean (and Agile) software development takes inspiration from Toyota who developed the Toyota Production System (TPS). This was later referred to as Lean Manufacturing when other manufacturers wanted to bring that way of thinking and ways of working into their companies. Fundamentally TPS is a set of principles approximated as “Eliminate Waste”, “Build Quality In”, “Deliver Fast”, etc. Software development practitioners in the late 90s were looking for alternative paradigms for software development. At the time the construction paradigm was prevalent and these thought leaders were looking for inspiration to address the terrible track record of software delivery. Software was regularly way over budget, delivered late and often didn’t meet the user’s needs. Lean seemed promising. In 2001 several of these thought leaders gathered in Snowbird, Utah to share ideas and at that time coined the term “Agile”. “Lean Software Development” was later popularised by Mary and Tom Poppendieck making a more direct relationship between the Lean manufacturing principles and Lean software development.
Okay, so now that we have a little background on what Lean is, you’ll notice that it’s much more about principles than it is about practices. This is the trap that many teams new to Agile and Lean fall into. They focus on the practices when the real place to look is the principles. So if you agree that the principles are worthwhile (and I’d say they’re hard to argue against -- who doesn’t want to “eliminate waste”?), then it’s a matter of thinking about how to apply those principles in your specific context. So I’d say that Lean is a good way to work, and it’s the application of it that will determine if it’s the best way or not.
2. When is Lean not the best way of working?
Carl (Strategist)
So I think what you’re really asking me is “When is Lean not applicable?” To be honest I think the principles are applicable in a variety of environments, but when I think about life and death type products, you might not want to iterate in quite the spirit of learning that Lean advocates! That said, I’m sure there are regulated environments that struggle with taking on Lean and Agile ways of working. But I’ve seen these barriers come down as people in these environments recognise that the old way isn’t working.
3. Since Agile comes from development, where does “design” fit in?
Philip (Visual Designer)
This is an excellent question. As I’ve said, Agile is derived from principles that were developed in a manufacturing context, so interestingly enough, these ideas are applicable in software (a very malleable process of discovery) as well as manufacturing (a very deterministic repeatable process). So clearly it’s not about it coming from development as such. In my experience, as Agile has been introduced into new areas, there’s more often than not this initial reaction: “This sounds like such a good idea, too bad we can’t apply it to what we do.” I’ve seen it with business analysis, infrastructure, data warehousing, etc. In fact, many software developers (although less and less) think it can’t be done in their area. Design is the latest frontier to buy into the principles but struggles with how to do it. Jeff Gothelf has given the design industry a great leap forward in his book Lean UX. In short, design is another one of the disciplines required to deliver great products. All disciplines have to work together -- to deeply collaborate, as I like to say -- to create great products. And as more people who embrace the objectives of Lean and Agile experiment with ideas, the more our industry will develop ways and means to do it. And as more companies that we admire pave the road, the easier it will be become. The question is are we going to be leaders or followers?
4. How do you change the culture at the top?
Stuart (Interaction Designer)
You’ve correctly noted that Lean/Agile adoption is a cultural change. And we know that culture is set by an organisation’s leaders. I’ve had experience working with large organisations where the leaders say they buy into the ideas of Agile and Lean but refuse to see that its not just for “the people doing the work.” The change of organisation’s culture has to come from the top if it’s to have any hope of being a sustained change. But getting time with top-level people can be difficult. The sad truth is that it’s easier to get the ear of someone at the top if they’ve paid heaps of money to an outsider to advise them. There are several big names in the Agile consulting world who have published books and are able to command very large fees, and in so doing, able to get the ear of the CxOs.
5. How does taking away your job title lead to delivering value quickly - and do you believe in it?
Jack (Visual Designer)
This is a very interesting question that I know we are grappling with at ustwo. I haven’t been part of those discussions, but I think I know the problem we’re trying to solve. One of the cornerstones of Lean/Agile ways of working is collaboration. Some people believe that job titles create silos and hierarchy that pull against collaboration. I think that’s the problem we’re trying to solve. Some people feel very attached to their job titles and some see it as an indication of how they’re progressing in their career (junior designer, senior designer, lead designer, etc.). I’m not sure what my opinion is of doing away with job titles -- I haven’t given it enough thought -- but I respect the problem we’re trying to solve. I think we just need to be sensitive to and consider how to address the other problems that may surface in doing so.
6. Delivering Value - Please explain it? Why is it better to deliver faster?
Ayesha (Interaction Designer)
When we talk about delivering Value, we’re talking about value to the end customer/user. This is something that many people struggle with and I think it comes down to the word “value”. Some people find it difficult to separate the word “value” (something I’d pay for as a customer) from “valuable” (something important and worth doing). I agree the distinction is subtle, but if you’re customer-focused, you’re wanting to pay close attention to creating things that are seen as valuable from your customer’s perspective. That doesn’t mean we don’t do the other necessary and important activities that required to deliver that value, but we recognise that the lighter-weight approach to those things will get us to delivering something the customer will see as valuable, faster. Why is it better to be faster? Well, if you buy into the economics and commerce of our capitalistic society, a pound today is worth more than a pound tomorrow. The sooner we can earn a pound the better. But there is perhaps an even better reason...learning. The faster we get value “out there”, the faster we learn. We learn about our ability to actually do it. We learn about how desirable our “value” is to the market. And we learn, where appropriate, if people will pull hard earned cash out of their pockets and pay for it.
7. What’s the role of documentation? How is learning transferred between teams.
Harsha (Interaction Designer)
I think this question stems from the Agile Manifesto. It includes a line that says “Working software over comprehensive documentation.” People often misinterpret that as meaning that we don’t have to create documentation if we’re working in an Agile way. But that’s not what was intended. It’s intended to address the documentation-heavy approaches that have come before. It wasn’t unusual to create heaps of documentation before any software was written. In fact, in many cases (that I’ve witnessed myself), after years of work, the project got cancelled and all they had to show for the work was piles of documentation. On an Agile project, the idea is to create whatever documentation is needed. This need will differ from context to context. In a regulated environment the documentation and traceability needs might be more than for other less constrained environments. Neither is right or wrong. The key is to work out what is actually needed and produce barely sufficient documentation. In other words, don’t create documents for documents’ sake. Create them because there is someone who will use them. In the case of your question, that could mean enough documentation so that another team could pick up what they need to understand about the software. But above all, where possible, use techniques and tools that allow the documentation to remain current as the system develops. Some form of test automation can be very helpful here.
I want to thank everyone for coming and asking great questions. It’s refreshing to be addressing questions more from a principles and mindset perspective than specific practices. It’s all about mindset. Practices will come and go, but the principles are here to stay.