kevin donaldson

A set of brief segments from an McKinsey Interview with behaviorial economist Dan Ariely on the topic of irrationality in the workplace.  My favorite clip from this set is on the topic of 'When to trust your Gut'.  Basically you can trust your gut if with lots of experience AND if you can control all possible influences that might impact the outcome of the decision... his point being - experimentation is the key, and he asks a great question - why don't companies do more experimentation?  We should always be testing leaps of faith.  Organizational agility is the mindset needed to support this type of continuous experimentation.  Agile software shops understand it.  Yes, there are costs to experimentation but the early learnings more than outweigh any of the costs.

Ariely has written a couple of books on irrationality.   One that I have read is Predictably Irrational: The Hidden Forces that Shape our Decisions -  a really entertaining and worthwhile read. 

 

I recently finished a great book by Randy Komisar and John Mullins called Getting to Plan B:  Breaking through to a better business model.  I originally got turned onto this book from the Startup Lessons Learned Conference in spring of 2010.  While the book has become a must read for startups, and in fact does focus a lot on starting new business's the core aspects of the book can be used across any business that:

• is starting up a new business unit
• carries out new product development
• is developing new service offerings
• is looking at evaluating new business strategies

... so pretty much any modern business that wants to stay competitive will get some benefit from the book.  The title is a good summation of the book:  Always be looking for and testing plan B, C, D etc.  To do this the authors focus on 3 main principals:

1. Analogs:  Don't re-invent the wheel.  Analogs to your idea are successful predecessor companies that are worth mimicking in some way. Portions of others ideas which can be borrowed and/or adapted to you to help understand economics and other aspects of your idea.
2. Antilogs: Be Different.  Antilogs to your idea are predecessor companies compared to which you explicitly choose to do things differently.
3. Leaps of Faith:  Ask the right questions.  Anilogs and Antilogs help you reach conclusions about some things faster with at least some level of certainty, but there will be questions that cannot be answered by historical precedence.  Leaps of faith are the beliefs you hold about the answers to your questions despite having no real evidence that they are actually true.  Therefor you must experiment.

These leaps of faith must be tested, and measured via a dashboard.  This can essentially create the framework for a simple yet effective management framework.  The book has many great examples but I will use one of my own for this post. 

I support and have been involved since the early days with a startup non profit called Create Common Good.  Create Common Good provides training and employment to refugees and others in need through experiential programs that transform lives and enrich communities  One of our programs is a farm program where we train refugees in farming techniques but also use the proceeds from the farm to support our efforts.  One of the ideas that we have had is to create a mobile lunch truck that serves up international cuisine made by refugees based on food from their native homeland using in-season local produce produced at the farm.  In addition to some Anilogs and Antilogs found for mobile food trucks, here is a sample Leap of Faith Dashboard to describe how it can be used.  (results listed below are fictitious:)

Many companies try and create complicated sets of metrics and dashboards, but often they are just patting themselves on the back with metrics that already prove what they know to be true.  Next time try innovating and exploring some leaps of faith in your business using this simple tool to test and measure.

On this blog I talk about topics related to what I feel are the 3 imperatives to managing a modern business

• Organizational agility
• Creativity through intrinsic motivation
• Customer development

What does it mean to be a modern business?  It's a new world out there and It means you deal with the following:

• The term Global can pretty much apply to any company now
• Disruption is happening all around you
• Wicked Problems are common
• Chaotic environments are normal
• The nature of employment is changing
• Intersectional Innovation blurs industry lines traditional business models

Your organization needs to match the relative stability of the environment you operate in.  Change is nothing new.  The Greek philosopher Heraclitus of Ephesus (535 - 475 BC) said The only Constant is Change.  However what is happening to rock people's worlds is the pace of change. 

This weekend I came across this manifesto in the most recent issue of ChangeThis written by Allan Lewis, Chairman of Grand Circle Corporation, the largest U.S. direct market tour operator of international vacations for older Americans.  This manifesto summarizes Allan's learning's from being in an unstable environment.  It is titled Change is the New Constant.   It speaks to 5 key lessons learned by the organization, which map back very well to 2 of the 3 imperatives I list above (organizational agility, creativity through intrinsic motivation):

