Innovation through customer collaboration and feedback

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.

Enlightened trial and error succeeds over the planning of the lone genius

“Enlightened trial and error succeeds over the planning of the lone genius”

is a quote from a great video demonstrating how teamwork and agile concepts at IDEO is used to successfully deliver innovation and solutions in a non-IT environment in just 5 days!

Some highlights which I thought were pertinent to agile:

• The people are not experts at any given area.  They innovate by using and applying the process.
• The person leading the team is the leader because he is good with groups, not because of seniority.
• There are no titles, no permanent (role) assignments – everyone is a generalist but brings specific skills.
• Everyone communicates and share what they learn.
• Iterative development with showcases/demonstrations of prototypes to get feedback for the next iteration of the product.
• Some of IDEO’s mantra for innovation:
• One conversation at a time
• Stay focused on topic
• Encourage wild ideas
• Defer judgment
• Build on the ideas of others
• No criticisms (this is self moderated)
• Time-boxing, to prevent the process from going on for ever (Parkinson’s Law and Pareto Principle comes to mind).
• Self-organization.
• Team judges what are the best ideas (team votes).
• Fail often in order to succeed sooner (fail safe culture).
• Having an open mind – think outside the box.
• Belief that focused chaos can be constructive.
• High use of visualization tools, story boards, information radiators.
• Fresh ideas come faster in a fun place.
• High level of collaboration.
• Teamwork, teamwork, and more teamwork!

Bridging Business and I.T. through Communication and Collaboration

How many times have you heard, “that’s what I said, but not what I meant or wanted”?  Too many times I would suspect.  Many symptoms of project issues are related to organizational, collaboration, and communication issues, not technology.  One of the challenges of any I.T. initiative is getting people to communicate and collaborate together, especially between business and I.T.

Communication

Wikipedia defines it as:

Communication is the activity of conveying meaningful information. […] Communication requires that the communicating parties share an area of communicative commonality. The communication process is complete once the receiver has understood the sender.

The last sentence above is quite important and often overlooked.  We rely too often on using static channels of communication, such as sending an email or word document to communicate a message.  However, the receiver of the message may not have understood what your intention is and we often ask ourselves “why people don’t understand it? I sent them the email with the requirements!”.

The sixth Agile Manifesto principle reminds us:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Getting people together face-to-face provides richness in our communication through, tone of voice, eye contact, visual gestures and the ability to convey tacit knowledge.

Collaboration

Collaboration is working together to achieve a goal.  Agile And again, we can look to the Agile Manifesto for some guidance:

Customer collaboration over contract negotiation

Business people and developers must work together daily throughout the project

The best architectures, requirements, and designs emerge from self-organizing teams

During a team discussion, I liked what a fellow colleague said on what collaboration meant:

Collaboration means acknowledging that you don’t have all the answers and that the collective wisdom is better used to solve problems.  Collaboration is being vulnerable and being transparent so the conversation brings out things that were otherwise not consciously known.

My communication and collaboration experience

Over the last several weeks I have been coaching and facilitating several inception/discovery workshops that included both business and I.T.  One particular workshop was attended by 35 people from all levels of the organization with some participants traveling from interstate.  The goal of the 3 day workshop was to discuss and plan how we would tackle a large program of work by identifying the program vision, goals, drivers, measures and the various streams of work that would make up the program.

In the 3 days we accomplished what previously would have taken weeks (possibly months) to complete.  The face-to-face workshops provided a rapid, efficient and effective way to for people to communicate and collaborate.  An important outcome was obtaining a shared vision amongst all participants.  After the 3 days everyone walked away with a shared understanding and vision that they can take into the various projects that would make up the program of work.

What I also observed was the large amount of informal communication and collaboration that occurred outside the workshop hours such as during breaks and lunch that otherwise would not have occurred.  Getting everyone together allowed whole team discussions which I believed lead to greater buy-in by all team members.

There was a high level of collaboration between everyone in clarifying business requirements, the problem space and each others understanding.  The power of bringing people together to communicate and collaborate to achieve a goal was powerful.  Trust was being built between business and I.T..  The business was able to understand the complexities and risk involved in I.T. development.  And the level of negotiation between the parties allowed mutual decisions to be made and the quality of the decision making was made possible by having the right people together.

