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 came across a great article by Masaaki Imai on Gemba Panta Rei celebrating Taiichi Ohno’s 100th Birthday which contained some of his brilliant quotes on management and thought I will re-post them:
“Let the flow manage the processes, and not let management manage the flow”.
In the lean approach, the starting point of the information flow is the final assembly process, or where the customer order is provided, and then the flow goes upstream by means a pull signal such as kanban. On the other hand, the flow of materials moves downstream from the raw material stage to the final assembly. In both cases the flow should be maintained smoothly without interruption.
Unfortunately, in a majority of companies today, the flow is disrupted and meddled with by the convenience of the shop-floor management.
“Machines do not break down; people cause them to break.”
His life-long pursuit was to make a smooth and undisturbed flow as a foundation of all good operations. He believed that wherever and whenever the flow is disrupted, there is an opportunity to do kaizen.
“The gemba and the gembutsu have the information. We must listen to them.”
Taiichi Ohno always placed respect for the worker first in his approach to kaizen. His focus was always on the customer, both external and internal.
“Just-in-time means that customer delight is directly transmitted to those who are making the product.”
Ohno was a man of deeds. Learning by doing was his motto and he did not engage in empty discussions. You pay money to buy books and go to seminars and gain new knowledge. But knowledge is knowledge, nothing more.
“Knowledge is something you buy with the money. Wisdom is something you acquire by doing it,”
But you gain the wisdom only after you have done it. The real understanding of the lean operations is gained only after you have done it. No matter how many pages you may read on lean books, you know nothing if you have not done it.
“To understand means to be able to do.”
Apple have been innovative in their great customer experience with their touch screen gesture controls in their iPhone and iPad products.
Is this video showing the ultimate form of usability (UX) – a baby using a product?
You will notice that the baby gets no response using the hand gestures from the magazine and thinks that her finger is broken….
Reading the paper on the train home from work I came across this article. Banning corporate email seems to be an extreme approach, but I do agree emails are sometimes a waste of time as its a poor form of communication. I think we have become lazy with technology and send too many emails when a face-to-face conversation or a phone call would be more effective.
According to Radicati, 294 billion (in 2010) email messages were sent per day. This means more than 2.8 million emails are sent every second and some 90 trillion emails are sent per year. Around 90% of these millions and trillions of message are spam and viruses.
So by the company, Atos removing emails from their corporate environment they avoid having people waste time or putting systems in place to manage the spam and viruses. By using instant messaging Atos employees can increase their communication effectiveness through two-way real-time interaction. Email is a broadcast mechanism and has little scope for real-time interaction. However, I can’t help to think instant messaging alone is still a poor form of communication when compared to other alternatives. It’s somewhere between email and phone conversation. I have added a few additional communication options, including instant messaging to the below chart first created by Alistair Cockburn.
Many instant messaging tools now support video (including audio) and desktop sharing – so combining instant messaging with video and desktop sharing would provide a better and more effective communication channel than instant messaging alone.
Email still has its place, especially in today’s reality when you have a global economy where teams are distributed across different countries with different languages and culture. And with this comes the reduced available timezone bandwidth that don’t allow the use of real-time communication channels.
According to the article in Digital Trends, the CEO of Atos Thierry Breton says
“It is not normal that some of our fellow employees spend hours in the evening dealing with their emails. The email is no longer the appropriate communication tool.”
“Companies must prepare for the new wave of usage and behavior. If people want to talk to me, they can come and visit me, call or send me a text message. Emails cannot replace the spoken word.”
For me, I agree with Breton and always prefer face-to-face conversation which explains why I find myself walking between office buildings in the city a lot.
Maybe some level of pragmatism is required to educate people on when and when not to use email rather than having a zero email policy.
Donald Gray has written a great and interesting article on Three Leadership Styles, based observations on managing traffic at an intersection. In the article the most successful leader is the one that sees people as “adults that most of the time they can take care of themselves, and that the role of a manager is to support these competent adults”. To be effective, the leader should not place themselves at the center of the management task so that they can be much more flexible and effective at the key management activities. A must read.
A sprint goal helps to enable the team to focus on for the next 2 weeks. What does everyone want the team to work on next?
The Scrum Guide [Oct 2011] states:
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. The Sprint Goal may be a milestone in the larger purpose of the product roadmap.
A sprint goal will be met through the implementation of the appropriate product backlog items. Working with the product owner, stakeholders, customers and users, the team identifies the product backlog items it believes it can develop during the next sprint to meet this goal. However, like many things in agile a key concept is ‘negotiation’. A reason for having the sprint goal is to give the team some leeway regarding the functionality and technology it delivers. During the iteration, the team determines daily how to meet the sprint goal. If the work turns out to be harder than expected, the team might only partially implement the functionality. At the sprint review meeting, the opportunity is given for the product owner and stakeholders to review how and what was implemented – they review how the sprint goal has been met. If they are dissatisfied, they can make decisions about the product backlog, architecture, team composition or release plan.
For short iterations (e.g. two weeks), the sprint goal may not always add a lot of value. With a two week iteration the team’s work may be sufficiently described that their goal becomes “complete the backlog items we selected.” For some teams I’ve observed a sprint goal may be useful but usually having better thought-through product backlog items works better. For these teams having release goals may make more sense than sprint goals. The teams that benefit most from sprint goals are those who have longer iterations (e.g. four weeks) or have just a few large product backlog items, as the goal provides some guidance as what we want to achieve and focus on.
Here’s an iteration goal for a team:
“Finish the agreed forms, portlets and web pages for News and Media then pick up additional stories to increase the team’s velocity”
Whilst this goal is ok, it gives no room to negotiate – it’s a very ‘command-and-control’ type statement rather than a goal to work towards. A small tweak by removing ‘agreed’ would provide some room for negotiation – “Develop the forms, portlets and web pages for News and Media site”. In addition, the second part of the iteration goal, “[…] then pick up additional stories to increase the team’s velocity” may be better suited belonging in the team’s social contract rather than in the sprint goal. ‘Doing more story points’ is an indirect result from focusing on WIP limits, pull, removing blockers, being a collaborative team and continuous improvement.
I have seen some sprint goals simply stated as “Complete x story points”. This is a useless goal as it provides no focus on what to work on other than to do achieve a number of story points (which leads to other issues such as story point inflation). So what if we have delivered ‘x story points’ if we didn’t deliver what the customer wants or delivered no business value.
So the idea behind a sprint goal is for the team’s output to be evaluated against the goal rather than the specific product backlog items they selected (there is a subtle difference). In a way it gives the team the opportunity to say “Well we didn’t finish all the backlog items but we met the goal.” Instead of having a sprint where we just ‘do more stuff’ the sprint goal can provide a theme the team can work towards. A sprint goal could be:
“This Sprint we will allow users to do a basic search, and enable the results to be filtered and the view sorted”
“No battle plan survives contact with the enemy.”
— Helmuth von Moltke
Sooner or later you will have the business asking questions like “How much is it going to cost?”, “What will I get?” and “When can I have it?”. The honest answer to this which often provokes a reaction of surprise are: “How much do you want to spend?”, “Tell us what you want” and “As long as it takes” respectively.
Technology projects are complex and high risk, and in particular there is high uncertainty especially before any actual development taking place. The Cone of Uncertainty [McConnell] describes the uncertainty in estimates of software development project cost, effort, and duration, throughout the lifecycle of a project. The degree of uncertainty is very large at the beginning of the project, which is often when decisions are made about project pricing and contracts which results in unrealistic project plans and expectations.
Agile or traditional, estimates on duration and costs are inherently very vague at the beginning of a project. For some complex projects, this uncertainty can last much later in the development process.
We are so accustomed to fixed price, time & cost projects, but in reality they are anything but. None of this information is new. However, project sponsors consistently latch on to the initial estimates project managers propose for the schedule and cost of a project at the start when the least is known and when there is the highest variability. And because project sponsors don’t understand project complexity and other factors influencing cost and schedule when requirements change and emerge, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business. Unfortunately, business executives’ lack of understanding about project management influences their perception of IT project success and failure [CIO].
There is inherent uncertainty, even in well-run projects. This is especially true in projects that involve complex software, large systems, large development effort, new application domains, new users. Furthermore, unlike manufacturing or building a house software development is a creative process and largely knowledge work which does not fit a cookie cutter model. We need to recognize that the Cone of Uncertainty implies substantial risks for traditional fixed-price and fixed-scope projects. The Cone of Uncertainty indicates we cannot predict the future accurately and that we need to restrain from traditional thinking. If you can’t predict the future, don’t plan it in detail.
A barrier to agile is the lack of the comforting predictive detailed plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way. Interestingly enough whenever we question “are those plans ever right?” the response is often negative. Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.
Agile practitioners will do an order of less magnitude less effort to come up with a plan and provide answers to the questions “How much is it going to cost?”, “What will I get?” and “When can I have it?” that are just as good and just as inaccurate as traditional approaches.
We strive to ask for exact answers when exact answers don’t exist (estimates are just an approximate judgment or calculation – it’s a guess, but we seem to forget that). Reality will come to light soon enough. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy of the estimates to show for it.
An agile project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference to traditional thinking is that agile is very explicit right from the start that this is not accurate and the team will strive to understand more as soon as we start working it. We want to get to the actual development effort where we regularly deliver high quality, working software that maximizes the business’ ROI.
There is an amazing feeling of relief when agile teams can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time. Instead of relentlessly following the pre-defined plan agile teams will adapt to the inevitably changing conditions.
Being on time, on budget and to specification means nothing when we have delivered the wrong product with low quality that has no business value.
So rather seeking the exact answers, should we be asking if we are delivering business value?
In the book Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath, the authors described the results of a study to answer the question: Would people with bigger popcorn buckets eat more at the movie cinema?
As part of the study, it was carefully engineered to serve the popcorn five days stale. Some people received medium sized buckets and others got a large bucket. The results were stunning:
People with the large buckets ate 53 percent more popcorn than people with the medium size. That’s the equivalent of 173 more calories and approximately 21 extra hand-dips into the bucket.
The book further states that other popcorn studies were always the same:
It didn’t matter if our moviegoers were in Pennsylvania, Illinois, or Iowa, and it didn’t matter what kind of movie was showing; all of our popcorn studies led to the same conclusion. People eat more when you give them a bigger container.”
No other theory explains the behavior. These people weren’t eating for pleasure. (The popcorn was so stale it squeaked!) They weren’t driven by a desire to finish their portion. (Both buckets were too big to finish.) It didn’t matter whether they were hungry or full. The equation is unyielding: Bigger container = more eating.
Recently in To Change Culture, Change the System David Joyce says:
Deming learned it’s not a problem of the people it’s a problem of the system that people work within. He found that if you want to change behaviour, then you need to change the system, and change management thinking that creates it. Doing so, culture change is then free.
To change someone’s behaviour, you’ve got to change that person’s situation.
Kaizen (改善), Japanese for “improvement”, or “change for the better” refers to philosophy or practices that focus upon continuous improvement of processes.
Teams I coach frequently ask me for “best practices”. Do not assume that “best practices” in previous projects will be equally successful in another project. In some cases, “best practices” from one context can be counter-productive in another context. Practices and processes from previous projects should be used for learning and improvement. No practice or process is both complete and optimal – once we master it at one level, we see deficiencies that were previously hidden and the cycle of improvement begins again. You should always challenge yourself to experiement and find better ways of doing things and beating your own standards for excellence –
Improvement usually means doing something that we have never done before.
— Shigeo Shingo
Mistakes are a part of being human. Mistakes are not a sign of failure. Appreciate mistakes mistakes for what they are – precious life lessons that are used for learning and for others to learn form. Part of continuous improvement is learning from mistakes. The only failure is the failure of not learning from your mistakes.
Insanity: doing the same thing over and over again and expecting different results.
— Albert Einstein
James Hird, the coach of the Essendon Football Club (a team in the Australian Football League (AFL)) took over the coaching of a team this year that was struggling to win games in recent years. A priority for Hird was improvement in the team – “We’re trying to push for continual improvement.”
The club started the season well winning several games, however, they also made many mistakes along the way and had some big losses. The club learnt many valuable lessons from those demoralising losses which enabled it to obtain an all-important victory against the best team in the competition. One of the team players said:
“The coaches were never too up when we won and they were never too down when we lost.”
“The coaches are all just about learning, evolving and improving.”
Even when the team won games and making the finals was in sight, it was still about improvement and getting better. Hird is solely focused on continuing to develop his team – “improvement first, finals second.” Through continuous improvement, Hird believes they will build a good team that can compete effectively and achieve the goal of winning a finals premiership:
“Whether or not we make the finals this year… in 18 months time we want to keep coaching and teaching so we do become a good team.”
“Our team is not built on superstars it is built on all-round effort across the board.”
In a previous post, IDEO had a fail safe culture and which allowed them to fail often in order to succeed sooner:
Enlightened trial and error succeeds over the planning of the lone genius.
It is important organizations foster continuous learning so teams constantly get better at everything they do—improving their work, making decisions, holding good meetings. That’s why successful teams emphasize continuous learning, always going over what they’ve done, identifying what went well and what didn’t, and finding ways to get better the next time around.
The following from Gemba Panta Rei highlights the importance of learning from mistakes through continuous improvemment:
Here are three important lessons from Irish novelist and playwright, winner of the Nobel Prize for Literature, and wicked wit George Bernard Shaw:
“A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.”
We often say that continuous improvement depends on the ability of people to experiment, make mistakes, reflect and learn from the mistakes. It is truly honorable when leaders create an environment in which it is safe for people to experiment, fail and learn. In fact it may take more courage to allow others to make mistakes than to make mistakes oneself. The good results of these experiments we call kaizen, and the learning that occurs from poor results we call development of human potential. When we achieve good results free of mistakes we call it competence, but mostly it is luck.
“The power of accurate observation is commonly called cynicism by those who have not got it.”
While opinions and ideologies can be had and held with only minimal effort from our armchairs, facts require that we put forth some mental and physical effort. The act of observation requires presence and attention, the accuracy thereof open-mindedness and the will to release held opinions when they conflict with observed fact. Seeing the truth can be uncomfortable. Having truth that conflicts with one’s belief can be even more so. Pointing out the misconceptions in the minds of others can result in being called cynical or worse. Accurate observation must be preceded by and paired with education, alignment and commitment to act to improve a situation, regardless of our preconceived notions in order for continuous improvement to take root.
“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”
I am an Agile Plumber – I eliminate waste, remove blockages and increase flow.
This week we had an agile workshop to establish some goals and create some epics for next quarter’s release for the agile change team at an organization I am coaching.
One of the items we covered in the workshop was to come up with a new team name for our agile change team as a result of some organization changes. Some of the names included:
- Agile Change Team (A.C.T.)
- Agile Capability Delivery Centre (AC-DC)
- The Enablers
- Centre for Agile Practices
….and there were many more.
When we went to vote on a name, a clear winner was Agile Plumbers. This name was quite humorous at first and we all got a good laugh, but the name is symbolic and there is some serious intent behind it.
An important aspect of agile and lean is about eliminating waste, removing blockages, and increasing flow which can really can change the way you build software.
There are many forms of waste including partially done work, extra processes, extra features, task switching, waiting, motion and defects. By looking at the waste that is in the steps you are doing and removing the waste you can do more with less.
We also have failure modes because we’re not paying attention to what it really takes to be agile. There are many roadblocks and blockages to getting to success. There are roadblocks that occur within teams and projects, but there are larger organizational roadblocks which are impediments to any agile approach. Agile touches on many aspects of an enterprise organization and changes many existing organizational processes that are more acquainted to waterfall. Examples include:
- Procurement, such as selecting and working with vendors.
- HR, especially what type of people we want to recruit, and changing manager’s KPIs to align more with a collaborative culture.
- Finance, how we structure the organization’s funding model to align with agile approaches and incremental delivery. Also funding may need to change to support a lean pipeline of work (continuous flow of work), rather than ‘individual projects’.
- Legal, how we write contracts that support agile teams and approaches.
- Training, creating training programs for agile (not only including agile specific topics, but also leadership and soft skills that are required in a collaborative organization).
- Governance, most traditional governance does not work with agile.
- Add your own organizational impact and blockage here that needs removing.
Finally, a goal of lean and kanban is increasing the efficient delivery of value through limiting the work in progress (WIP), making work visible and increasing the overall flow. Optimizing the entire value stream, from initial concept to consumption is fundamental to increasing flow of value through the organization. The idea is to get an idea into the development pipeline and out to the customer as fast as possible by looking at the existing processes and improving them and in the process eliminate waste and create value.
The other advantage of being called an Agile Plumber is that the name creates an memorable impression. In a large organization with many business units and organizational teams, one thing that can be difficult is being able to identify where agile help can be found.
So next time you need someone to help eliminate waste, remove blockages and increase flow, call your nearest Agile Plumber!