1. Flexibility trumps Efficiency

• efficiency-focused models are focused on managing predictable environments.  Over time, the relentless pursuit of efficiency will cut out the capabilities needed to respond to the unpredictable.  (see related post: Is Agile/Scrum the Process Mgmt Framework for the Creative Economy)

2. Mission and Vision creates Inspiration

• For a company to be adaptable and flexible, its associates must understand and be committed to its mission and vision. To achieve that commitment requires a compelling mission and vision; people will not commit emotionally to a mission that is only about achieving greater profit or growing sales.

3. Values, not Structures, drive effective organizations

• In uncertain environments, decisions are guided by values, not structures. If those values are not in place the wrong decisions will be made.

4. Investments in People and Learning create Advantage

• Structures and systems cannot adapt rapidly enough to unpredictable events. People can. Effective investment in people can create huge leverage and competitive advantages. In changing times investments in developing people are the most valuable.

5. Relentless measurement of Excellence is essential

• If you have a vision and mission you believe in, you must evaluate your people against them all the time, no matter how much you admire their energy or reputation, and no matter how much money they are bringing in. If you don’t, you will live to regret it.

It's worth the 20 minute read!

 

Recently I have been talking to more and more people about the power of using the Agile/Scrum framework to manage multiple business functions and it struck me that a likely reason for this is that the nature of work is changing for many people and even entire organizations.  

There is a broad shift happening away from the information/knowledge economy (which arguably started decades ago) into the next great stage often referred to as the creative economy.  In this stage, business starts to look, and act more like art.  Furthermore, a company's strength is often less about the systems and processes that it runs on, but more about the people and creative capital within.  For instance in a start-up, treating the business as art is not only required, but also a source of competitive advantage in most cases.

As many more people and organizations move away from factory work, process's become harder to define and lock down.  And when I say factory I don't mean just the traditional assembly line version of a factory that most of us think of.  Seth Godin uses a broader term in his book Linchpin where he defined a factory as:

"... an organization that has it figured out, a place where people go to do what they are told and earn a paycheck" 

This definition goes well beyond assembly lines and encompasses white collar information organizations such as insurance companies, government departments, and franchises with their systems and controls that drive continuity in their offering.

Of course, as business's mature, it is inevitable that parts of the organization will and need to become 'factory-like' -  areas where the work is repeatable and comoditized.  That's not necessarily a bad thing, however more and more things in modern business cannot be 'systematized'.  This can be scary to many people that want to work in a job with a map to tell them what to do.   It can also be a thorn in the side of traditional process engineers who love to create process maps for everything.  What some fail to consider is that if a process can be mapped, it is likely that it can be copied and therefor starts a march down the path towards comoditization.

In the creative economy process engineers and the process's they create can actually reduce operational effectiveness when they attempt to systematize everything in the organization.  Six Sigma works great when trying to create lots and lots of high quality widgets, but it doesn't work as well in value-add service offerings.  Process engineers can fine tune accounting processes but it doesn't work as well when trying to create a musical.  Traditional process engineering is valuable but not when it is used like a hammer and every aspect of a business is a considered to be a factory/nail.

Another common example for almost any company: Most large organizations have ultra detailed software development life-cycles that continue to grow and bloat over time but with all that detail its amazing how few projects finish on time with happy customers.  Why?  Because software development is Art. 

However, in the software world, people have started to figure out that lighter process can actually generate more predicable results.  Agile and its associated offspring (Scrum/XP etc) are not processes in the traditional sense, but frameworks that can both provide structure as well as freedom for the art of software development.  However,  the scrum framework can actually be used outside of the software world as a tool to help manage work in the creative economy more broadly. 

Unfortunately, some that I explain the framework to get frustrated with the lack of detailed direction, but that is exactly why it works!  It is a framework with very basic patters that support creativity, but also the need to produce maximum value for the customer in the shortest time possible. It does incorporate aspects of process engineering such as Lean, but only to provide guidance on direction.