Agile stresses the importance on communication and collaboration.   Alistair Cockburn recently remarked how important it is to increase collaboration between people and across the enterprise.  Effective communicators realize that the goal is to share information, and that the information sharing is typically a two-way street.  Through conversation we can iterate over meaning and seek clarification.  The ability to answer questions in real time is important because questions provide insight into how well the information is being understood by the listener.  Face to face collaboration also reduces the cycle time of information sharing through continuous flow of tacit knowledge.

Agile is about bringing people together to achieve more than they could individually.  It is only if we have consensus through group collaboration that we can provide optimal solutions to address business problems.  So next time you want to bridge the business and I.T. gap consider increasing the amount of real-time communication and collaboration between the two parties:

• Get all the players in the one place and talk.
• Engage the right players to make decisions.
• Leverage the knowledge of the team – listen as much as you talk, ask questions when you don’t understand, question if you do not agree.  There is no silly question!
• Clarify and iterate over meaning to get a common understanding:
• “So what you’re saying is…”
• “Let’s use an example…”
• “Doesn’t that imply…”
• Find the value that each member adds to the group.
• Think ‘one team’.   We stand or fall together.  Collaboration expands our potential to succeed.
• Negotiate to reach an understanding, resolve a point of difference, or to produce an agreement upon courses of action.
• Document and capture important information so it is best not forgotten (don’t document just for prosperity sake) – it is the dialogue that is important.

Software development is a creative process and any creative endeavor requiring teams collaborating together to share knowledge, learning, ideas, solve problems and build consensus.   Communicating and collaborating will always help you steer your way to a far more successful outcome.

Bridging IT and business

We sometimes hear that business is not getting value out of IT.  Technology and tools are constantly improving but we often have missed expectations.  The need to align business and IT is getting more important.

Incorrect assumptions of what the client needs often leads to incorrect actions resulting in wasted effort.

Next time you  speak to your customer, clarify what they mean and speak in their language.  Get the customer to provide real life examples and elicit feedback along the way.  That way you will move towards aligning IT with the business and deliver greater value.

Traditional Project Management Role on a Scrum Project

A “good read” article on Agile Journal, An Agile PM Isn’t What You Think Sub-Head: Where Does Traditional Project Management Fit in an Agile Project Using Scrum

There is always considerable discussion about the role of the Traditional Project Manager on an Agile Scrum Project and this article describes it very well.

In the end, Scrum does not prescribe where the individual currently serving as project manager should go in a Scrum project, only with whom the project management responsibilities lie and, as such, organizations should not assume that project managers always belong in a particular Scrum role.

[Edit 16 Nov 2009]

In another article 10 things a PM needs to know about Agile, the authors go as far as stating

There is no PM role in Agile

Whilst there is no single person performing the role of a PM, the elements and responsibilities of the traditional PM are performed by all the people on an Agile team.

I thought the following statement is quite true

“but who is going to chase them up if they don’t get their work done on time!?” In reality, this is more a fear than a real risk.

Ultimately, organisations and management need to trust individuals and teams to do their work – that’s why they hired them in the first place.

Customers Should Be Part Of The Team

Source: Dilbert 21-Sep-2009

Dilbert cartoons are great because they poke humour in everyday working situations, and they wouldn’t be funny if they weren’t true.  Too many times have I seen project teams in the situation above, including ones I have worked on.

Customers should be made part of the team.  A goal in Agile is to have the customer collaborate with the team and a key role is the Product Owner.  Together the team and customer work out what is needed in the user story (requirement), what is required to start the user story and what are the acceptance criteria to pass.

Communication between the customer and team occurs throughout the project and feedback is provided by the customer to the team often.  By having the customer part of the team it helps the team maintain a state of productivity by remaining available to answer questions and further clarify acceptance criteria.  Because the team and the customer work together to discuss the user story, there are no misunderstandings and situations in the above cartoon should rarely occur.