Nordstrom is one of USA’s leading fashion specialty retailers and is a Fortune 500 company (2011 – ranked 254). When I think of a fashion retail company, innovation isn’t the first thing that comes to mind. So how does a large retail company like Nordstrom innovate? Through the creation of a Lean Startup team, called Innovation Labs. According to their website,
The Nordstrom Innovation Lab is a new, and growing, team. We act like a startup inside of a large company: we move through ideas quickly, using whichever technologies make sense. We also walk the agile walk: the lab is a collaborative workspace with stickies and note cards everywhere, and we follow agile engineering practices like pairing and test-driven development. On the customer-facing side, we use ideas from both lean manufacturing and lean startup, and test our experiments with customers using human-centered design strategies and tactics.
The below video is a brilliant case study on how the innovation lab uses Lean UX and human centered design to build an iPad application (to help customers select a sunglass) incrementally and getting customer feedback in real-time as they work, so they were never working on anything that wasn’t valued by the customer. They were only doing things that was delivering value.
The innovation lab manager, JB Brown states:
Somebody will have an idea and we will find a way to prove that the idea will work.
We really don’t know what the features are yet. We are going to use customer feedback as we go along in order to build the best thing. Building a feature and testing it until we get to the point where we have something that is good enough.
Building the iPad application isn’t complex and the cycle time to develop a feature wouldn’t take long. But what the innovation labs team has done is cut down the feedback loop times. If this application was built in an office away from the customer, getting feedback would have been much longer. And by getting feedback directly from the end users rather than a user proxy, they have reduced the risk of developing the wrong features.
The innovation lab uses a concept called ‘flash build’, a variation of a flash mob, where a software team shows up at a surprise location to build a minimal viable product application so they can get direct customer feedback in real-time.
It is awesome to see innovation and the use of lean and agile principles and practices in action within a large company.
I first knew David Joyce, a Systems Thinker and Agile practitioner, through the local Limited WIP Society user group in Melbourne and in more recent times I have had an opportunity to know and work with him. David is one of those people who has a knack of explaining something that you can readily understand and comprehend.
David along with Peter Middleton have just published an IEEE paper, Lean Software Management: BBC Worldwide Case Study that contains anecdotal evidence over a 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.
These are impressive and enviable results.
David’s paper shows how the use of lean methods and thinking including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
Quote from David Joyce’s website –
I believe it will be one of the most significant papers in Software Engineering this decade.
– David Anderson
Great stuff David J !!!
I came across a case study on Facebook and how two key factors that contributed to Facebook’s success: people – in particular Mark Zuckerberg himself – and process – ‘moving fast’.
Facebook has a culture of speed and values moving fast above anything else – fast releases and fast learning through fast feedback. Everyone is responsible for quality. There are mandatory code reviews and there is an emphasis on coding conventions. There are automated tests at all levels of the stack, integrated with continuous integration systems and other tools.
There is a firm belief at Facebook that nothing should stand in the way of an engineer who wants to release a change or a new feature to production. There is no separate QA team. Engineers are responsible for the quality of their work. Changes are released daily, often multiple times a day. New features are released on a weekly basis.
Facebook doesn’t publicize that they have a process, however, Facebook’s culture of speed seem to have it’s roots in Lean, Scrum and XP. Though not explicitly stated in the article, I get the impression that concepts from Kanban are used. They have small batch sizes and measure cycle time to enable fast flexible flow from idea to development and then to release into production. Many of the ideas come from Hackathons. Facebook has a focus on human interactions, close collaboration and low ceremony to enable fast releases of working software. High communication bandwidth between the team members and product managers is important. Co-location of the team in the early days was critical from the Harvard dorm rooms to the houses they rented in Ralo Alto.
Agile software development embraces decentralized control and the benefits this brings, in particular with respect to moving fast. It should come at no surprise that Facebook is basically an agile shop, even if you won’t hear much about “Scrum at Facebook” or “XP at Facebook.” They work in small, interdisciplinary teams, and they deliver high-quality software early and often.
To ensure everyone is on the same page and not wasting effort working on the wrong thing, there is a common and shared vision at Facebook which enables the entire company to move in the same direction. Getting a shared vision is a challenge in many large enterprises – most people don’t even know what the vision is let alone share it. Facebook seems to have this nailed:
Mark Zuckerberg’s vision is deeply shared and understood not just by the management team, but by every single Facebook employee.
Reading the case study, I get the feeling that there is a tolerance of failure and mistakes. If Facebook fails, it learns, regroups, adapts, and develops some more – fail fast but recover quickly.
Albeit a several pages long, I encourage you to read the entire Facebook case study – it makes for an interesting read (even for not I.T. folks).
Be sure you read the comments by Don Reinertsen, Alistair Cockburn, Jeff Sutherland, Yishan Wong (former Director of Engineering at Facebook) towards the end of the article.
The Harvard Business Review has published an article on How Pixar Fosters Collective Creativity in making their movies. The link is only a summary to the full article (which is paid), but it does provide some insights on how Pixar approach their film making.
Building complex software systems is very different to making a blockbuster film, but one thing in common is the people behind it. The way Pixar approach their film making is very similar to Agile practices.
Pixar have cross functional teams – Pixar assembles cross-company teams and find people who’ll work effectively together.
Pixar incrementally build out the movie – Though it is incomplete, Pixar demonstrate the animation work daily to enable the team to communicate important points to the entire crew at once and get candid feedback.
Pixar has self-organising teams – They help the teams to solve issues and the teams are trusted to solve complex problems themselves. People are encourged to help each other produce their best work. Managers are not afraid to hear bad news and they do not micro-manage the team. It is interesting to note that the managers are
okay to walk into a meeting and be surprised.
Pixar is constantly learning and improving they way they work through retrospectives (they called it post-mortems).
Pixar asks post-mortem participants to list the top five things they’d do again and the top five things they wouldn’t do.
This way they can extract the most valuable lessons and constantly inspect and adapt the way they work.
Can you produce a blockbuster software system?