If you find that some or all of your business is more about people creating art than running a factory, traditional process engineering may not be the answer in all cases.  Agile/Scrum could be the process management framework for the creative economy.

• Related post: Agility is an Organizational Value

 

Sports like football are great to use when discussing concepts related to organizational agility and startup culture.  They work well because there is a mix of competition, pain and exhilaration in the sport, which is very similar to what you get in a startup environment.  Interestingly, this can be a useful way to help recruit and/or determine the types of people that you want on your team.  The analogy can help prospects understand what they are signing up for, and help weed out candidates that are not interested in getting in the game.  Some people like the idea of being agile and part of a startup culture, but can they play on the field or are they really just an armchair athlete?

Once you have your team – how can you make your players most effective?   While the football analogy works, I think the sport of rugby might be a superior analogy in many respects.  Both games have similar objectives around moving the ball down the field but with some key differences.  Here are a few examples:

Pads and Helmets:  Unlike American football there are no pads or helmets in rugby.  Having extra safety gear can create the impression of indestructibility.  Just put your head down and go.  Without pads and helmets for protection it might drive a different type of behavior – is there a smoother, more elegant way for us to move the ball forward?

Defined Plays - the good:  Executing a defined play can be a good analogy for an agile culture if used in the right context.  For example in most Agile software shops, teams will ‘huddle’ each morning to set out a plan for the day and then resets again the next day based on the results of the previous days play.  Frequent resets and huddles on all aspects of business are important.  However the longer the duration between huddles the more this analogy starts to breaks down. (see post on organizational rhythms)

Defined Plays – the bad:  At a macro/business level I find that 'defined plays' can actually decrease agility.  Plays in football are executed as planned.  If anything goes wrong, play execution fails most of the time.  It typically results in zero movement forward or sometimes a loss of yards.  On the other hand, Rugby is more about continuous sustained play with real time adjustments.  The team is not told what play to execute, nor do they have the benefit of a stoppage in play to huddle up and discuss.  The rules of rugby create a style of play that can appear very chaotic from the outside. (Remind you of your business environment?)  However, team members practice around a basic framework or set of patterns, and when on the field – the team self organizes, and adjusts real time as the environment changes. 

The Speed of Play: Think about American football.  4 quarter hour segments of play time.   Then think about game duration in terms of actual play time.  There is a lot of time where there is no actual ball movement.  Now think about Ruby.  The style of play is much faster – there is a lot more opportunity for real time ‘practice’ – fail, retry, fail, retry.  It happens so fast in the game play that you hardly have time to consider or even think about it as a failed play.  Its just a natural part of the game progression.  This coupled with real time learning on the field creates a very well practiced, fail fast and adapt, agile team operating under minimal constraints.     

One last thought:  The idea of moving the ball down the field in small short plays is a good one, and definitely a potential strategy to get the ball across the line.... as long as the team you are playing against is using the same rules.   Now think about your business environment.  To me, it is much more like rugby with very few rules about how the different teams move the ball.  If your team plays well under the rules of American football what happens when you are put in an environment with the same objective (moving the ball down the field to the end zone) but remove the constraints on how movement takes place and play doesn’t stop?  Think like a rugby team!

Over the Labor Day weekend I was able to sneak away and do a fun climb on the 4th highest peak in Idaho. – Diamond Peak (12,197).  The weather couldn’t have been better, allowing us to bang out the 4200 ft of gain over a steep 2.5 miles in 4 hours with another 3 hours on the decent.  In addition to some pictures from the trip, I came up with 5 lessons from mountain scrambling that will help you become a more Agile Organization. 

1. Your approach needs to be sustainable and enjoyable: Make sure you select a target and approach/route that will be enjoyable and sustainable to the team.  Selecting a climb that is too difficult for one of the party can be dangerous or minimally they will not want to do it again.  The same can be true for teams who jump full force into an Agile approach.  Not knowing how to set a sustainable pace with too much complexity can put a bad taste in a team member’s mouth possibly making them not want to do it again.
2. Continuous conditioning:  Assuming #1 is true, conditioning is the next biggest factor.  When you are tired, your vigilance drops – maybe you don’t drink or eat as often as you should, you get sloppy and you make mistakes. In the mountains small mistakes can be costly.   To be an agile organization, agile conditioning is required.  Learning to be comfortable making decisions at the last possible moment but not too late, being comfortable with changing environments, comfort with simple frameworks over complex detailed process's to name a few.
3. Simple Management Frameworks:  This weekend was a class 3 scramble in September.  We went with no ropes, or gear outside of a helmet for safety.  Our next project may be different requiring some different tools added into the system.  Knowing what you are trying to do will help you adjust your ‘management system’ before the start and during the climb.
4. Iterative Feedback and Planning:  During the act of climbing you are watching and interacting - Asking your partner how they are feeling, are they comfortable with the steepness, etc.  Once every 60-70 minutes I stop to assess rate of progress, hydration and energy levels of both myself and others in the party.  At the end of the climb, I do a retrospective – what was my level of enjoyment, did I bring the right gear/clothing based on weather and/or technical complexity, was it a good match to my/our technical abilities. 

5. Make sure everyone has the same goal:  My goal is always to return safely to my car.  It is not to reach the summit – that is only half way.  Goal alignment helps speed decision making, when required.  Knowing what weather conditions are acceptable, and what is not....Having an agreed upon turn around point...Knowing why you are here.

 

 

The concepts of Lean grew out of manufacturing specifically by Toyota.  They have since been adopted in services and further adopted into many business verticals and applications.  In 2003 Tom and Mary Poppendieck applied Lean tenants to software.   If you are new to lean all these different variations can actually be confusing and make it seem more complex that it really is.  Having worked with a number of these models I tend to use the Poppendieck model and apply it generally as 7 lean thinking principals for companies looking to become agile organizations.  These 7 principals with the software aspects extracted, coupled with a good understanding of Agile principals can put your company in the right mental framework to begin the journey to organizational agility.

Principal #1: Eliminate Waste

There are 7+1 types of waste you should be on the lookout for.

1. Overproduction: Producing more than you need, creating things the customer doesn’t want
2. Excess Process/handoffs: excess process steps, time etc
3. Inventory/WIP : Physical inventory, excessive requirements documents
4. Motion: Physical movement of product, searching for information
5. Defects: broken products, software bugs, missed SLA’s - anything related to the quality of service
6. Over processing/Excess quality: Gold-plating, giving the customer more than they want
7. Waiting: customer waits, team waiting, waiting on 3rd parties etc
8. Intellect: This was a later addition to the model.  For modern organizations, this is likely to be the most costly form of waste and is also highly dependent on the other 7.  This is wasted skills, mental capacity etc of your people.

Principal #2: Amplify Learning

How do you amplify learning?  Use shorter work cycles with rapid feedback loops with as few filters as possible to the end customer of the hypothesis/test.    Most important – take time to actually learn from your execution.  All too often people execute and move on to the next thing without doing a review/retrospective on the results so that smart adjustments can be made.

Principal #3: Decide as Late as Possible

In uncertain environments better results can be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions.   An iterative approach with short cycles promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after release.  As mathematician Jon Von Neumann said: “There is no sense in being precise, when you don’t even know what you are talking about”.

Principal #4: Deliver as fast as Possible

The sooner a workable end product or service can be delivered without considerable defect; the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfillment of a customer's present needs and not what they required yesterday. This also gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product.

Principal #5: Empower the team

A pillar of lean is: develop people.  Agile says – find motivated people and trust them.  However, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. They need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments.  A key success factor is having a framework that allows the team to be successful.

Principal #6: Build integrity in

There are two types of integrity:

• External (perceived) Integrity: totality of the product/service achieves a balance of function, usability, reliability, and economy that delights customers
• Internal (conceptual) Integrity: the product/service components work together as a smooth cohesive whole

The key to this is to have excellent information flows from customer to the people building the product/service as well as upstream and downstream processes.

Principal #7: See the whole

Products and services are not just the sum of their parts.  See the Whole, does not imply that you need to/should ignore details but more importantly be aware of temptations to optimize parts at the expense of the whole.  Make sure you are measuring success at the right level to ensure ‘seeing the whole’.  Here is a related blog post I wrote on this topic.

Continuing on my recent theme of focus:  If you are in the business of software take an upcoming lunch break and watch this 50 min presentation by Geoffrey Moore from the The Business of Software Conference.  Even if you are not in software this presentation will still be valuable to anyone focused on organizational agility.  One great comment I took away:

Nimbleness and agility is often your highest competitive advantage.  Wasting this on anything that is non core is very expensive to you as a company.

 

Agile has definitely reached buzzword status.   Have you heard any of the following?

• 'Agile is one of our initiatives for this year’
• ‘We plan to implement Agile next quarter’
• ‘Agile is in the budget for this year’
• ‘Yeah – we started Agile’

A large number of companies going in with this mentality will fail, and come out saying things like ‘Agile just doesn’t work in our organization’.  Here’s the thing: Agility is about people.  It’s a way of thinking; it’s a way of being and acting.  It’s not a process. It’s not something you buy and implement.  You would not say ‘we are going to implement company culture this year’, and organizational agility falls in the same camp.   Agility is an organizational value and philosophy guided by patterns and frameworks.

A lot of this misunderstanding stems from Agile software development.  Even within the software community there is confusion.  For instance, Agile is not a development methodology – it’s a set of guiding principles.  Even the methods that fall under the Agile umbrella such as Scrum can best be described as frameworks to help guide and implement Agile principals.

That being said, Agile software development should also be celebrated.  Software development is a realm of extreme uncertainty, which has allowed agile techniques to evolve at much faster rates than other aspects of business.   Now that extreme uncertainty has spread well beyond software and we can take advantage of these advances and adopt them more broadly to support organizational agility.  To use a software analogy on agility: Agile needs to be part of the organizational operating system – not a program that run within it.

In business, agility is most often described as  “the capability of rapidly and efficiently adapting to changes”, but this definition has a very mechanistic feel to me.  When I think about true agility I think about a Cheetah for instance.  With that frame of reference, I define organizational agility as the capability to react with speed, strength and grace.    This makes agility less machine-like and more focused on its true core – people. 

Over the past couple of days we have had Jeff Sutherland in helping us work through some of our scrum impediments and he brought up an interesting, yet simple measurement tool that I would like to expand upon here that can be useful for any organization using agile techniques for business management.

Think of it as a simple balanced scorecard for agile teams.  To create the score, you can use a combination of quantitative hard measures as well as qualitative metrics such as surveying your team.  Doing this, say on a monthly basis can give you a gut sense on where things are going well and where the team can improve.   It can be a valuable part of the retrospective process.  This can create discussions that can lead to the identification of team impediments and hence towards ways in which process’s can be adjusted and improved.

The base model consists of 4 components: Velocity, Direction, Sustainability and Quality.  I have added a fifth dimension of User/Customer Experience. 

The first 3 vectors have an internal focus:

• Velocity:  This is the rate of throughput for the agile team typically measured in points or some other measure of output.
• Direction: This relates to how well the backlog is managed, how well thought out the strategy is, and how the team manages instability (changing markets, customer needs, competitive pressures etc)
• Sustainability:  In an agile organization the goal is to increase velocity and maintain a sustainable pace.  Sustainability can relate to hours, mental overload etc.  (see related post on the creativity inflection point)

The last 2 have an external focus:

• Quality:  This relates to the quality of the product or service being produced by the team.  It can be measured by factors such as defects, service calls, process time etc.  Arguably anything that falls into the lean definition of ‘waste’ could fit into this category.
• User Experience:   Some may argue that quality vector includes user experience but I feel that they are best thought of as different dimensions.  Some metrics such as customer satisfaction (eg Net promoter score) will be influenced by both but they are not always correlated.  You can have a very high quality product that produces a very poor customer experience.  Having a specific gauge on user experience creates a better balance.

Measuring this over time can give you good view into where things are at, what is getting better and what is getting worse.  It can also help you measure against organization priorities.  For instance, the team may actually need to sacrifice some velocity to increase on the vector of user experience for some period of time. 

What do you think?