Thursday, December 10, 2009

Relearning to Count - Zero, One, Many

I have been thinking about the methods we use to count with.  What method of counting is most appropriate to the task at hand (pardon the pun).  A smart friend of mine told me that developers need to relearn to count.  As a software developer the appropriate method of counting is, zero, one, many.
Little 1 by Ann & Paul Rand

The first time we learn to count we use our fingers in the simplest technique.  Some time early in childhood we learn to show fingers for our age, "I'm this many (shows two fingers)".  Then we actually learn to count, 1, 2, 3.  Later taking it up to 10.  So a base-10 number system seems like a natural human number system.  But is this true?

I've been wondering why we used a sexagesimal number system (base-60) for time.  A hour has 60
minutes and 60 seconds in the minute.  Why use this system when it would appear a base-10 system would have been more natural?

Babylonian sexagesimal symbol set
These two facts perplexed me.  We learn to count in base-10, yet our fundamental unit of measure is base-60.  Reading about the Babylonian number system may lead to a plausible explanation.  We adopted the Babylonian system for time.  And perhaps the Babylonian children learned a different method of counting, not counting fingers - but instead counting finger joints.  If one counts all the finger joints on the fingers one can count to 12 just using the four fingers.  That is much more efficient.  So using the left hand to count in base-12 and the right hand to count the multiples of 12 one arrives at a combined base-60 system of counting.  A bit more complex than counting to 10 on the fingers.  But the Babylonian's were not children.

Compare the simplicity of a base-60 system to a base-10 system when one is in a shop counting baskets of grain.  There is a high chance that there will be more than 10 baskets, but lower chance that there will be over 60 baskets before someone wants to start marking on clay tablets.  Perhaps the shop keepers relearned to count in base-60 because it afforded fewer trips to the clay tablet.

For non-developers you may continue to think in base-10. As a software developer you need a slightly more abstract system.  That system is Zero, One, Many.  Simple.  All you need.  Zero is used to mean the empty set, nothingness, the absence of quantity.  Zero has an interesting history.  One is used to mean the unique thing, unity, not Zero and not Many.  Many is used to mean a collection of like things.  Modern programming languages have allowed this abstraction level with many types of objects to represent Many.  We have Collections frameworks all designed to represent a specific constraints on Many, but the abstract concept is still Many.

Is there an anatomical representation of this system (Zero, One, Many)?  How about the closed fist for Zero, the raised index finger for One, and the open palm held horizontally ready to hold the collection for Many.

See Also:
The History of Zero:  How Ancient Mesopotamia Invented the Mathematical Concept of Nought and Ancient India Gave It Symbolic Form
Linguistics of Numerals - guess what a duodecimal system uses as it's base?

Wednesday, December 9, 2009

(NOT) Reliable and Valid Research - Fox News

Fox News quotes poll to show that perhaps scientist falsified research to support global warming.

Rasmussen Poll:  Did scientists falsify research to support their own theories on Global Warming?
59% Somewhat likely
35% Very likely
26% Not very likely
120% total people responding

Well that is a poll that you can take to the bank.

Perfection and constant change

"To improve is to change; to be perfect is to change often."
      - Winston Churchill 

Monday, December 7, 2009

The Universe - by the numbers

The Universe appears to be quite old but for some reason the really interesting things happened at either end of the arrow of time.  Being a fan of This Is Indexed I though I would try one myself - nope not funny.
Everything interesting happens at the ends of time.

      Age (years)
13,700,000,000     Universe
 4,600,000,000      Solar system
 4,570,000,000      Sun
 4,540,000,000      Earth

   530,000,000      The Cambrian explosion

       2,500,000      Stone Age (begins)
           15,000       Domestication of dog, cow, pig, etc.
           10,000       Argicultural revelotion
             5,300       Bronze Age (begins)

                230       Industrial Revolution (begins)

                 47       me

Sunday, December 6, 2009

ToDo or Not ToDo - that is the question.

What does a TODO tag in your code say about you as a developer?

When is a TODO not appropriate - is it every appropriate to postpone work that you recognize, but just don't want to deal with now?  Is procrastination a trait that we encourage or discourage?

I posit that quality code has very few if any TODO tags.  That there is a inverse correlation between the percentage of TODOs in a code base and the quality of the code.

Srikaran Reddy had this argument to make:
TODOs present in code may be indicative of the quintessential engineer: one who can distinguish between what is required at the moment versus an ideal, or potential future requirement, that is of relatively lower priority. The term 'sine qua non' comes to mind. This is especially true when maintaining inherited code. On the other hand, a TODO could represent some sloppiness. There are different flavors of TODOs that need to be factored into this argument.

The good thing about TODOs is that they are easily tracked, and after a simple search, could be transformed into whatever ticketing or bug/issue tracking mechanism the team is using.

One might argue that a TODO is simply an item in your uncommitted backlog that happens to be noted in your code.

Srikaran may be the quintessential engineer, so I respect his point.  Are there flavors of TODOs just like there are flavors of quarks?  Yes I think there may be, but how do we tell them apart?  Let's put a flavor tag and annotation after the TODO comment.

Here's an idea - allow the IDE to grow the icon/font associated with a TODO by the interest rate for the technical debt it represents (I suggest prime rate + 10%).  Therefore after several years of a legacy TODO the icon or font would be 3X the normal code text.

TODOs in code do provide an easily searchable tag, it is a nice and neat way to decorate the code with more work to be done.  In the case of the bug tracking system the TODO represents work needing to be done in two places - the code base, and the entry in the bug tracking system - neither of which were done by the addition of the TODO.

The argument for a TODO representing a backlog item is weak, but interesting rationalization.  I think the purpose of the backlog in Scrum is to be a visible prioritize list of work.  The TODO fails on both attributes of this list type.  It is not visible to everyone on the team, especially the Product Owner who is responsible for prioritization.

Friday, December 4, 2009

Rx for a Team Culture

Do you think you need a prescription to create a Team Culture - OK - here you go.

  1. Executive-level statements in public and private about the importance of team players (not just teamwork platitudes).
  2. Executives model team player behaviors (not just preach behaviors).
  3. Promote and reward people with team player skills, publicly announce reasons including team player factors for decision.
  4. Reward team players with important assignments.
  5. Adjust individual performance appraisal systems to include specific team player behaviors.
  6. Hold training on attitudes, skills and behaviors of team players.
  7. Reward team players with higher salary increases, and tell them why.
  8. Create an incentive system that rewards team effort (not individual effort).
  9. Institute flexible compensation programs that allow managers to pay individuals that contribute to the team culture.
  10. Include team-player skills & abilities in management assessment programs.
  11. Develop programs of team awards that motivate the teams, flexible enough to tailor it to team needs.
  12. Appeal to intrinsic motivation, encourage managers to use nonmonetary forms of reward.
  13. Eliminate competitive rating and ranking appraisals programs.

- From Glenn M. Parker's - Team Players and Teamwork (1996) pp. 146-147. New hardcover edition via Amazon.

Monday, November 9, 2009

Acid Pour - Group Initiative

Acid pour is a game (group initiative) to investigate styles of leadership such as: command-and-control versus self-organizational teams, styles of communication and behavior of groups.

I have used this game to teach teams the difference between Agile and using a command-and-control style of leadership.  In this scenario the group elects a CEO that appoints 4 managers, the rest of the group is assigned the role of worker.  Restrictions are place on the worker such that only communication is allow to flow from the top.  For example: when the workers approach the containment area they must put on the protective suits (blindfolds), however only the 4 manager suits have intercom systems, therefore the workers will not be able to talk, nor see.  The managers will instruct them (control).  The CEO will direct the action via planning with the managers for 5 minutes, and then by announcing new directions as needed.

This scenario is very restricted, typically fails to succeed, so I allow them to try multiple times, switching roles among the group.  Then we change the paradigm.  We become an Agile company, and allow the team to make suggestions for company improvements.  Typically someone wishes we would buy better protective gear that had intercoms and that had better vision - done - retool - invest.  Remove the blindfold restriction.  Remove the CEO as controller - allow the whole team to plan - not just managers.  Allow another attempt or several (it is fun and success is desired).

Debrief (if you don’t have time to debrief - do NOT do the initiative).

Acid Pour (aka: Toxic Waste, Nuclear Meltdown)

  • boundary markers (rope works well - you’ll need 2 ropes)
  • bicycle inner tube
  • strings (1/4” line - one per participant - approx. 10’ long)
  • plastic container (office trash can)
  • small metal container (large coffee can)
  • aggregate (water, stones, packing peanuts, or other)

Set Up
  • Place the aggregate in the smaller metal container (not to heavy).
  • Fill the plastic container 1/3 - 1/2 full of water.
  • Set both containers side-by-side inside a small marked off area (5’ dia.).
  • Make a larger boundary area with a width longer than 1 string length (15’ dia.).
  • Leave inner tube and strings set outside of boundary area.

Group Task

To empty the contents of the smaller metal container into the larger plastic container, without entering the containment field (denoted by the markers).

  • Your group must neutralize this highly toxic and volatile chemical (in the plastic bucket) by pouring the agent in the can into the bucket.
  • You may use only the materials provided (strings and rubber tube).
  • You may not enter the outside containment area.
  • Neither container can leave the inside containment area.

Safety Considerations
  • Monitor blind participants (if using that option).

Common Stories

  • Meltdown in a nuclear power plant and the metal container has the water to cool the reactor.
  • Toxic waste or a volatile acid must be neutralized by adding another chemical.
  • The Toxin or acid is eating through its old container and must be put into a new, stronger container.

Options & Variations
  • Only allowing each participant a limited amount of time to speak, as if they were in protection suits with a limited amount of air.
  • Having the group elect a foreman to supervise the transfer of materials and only allowing the foreman to speak.
  • Blindfold half the group before they see the task; only blindfolded participants can touch resources. Describe the task to the sighted participants so that the blindfolded ones can’t hear it. Sighted folks must direct the others to perform the task. This is very difficult, so often good to allow them to regain sight at the end, if success is important for the group developmental stage.
  • Strings can be already tied to the tube (best for blindfolded version) or separated.

Common Issues

  • Teamwork
  • Communication
  • Leadership
  • Follow-ship
  • Creative problem solving

Friday, October 23, 2009

Ban Double Speak in Congress

Senator John McCain introduces a bill named "Internet Freedom Act".  It is designed to give broadband providers the right to block applications and content.

“Today I’m pleased to introduce the Internet Freedom Act of 2009 that will keep the Internet free from government control and regulation, it will allow for continued innovation that will in turn create more high-paying jobs for the millions of Americans who are out of work or seeking new employment. Keeping businesses free from oppressive regulations is the best stimulus for the current economy.” - McCain
So blocking the Net Neutrality Rules proposed by the Federal Communications Commission designed for freedom of access would be McCain's idea of freedom.

I think one of the problems we have in this wonderful country is we (the population) allow this type of double speak from people that should be held to a higher standard.  I just lost some respect for McCain, I thought he was a better man than that.

How would a process for naming effect the bill naming of congress - wonder if they ever pass the 1st stage - Nonsense?

The Fun Theory Contest - have fun

A company known for fun, Volkswagen (VW) is sponsoring the contest, to prove that fun is more fun than not having fun and therefore changes human behavior.

Win 2500 EU  The Fun Theory

Watch the YouTube examples, create your own idea and enter.

Thursday, October 22, 2009

What does it mean to be a Team Player?

Being on a team is a privilege not a right.  Some people inherently understand this, some do not.  Marcus Jordan, freshman guard for University of Central Florida, doesn't want to wear the team shoes.  It is big money for sports teams to make deals with sponsors - this one is $3 million.  Why does Marcus refuse to wear the team shoe?  The team shoe is Adidas, and Marcus is fond of his father's famous Nike Air Jordan.

So if you were the coach, what would you do?

Marcus Jordan

What were the choices for Marcus?  To wear the Adidas shoes and explain to the press that he was wearing the team shoe.  This has been referred to as "taking one for the team".  Or he could play the "I'm special" card.  Which is what he choose to do.

Is having a special player on the team, good for the team?

I have fond memories of Michael Jordan playing for UNC.  He was  great player for many reasons.  One was that he was so very hard to defend when driving to the basket, the defender didn't know if he would pass or take it to the hoop.  He was a team player.  He was perhaps the epitome of a team player.  So I ask myself what Coach Dean Smith would have done?

Coach Smith would have protected the team.  If the player could not play team ball, they would not play for Smith.  UCF has options in this fiasco - bench or eject the player from the team.  If you don't wear the uniform you don't play ball.  It is very simple.

Ref:  ESPN

Proposal to Adopt Agile Development Methods

Proposal to Adopt Agile Development Methods
David Koontz
Chapman University College

Proposal to Adopt Agile Development Methods

Welcome to the Twenty First Century.  We have amazing technology, a complex ecosystem of global industry, and a systems-thinking learning organization.  However, we are using antiquated software development methods. Our home-grown methodology based upon a manufacturing model of large up-front detail designs, construction, then verification, and finally production is a phased or largely sequential software development process.  This process does not work well for software - a very malleable product.  Our project success rate of 32% is slightly better than the industry average of 28% (small companies) reported in the CHAOS Report (Johnson, 1995).  However, if we continue to fail two-thirds of the time, we may find ourselves at the back of the pack, and possibly in the bankruptcy courts.
Agile software development is a family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices.  It focuses on delivering frequently and embracing changing requirements.  Many more companies are adopting Agile software development practices.  The trend is no longer a fad.  The results of Agile Transformation are clearly higher productivity, greater product quality, greater business customer satisfaction, with equal or lower cost of development (Appendix A) (Ambler, 2008).  The success rates of Agile teams exceed 80% (Ambler, 2008).  This is a drastic change from one in three successful projects to four out of five project successes.
An Agile Culture
An Agile organization, at the company level or at the project team level would exhibit the values of the Agile Manifesto:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Beck et al., 2001/2001)
The 12 principles of the Agile Manifesto (Appendix B) could be used to assess the organization as it transitions into a more Agile organization.
Business cultural changes are notoriously difficult.  It is one thing to pronounce that the company will adopt an Agile method or even that we wish to have an Agile philosophy; it will however be a completely different thing to manage a longterm transition toward those goals.  One lens through which we may view radical changes of this nature is the Bridges Transition model.  This model reminds us that changes may be as simple as announcing the goal. The transition, however, is more complex.  The transition is the path of growth that will lead to the goal, “composed of (1) and ending, (2) a neutral zone, and (3) a new beginning” (Bridges, 2004, p. 4).  Viewed through the lens of the Transition model the first phase is the ending.  That would be the point at which the organization decided to change to an Agile organization, and announce the vision. To end the waterfall of phased development.  The neutral zone is the gap between our old well known process and the new beginning when our new Agile processes are well known. A feeling that for a period of time the company may be lost, and misdirected, a feeling that may be greatly amplified as we learn and grow into this new organization and become the new company.   Bridges (2004) notes that the neutral zone is a time of learning. The new beginning, is marked by the point at which we naturally start to think of ourselves as an Agile organization, not questioning if we are, but knowing that we are Agile.  The beginning will mark new and unknown opportunities for the organization.  The ability to quickly recognize market shifts and respond to changing requirements by delivering high quality applications and software services that meet customer’s current needs.  Along with an ability to evolve our solutions as new needs arise.  Responding to valuable feedback from customers and incorporating that into new features while rapidly delivering those solutions will make our company successful.
Behaviors of an Agile Organization
Delivering frequent customer value is the hallmark of an Agile company.  To continually provide working software to our customers we must have processes that allow for last minute changes that add value.  Development processes that embrace change, rather than resist change, are goals of an Agile organization; for life is the act of constant change. 
Agile development practice allow for evolving designs rather than planning for static designs implemented in construction phases. Spending less time in up-front requirements gathering and specification elaboration phases requires trust.  Trust that the team can and will turn a requirement, even poorly specified, into actual working software.  Trust that the business will manage the resources well.  Build the most valuable assets early, not wasting energy on bells and whistles that customers do not desire. Our development teams must collaborate with the business groups on a daily basis throughout the design.  This will require commitments on both sides, as detailed plans will not be developed; therefore constant input and feedback must be part of the process.  Mistakes must be allowed to happen, even encouraged, for it is in errors that we learn the most.  Risk of large mistakes will be mitigated with short duration iterations (time-box) of design and development.  The result of each iteration will be a functional product, demonstrated to the project stakeholders for evaluation and feedback.  Adjustments will become the norm; adjustments in project scope, features, release plans, and timeframes.  These adjustment may be as large as the cancelation of a project; but when successful these adjustments will be the minor corrections that one makes to navigate the highway while driving a car.
Leadership in an Agile Organization
Agile development requires that the management assemble a group, give the group some clear goals, support the group, negotiate with the group on all aspects of constraints, and then leave the group to self-organize, and allow the power of motivated individuals joining with other individuals into a team resolving and solving the problems required to achieve the goal. In these work groups leaders will emerge.  Given clear concise goals the group will form into a team.  A typical solution for team leadership and Agile process control is the Scrum framework.  Scrum is a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1).  The Scrum framework defines only three roles for the process, a team of developers responsible for the product, a Product Owner ultimately responsible for the project return on investment (ROI), and a Scrum Master responsible for the process.  Scrum is one of many Agile processes.  It is recommended as the cornerstone of our Agile transformation because it is widely known, well defined, simple, and easy to learn.  Although it may be considered very hard to master; like riding a wild mustang on the range, it requires constant attention to the nuances of the team, processes, and product.  A Scrum Master may play a leadership role for the team, however there is no direct authority over the team members except for process authority.  The Scrum Master will be a facilitator for the Scrum process teaching other team members, the Product Owner, and stakeholders their responsibilities and roles.  The Scrum Master does not lead the team, they allow the team to develop its own leadership.  Emergent leaders in self-directed teams have greater  emotional connection with the group, and exhibit empathy for the context surrounding the group.  This context allows emergent leaders greater effectiveness in directing group performance (Cohen & Bailey, 1997).
Scrum can be successfully applied outside of a software or product development environment.  We may find upon a successful transition of the development practices that Scrum is a valuable tool in higher levels of our organization. Aspects of empirical process control with its emphasis on inspecting actual progress and adapting the next iteration to be incrementally better is inherent in organizational development methods also.  Opportunities await us along the path to Agile Transformation.
The Feel of an Agile Organization
Our current perception of a world where technologies change so fast as to leave us all behind will change when we can keep pace with the industry. When we have made significant progress toward our goal of becoming an Agile software development group we should be capable of taking rapid advantage of emerging technologies.  The strategic vision of transitioning our legacy products to a Service Oriented Architecture (SOA) will benefit from the ability to adapt to rapidly evolving standards in the new paradigm.  The development teams will be capable of using new Web 2.0 techniques that allow our User Experience designers more freedom in user interface interaction delivering a richer experience to our customers.
Product design will become a richer collaborative process, using the broad skills of many team members across our diverse organization.  A more cohesive, inclusive, and participatory product development environment should result in higher quality and insanely great products.
One principle of Agile is the sustainable pace.  We need to maintain a development pace that does not require late-nights, weekends, and a “death march” (Brooks Jr, 1995) to production.  With the addition of Agile skill sets from the Extreme Programing (XP) methods we expect developer job satisfaction to increase.  The XP practices of Continuous Integration (CI), Test-Driven Development (TDD), and Pair Programming (PP) will change the nature of the daily work of the software development group.  This will require training, coaching, and experience for our people. The physical space will also change.  Working alone in a cubicle from specification documents written 16 months prior is a practice of past eras.  A project team room that concentrates the software development group along with the product development group will increase just-in-time communication.  Teamwork will build tacit knowledge of who knowns what details and problem solving skills.  We will use techniques such as pair programming to build knowledge, skills, and abilities (KSA) within our Scrum teams.  The use of TDD will create a suite of tests (a safety net) that provides value to the development team (including the embedded quality assurance specialist). Tests will prove that the product functions as desired.  The CI system and the automated build system will allow push-button deployment of our products to System Test Servers.  Allowing frequent (almost anytime) deployment of our SOA products allowing the Product Owner to quicken the return on investment (ROI).
Dr. Dobb’s Journal article reporting on Scott Ambler’s Agile adoption and success rate survey (Feb. 2008) concluded: “In short, becoming more agile appears to be low-risk decision for senior IT management” (Ambler, 2008).
The Value Bottom Line
The value of a transition from our waterfall process to an Agile process will deliver both intrinsic values and extrinsic benefits.  Our recent effort in Triple Bottom Line (TBL) accounting, summarized by SustainAbility’s “people, planet, profit” phrase, will resonate with Agile’s people-centric view of our human capital.  A list of Agile’s intrinsic values are:

  1. Employee job satisfaction (motivation, sustainable pace, enjoyment)

  2. Humanistic values (trust in people and collaboration)

  3. Maximize project success rates (78% overall success rate; 83% co-located)

  4. Quicker time to market (releasable “barely sufficient” products)

  5. Reduction in the Cost of Change (less requirement defects, less bug fixes)

  6. Quicker time to project ROI (via more frequent release to production)

  7. Greater Productivity (82% of respondents perceived higher productivity)

  8. Higher Quality (77% of respondents perceived higher quality)

  9. Higher Stakeholder Satisfaction (78% of respondents perceived higher satisfaction)

  10. Lower Development Cost (37% of respondents perceived lower cost)

(Ambler, 2008, statistics from survey).
The extrinsic benefits will be realized as we transition to an Agile organization, these may include:  customer loyalty due to great products, ease of recruiting due to improved work environment, status in the industry and the Agile community, etc.
Expected Results
The Agile transformation will require time and patience, as well as skilled coaching.  It is expected that results in team work environments and project quality will be the first benefits to be realized.  New Scrum teams learn quickly but must be given the opportunity to make and correct their own mistakes along the Agile path.  At Yahoo Sutherland (2009) reports using a technique to jump start Scrum teams when “properly coached delivered 300-400% improvements” (p. 1).  “The best Scrum teams in the world average 750% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience” (Sutherland, 2009, p. 1).  A team at Jayway in Sweden “doing two week sprints achieved 375% of initial velocity in six sprints” (Sutherland, 2009, p. 4). Other benefits of Agile adoption will take longer to materialize, and largely depend upon the attitude of the company at large.  “Scrum was institutionalized at Systematic over a period of approximately six months” (Jakobsen & Sutherland, 2009, p. 1).  Systematic was found to be CMMI level-5 compliant in 2005, and adopted Scrum in 2006 (Jakobsen & Sutherland, 2009, p. 1). Many of the corporate level benefits are only seen in the later stages of complete transformation to an Agile corporation.
Consequences of Inaction
The status quo of failing projects after months and even years of development are in store for the long run, unless, we act to change.  Some project are bound to fail, we take risk and judge the rewards worth the cost.  However, even the Agile concept of a success when we fail fast, saving the cost of further investment in a poor idea, is a benefit that we do not currently have with our software development lifecycle.  We must invest upwards of 80% of the total project cost before we can make go no-go decision based upon functional working software.
Action Plan
First Steps
Training is the first step after a decision by corporate management.  We must all speak a common language regarding the Agile philosophy and lexicon.  Scrum training is the easiest Agile training obtainable and is offered at reasonable cost for ad hoc attendance of two day seminars, or a Certified Scrum Trainer may be engaged to come on site.  This would be considered initial training for key personnel and valuable for further organizational change development planning stages.  Educating ourselves on the Agile values and methods and then developing our organizational change action plans within a Scrum model of inspecting and adapting will be a great experience for our management team. A further step will be to hire an Agile coach, a person to guide the organization, to mentor future Scrum Masters, Product Owners as well as Team Members.  This person will be tasked with oversight of the change initiative, and report to the VP of Product Development.
The Map is Not the Terrain
In the Robert DeNiro film “Ronin”, DeNiro's character Sam expresses the need to actually see the place, to physically be in the space:  “The map, the map, the map. The map is not the terrain.”  An action plan is not the Agile path we will traverse.  Dwight D. Eisenhower said, “The plan is useless; it’s the planning that’s important.”
Kurt Lewin’s Action Research model of organizational development and change will be to overarching approach.  It meshes well with the Scrum framework.  Action Research is a cyclic process model facilitated by an Organizational Development (OD) Practitioner, which relies heavily upon the collaboration of a client group (transformation team) for exploration of data, problem space diagnosis, action planning, implementation, evaluation of interventions, and further cycles of planning, actions, and post action assessment (Jackson, 2006).
In the cyclic process of Action Research we have reached step (3) preliminary diagnosis.  A problem has been perceived (step 1), and collaboration with an OD practitioner (step 2) has commenced.  The preliminary diagnosis (step 3) is to institute an Agile transformation of the software development group.  With a possible larger transformation of the company as an organization in the future.  The future steps are: (4) gather data from the transformation team, (5) data feedback to the team, (6) team exploration of data and problem domain, (7) team action planning, (8) team takes action, (9) post action evaluation and data gathering, (10) new action planning by team, (11) new action taken by team, (12) post action assessment, then a repeating of the cycle (Jackson, 2006, p. 140).  However, let us take first steps first.  The Scrum training of key personnel would be the preliminary recommendation of an action.  The transformation team and executive management should take this proposal under consideration and decide if this is the proper course of action.  In other words, will they commit the company to this Agile course of action?  Knowing full well that our plans may need to be adjusted, and being responsible for evaluation of the action, and any future adjustments necessary.
Resonance with Organization Development Theories
The cultural change that an Agile transformation requires may be analyzed via Force Field Analysis. “In planning for change, it is advantageous to identify those conditions that will help or hinder the change initiative” (Jackson, 2006, p. 145).  The transformation team may use this tool to identify the driving and restraining forces for the Agile transformation initiative.  After identifying all forces both pro and con the forces are assigned relative weights (or points).  The weights allow some subjective measure of the effort the force applies to the current situation (status quo).  Analyzing these forces the team will try to strengthening the driving forces while weakening the restraining forces, and possibly devising strategies to flip a force from restraining to driving.  This will allow the team to identify impediments to the initiative and seek management support in removing the impediments (a role of the Scrum Master).
Action Research Becomes Scrum
The team members trained in Scrum will recognize may of the aspects of Organizational Development methods such as Action Research.  Scrum and many of the Agile processes draw on years of research and studies of team dynamics, process workflow, continuous improvement, systems-thinking, and organizational learning (Sutherland, 2004).  Scrum uses very small iterations and feedback loops on many levels to plan work over a short duration, inspect the progress of the work done, to expressly define the standards of completed work, and to reflect upon the work, processes, and techniques to constantly improve and move forward.
Methods to Facilitate Transition
Many Agile development groups have embraced more humanistic values for work, attempting to capitalize on knowledge workers innate desire to enjoy their work and their internal motivation.  Herzberg’s Two-factor theory is applicable to this situation.  Also referred to as the Motivation-hygiene theory, it describes the factors that lead to worker satisfaction (motivators) and factors that lead to dissatisfaction (hygiene) if not attended to well.  Herzberg concluded that the satisfaction scale was not a single continuum.  The factors that lead to dissatisfaction (work conditions, salary, relationships, supervision) when poorly managed, did not lead to satisfaction when expertly managed.  There are very different factors that lead to satisfaction.  These motivating factors are: growth, advancement, responsibility, recognition, achievement, and work itself (Robbins & Judge, 2009).  Agile methods support these motivational factors in the work place.  Additionally many Agile teams use Appreciative Inquiry during retrospectives.  Appreciative Inquiry “seeks to identify the unique qualities and special strengths of an organization, which can then be built on to improve performance.  That is, it focuses on an organization’s successes rather than on its problems” (Robbins & Judge, 2009, p. 632).  Scrum requires a team retrospective each sprint (iteration), this is a process inspection and a chance for adaption.  Using Appreciative Inquiry builds on teams ability to learn and improve, recognizing that perfect execution may be a goal, but rarely attainable on the first several attempts.
Organizational Change was studied by Kotter, who developed an eight step change model largely from the failures of companies engaged in change initiatives. “A few of these corporate change efforts have been very successful. A few have been utter failures. Most fall somewhere in between, with a distinct tilt toward the lower end of the scale” (Kotter, 2007, p. 96). Kotter’s recommendation are: “(1) Establish a sense of urgency; (2) Create the guiding coalition; (3) Develop a vision and strategy;  (4) Communicate the change vision; (5) Empower broad-based action; (6) Create short-term wins; (7) Consolidate gains and produce more change; (8) Anchor new approaches in the culture - make it stick” (Jackson, 2006, pp. 166-167).  Kotter (2007) warns that skipping steps or not given proper attention to a step is the typically mistake made by failing corporations.  There are valuable lessons to learn from these mistakes.
Recognizing Success - Metrics
Scrum uses very simple tools for measuring iteration success.  These metrics are the Scrum task board with task to be done, the in-process task, and the done task.  The task board will be the center of activity during stand-up meetings each morning.  A quick look at the board allows everyone to see progress being made and the work remaining during the sprint.  It is the Scrum team’s job to manage this and radiate the information to all.  Another information radiator is the release burn-down chart showing the completed work and remaining work required for a product release. The physical changes in Agile adoptions will be easy to recognize.  These will be groups of strangers forming teams, teamwork and group discussions, “big visible charts” used as information radiators (burn-down chart), stand-up meetings, product demonstration, application  test suite pass/fail monitors, project build charts, broken build email notifications, the list goes on and on.  One specific example; on some teams the engineers wire-in a flashing red light to the build machine, if a build fails the flashing light alerts everyone in the room.  Quick action by the developer that broke the build by committing the defective code is the result.  This “stop the line” behavior will become obvious to management that takes the time to understand the Agile process. 
Agility of our development organization may be measured by several instruments.  Cautions using these instruments should be used as they are not as well studied as may psychometric test such as IQ test or Myers-Briggs Type Indicator for example.  The simple 10 question Nokia Test is one example.  “The Nokia test is a similar to a maintenance check on your car. It looks at whether your tires have air, your tank has gas, all cylinders are firing, and makes sure there are no critical missing pieces to your car. You should perform it before you go out for a drive with your Scrum team” (Sutherland, 2009).  A more comprehensive measure that allows organizations to perform longitudinal studies of improvement in Agility is the Comparative Agility™ survey by Cohn and Rubin (2008). This survey is available free of charge on the web (  However, it has not been studied for reliability and validity.  Of course, the Action Research transformation team will evaluate every intervention, and use any instrument that is deemed appropriate.
More subtle successes will be rates of project success, measured over much longer periods of time. Greater return on investment for projects, as well as quicker cost recovery and lower investment cost.  These will come after Agile process are in place and the corporation begins to take advantage of Agile’s many secondary benefits.  The measures will be typical business metrics already in place at our company.
Agile transformations do not happen overnight.  They are not without trials and tribulations.  In a systems-thinking view of our organization a change in the development process will ripple outward effecting other departments.  Scrum does not offer to fix our problems, it is no silver-bullet.  A core value of Scrum is transparency.  “Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes” (Schwaber, 2009, p. 1).  We will not be able to solve problems of which we do not have knowledge.  We must trust others motivates when they raise issues and collaborate on solutions.  Our Agile coaches will have faced many of the issues our transformation will conjure up, some may be unique to our organization.  An Agile philosophy is that making decisions and then monitoring the outcome, even if a mistake, is much better than postponing the decision past the last responsible moment.
Many Agile adoptions start with pilot projects and with tentative steps toward half measures.  These attempts have been labeled “Scrumbut” processes.  Agile practices work as an orchestra producing a symphony, to remove one section of the orchestra will mute a portion of the symphony.  The expected results will not be achieved with half measures.
Cost for Certified Scrum Master training is $18,000 (plus expenses) for up to 20 participants on site.  Agile coaches salaries are approximately $130,000.  We may lose some employees who do not wish to transition to Agile work methods.  There are also indirect cost associated with every change. Infrastructure cost will be incurred to retrofit our software development work bay of cubicles into team rooms with modern pairing stations and a more flexible organic work space.  Details will be studied by the transformation team and evaluated when the time comes for those decision.
Change is the nature of our business.  If we do not change our business methods and adjust then change will be force upon us.  Adopting an Agile stance will allow us to change with the industry, to seize opportunities before challengers, and to outperform competitors.  It will provide for a people-centric development practice, that is at our companies core beliefs.  Many other companies have seen higher productivity, higher quality, greater job-satisfaction and overall cost reduced using Agile methods.
The first step towards this cultural transformation is for the Executive Management Team to approve this proposal, to join the Agile community, to communicate the new vision, and begin the transformation into an Agile organization.

Appendix A.  Agile Adoptions Rate Survey Results
Agile Adoption Rate Survey Results (February 2008) published in “Has Agile Peaked?” Dr. Dobb’s Journal (June 2008) by Scott Ambler: ( used with permission).

Appendix B.  Principles of Agile Manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  4. Business people and developers must work together daily throughout the project.

  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

  7. Working software is the primary measure of progress.

  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  9. Continuous attention to technical excellence and good design enhances agility.

  10. Simplicity--the art of maximizing the amount of work not done--is essential.

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

  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

(Beck et al., 2001/2001)

Appendix C.  Definition of Terms
Agile software development - A family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices focusing on delivering frequently and embracing changing requirements.
Burn-down chart - a information radiator depicting the progress made toward a goal.
CMMI - Carnegie Mellon, Software Engineering Institute’s Capability Maturity Model Integration - a measure of process maturity (5 being the highest level).
Lightweight process - generalization of Agile processes; relative to highly formal processes or heavyweight processes.
Methodology - “a system of methods used in a particular area of study or activity” (Jewell, 2001).
Product Owner - a role on the Scrum team responsible for prioritizing the work to be done, to optimize the return on investment.
Scrum - a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1).
Scrum Master - a role on the Scrum team responsible for optimize the process and productivity.
Scrum meeting - a short focused daily plaining meeting for the team, also called the standup meeting (because no one is allowed to sit).
Sprint - a time-boxed iterations of product development (typically one month or less).
Time-box - a fixed time duration in which a task is performed.
Velocity - the amount of work a Scrum team performs in one sprint (may be measured in unit-less value of story points).
Waterfall - a generic term applied to heavy-weight formal sequential phased development methods.

Ambler, S. W. (2008). Has agile peaked. Dr. Dobbs Journal: The World of Software Development, 3(6), 52-54.
Beck, Beedle, Bennekum, Cockburn, Cunningham, Fowler, et al. (2001). Manifesto for agile software development. Retrieved november [Web page]. (Original work published 2001)
Bridges, W. 1. (2004). Transitions : Making sense of life's changes . Cambridge, MA : Da Capo Press.
Brooks Jr, F. P. (1995). The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
Cohen, S. G., & Bailey, D. E. (1997). What makes teams work: Group effectiveness research from the shop floor to the executive suite. Journal of Management, 23(3), 239.
Cohn, & Rubin (2008). Comparative agility survey. [Web page]
Jackson, J. C. (2006). Organization development : The human and social dynamics of organizational change (illustrated ed.). Lanham, MD : University Press of America.
Jakobsen, C., & Sutherland, J. (2009). Scrum and cmmi--going from good to great: Are you ready-ready to be done-done?. Agile 2009.
Jewell (2001). The new oxford american dictionary (illustrated ed.). Oxford University Press.
Johnson (1995). The CHAOS report (1994). Standish Group. Retrieved September 24, 2009, from
Kotter, J. (2007). Leading change: Why transformation efforts fail. Harv Bus Rev, 96-127.
Robbins, & Judge (2009). Organizational behavior . Upper Saddle River, N.J. : Pearson Prentice Hall.
Schwaber (2009). Scrum guide. [Pamphlet]
Sutherland (2009, August 25). Nokia test: Where did it come from? Scrum log (Jeff Sutherland's Blog) [Web page].
Sutherland, J. (2004). Agile development: Lessons learned from the first scrum. Cutter Agile Project Management Advisory Service, 5(20).

Proposal to Adopt Agile Development Methods
Wednesday, October 14, 2009

Apple-Innovation is the Key

David Koontz, Sumalee Mahaguna, Daniel Stiles
Chapman University

    Organizations have many distinguishing factors that make them successful in their field.  However, one factor that is apparent in great organizations is vision.  Organizational vision is necessary for an organization to be successful because creative energy begins with vision.  Creative tension is the driving force which organizations use to make their vision a reality.  “Visionary companies are premier institutions…in their industries, widely admired by their peers and having a long rack record of making a significant impact on the world around them” (Collins & Porras, 2004, p. 2).  According to Peter Senge author of the Fifth Discipline, vision is distinct from purpose.  Purpose is abstract, leading towards a general heading whereas vision is a specific heading that is concrete (Senge, 2006).  Apple is a visionary organization that has a clear vision and purpose that can be seen through their innovative products over the years.  Apple’s original vision was, “to make computers for the rest of us,” while their purpose is, “to make a contribution to the world by making tools for the mind that advance humankind” (Collins & Porras, 1991, p. 39).  A purpose without a vision prevents forward mobility in an organization.  Conversely, a vision without a purpose is also futile; they go hand in hand. 
    Besides having a vision and a purpose, organizations need to take further steps to implement their corporate vision and ensure that this plan of action is known and practiced throughout the organization.  John Kotter, a professor at Harvard Business School and author of the book Leading Change list eight important steps for change.  The eight steps for organization change parallels the steps needed to implement vision within and organization.  These steps include: establishing a sense of urgency, forming a powerful coalition, creating a vision, communicating the vision, empowering others to act on the vision, planning for and creating short term wins, consolidating improvements and still more change, and institutionalizing new approaches (Kotter, 2007).  Since the initial start of the organization, Apple has had both successes and failures in the implementation of their visions while striving to fulfill their purpose, creating tools for the mind to advance humankind.
Establishing a Sense of Urgency
    In Kotter’s model for transforming an organization, the top priority for establishing a powerful “sense of urgency”, Kotter notes that many companies start to change when someone or some group in the company sees the impending doom of a market position, or competitive opportunities.  This type of opportunity was seen by Steve Jobs when Apple was founded in 1976.  The cofounder of Apple Steve Wozniak said, “It never crossed my mind to sell computers. It was Steve who said, ‘let’s hold them up in the air and sell a few’” (Westley & Mintzburg, 1989, p. 25).  This insight resulted in the personal computer industry (Jackson, Mandeville, & Potts, 2002, p. 328).  The mainframe computer manufactures of the day did not see a need for a home computer.  Prior to Apple’s home built kit Apple I computer, the industry for personal computer did not exist (Jackson, Mandeville, & Potts, 2002, p. 326-327).
    During Apple’s thirty years of existence, Steve Jobs has established several changes because of competitive opportunities.  In the 1980s Macintosh development era, Jobs created a race to market.  The Lisa team had started work on their product years before the Macintosh team had started their project.  Steve Jobs made a bet that his team which featured the Macintosh would be the first to market.  Unfortunately, Jobs lost the bet; the Lisa did launch before the Macintosh.  However, Jobs was the true winner because the Macintosh won the longer race in the market place.
    In the decade (1987-1997) without Steve Jobs leadership, Apple continually lost market share and failed to execute a clear product vision under the direction of CEO Sculley (West, 2007, p. 7).  Apple culture was out of Sculley’s control.  Apple was able to regain their footing on the path to creating “insanely great” products (West & Mace, 2007, p. 6) upon the return of Steve Jobs in 1997.  Jobs reasserted his leadership in many areas and the first thing he did upon his return to Apple was announced a deal with Microsoft who invested $150 million in Apple stocks (Kawamoto, et al. 1997).  This move shocked the industry.
Forming a Powerful Guiding Coalition
    Apple’s internal coalition of executives and leaders are much harder to ascertain; the company is known for its secrecy.  Certainly, tight groups of people have formed around the various shared visions of products.  Early on, Jobs “organized Apple office as a circle of work areas around a central foyer.  There stood a grand piano and a BMW.  ‘I believe people get ideas from seeing great products,’” Jobs claimed (Wise, 1984, p 146; Westley, 1989, p. 20).  Apple may have been one of the first companies to use evangelism marketing.  This ability of the company to enroll and develop a very strong relationship with customers is another form of coalition building where Apple has excelled.  Customers become voluntary representatives of the company, advocating for the products and services, an early form of viral marketing (Apple Evangelist, 2008). 
    Apples success in creating a coalition of business partners has been questioned by many and recognized as a short coming by Jobs.  In a joint interview with Bill Gates, Jobs said, “Because Woz and I started the company based on doing the whole banana, we weren’t so good at partnering with people” (Gates, et al., 2007, p. 25).  Jobs had recognized that Microsoft’s success was partly contributed to the coalition they were able to foster.  Microsoft is Apple’s longest running successful partnership.  The two companies worked together in the early days of Applesoft BASIC built into the Apple II which was credited with making the computer successful (Linzmayedr, 1999, p. 15).  Notably, they have been rivals in the eyes of many; however, the Macintosh platform was a large portion of Microsoft’s revenue (Linzmayer, 1999, p. 239).
    A holy grail for the telecommunication industry for the last 20 years has been “convergence of communication and computing” (West, 2007, p. 10).  Apple CEO John Sculley was a big proponent of convergence and championed the Newton MessagePad, creating the niche market for the personal digital assistant (PDA) (West, 2007).  Although Steve Jobs terminated the Newton product upon his return to Apple in 1997, Apple was learning to partner with other companies.  In the last decade, Apple has worked successfully with the music industry on iTunes store and digital rights management for songs.  They have also established partnerships with telecommunication companies worldwide to market the iPhone in over 90 countries (Apple, 2009).  Apple has learned to join and build communities for its products that foster organizational mission.
Creating a Vision
    Apple was created on a vision that Steve Jobs, Steve Wozniak had in 1976 in a garage.  Their vision was to create computers that the average consumer could use without possessing the technical knowledge or skills.  Computers at the time were only limited to a certain market niche and the average homemaker or sales clerk were not a part of this niche.  Apple founders saw that their technology could bring enrichment into the lives of people.  These computers would be affordable yet different enough to stand apart from all the other computers sold on the market.  The idea was to have an “Apple computer on every desk” (Ditlea, 1981, p. 1).  This idea became the foundation for which their vision was built upon.  Their vision was extremely radical compared to the other computer companies at the time.  As radical as their ideas may seemed, their vision attracted many other computer enthusiast into their business and completely set them apart. 
    Having a vision is extremely important to the success of an organization because without it, there is nothing pulling the organization forward.  “Vision is a specific destination, a picture of a desired future” (Senge, 2006, p. 138).  The organization was founded on a vision and this vision propelled the founders to continually innovate computers.  Initially, their vision was quite simple, to make computers that everyone can use.  Their vision has evolved over the years to communicate an even greater need to change the world through their innovation.  This desire lead to establishing purpose for their existence and that is “to make a contribution to the world by making tools for the mind that advance humankind” (Collins & Porras, 1991, p. 39).  Apple felt that they had more to contribute to society than just computers.  They have expanded their technology into the music industry and the phone industry.  In a special review by Business Week, Steve Jobs made a statement saying, “We have just begun” (Business Week, 2000, p.1) as a prelude to his plans for the future.
Communicating the Vision
    Apple started life as a business, not as a company.  The gradual change from a bloated garage operation into something resembling a corporation was arduous and protracted (Moritz, 1984).  What was even more arduous than the transformation was the communication of the founder’s vision to the rest of the organization.  Originally, the idea of creating computers that a normal person would be able to use was the driving force behind the organization.  Apple employees had strong feelings about this because it set Apple apart from the other computer companies.  They were even successful in recruiting employees from various companies such as Intel, National Semiconductor, and Hewlett Packard (Moritz, 1984).  These employees readily resigned from their current position at these various organizations for Apple because they saw that Apple had something different to offer. 
    Initially, communicating the vision to other Apple employees was not hard because the organization was founded on a vision.  However, as more people flocked to Apple, the harder it became to communicate this vision.  The glue that once held the organization together began to fall apart as the company grew at an exponential rate and the vision was lost amongst the new faces that continually showed up on a daily basis.  Hiring from other organizations also brought discontinuity into the organization because employees from IBM or Hewlett Packard would bring culture from these various organizations that were not compatible with Apple.  Eventually, Apple’s success became their enemy and Apple found themselves operating similarly to organizations such as IBM.  This was something they tried extremely hard to avoid but with so many people working in the organization, bureaucracy was the only way to manage everyone.  “By 1980 the company was too large and too scattered for any one manager to cover on a daily stroll to take the air and test the waters.  So for most of the employees, the corporate hand was invisible” (Moritz, 1984, p. 257).  Apple tried limiting some of these discontinuity within the organization by establishing a committee whose main purpose was to “reduce the abstract into the concrete and codify all the conflicting impulses and intentions, the clashes between individual enterprise and teamwork, between autocracy and democracy, that make up a company” (Moritz, 1984, p. 257).  The committee set out to turn the company around which included the culture and the working environment.  The idea was to get the organization into an alignment in order to start working cohesively again.  One of the methods used to reach alignment was to reestablish their cultural values throughout the organization.
    There was no doubt that Apple employees were employed because of their passion for computers so Apple founders found that the best way to communicate this value was thought their products.  Apple started a new policy for their office procedures.  No more typewriters were to be purchased or leased and the existing ones were banished.  Apple believed that before they could communicate their vision to the public, they should fully believe in their products first by utilizing it in the workplace.  Shortly after Apple did away with typewriters, the term secretary was also abolished to reflect the varied responsibilities that could be accomplished by the personal computer.  The term area associate took the place of secretary.  Apple also started a program that gave Apple employees their own personal computer once they had demonstrated minimal efficiency.  They also offered classes for family members and large discounts to friends and family members.  Apple founders wanted the work place to be more than just a place to come to, do what you had to do, then go home.  He wanted the work place to be a place where people could innovate and have the freedom to do more rewarding and enriching tasks. 
Empowering Others to Act on the Vision
    The Macintosh group was formed to examine the feasibility of developing an extremely low cost computer for the public.  Steve Jobs took over the program and “was determined to build a computer that was in his words, ‘insanely great’” (Nonaka & Kenney, 1991, p. 75).  Early on, the Macintosh team did not have an exact idea of what the computer would be like and were not given a development schedule.  An engineer in the project said that, “Steve allowed us to crystallize the problem and solution simultaneously” (Nonaka & Kenney, 1991, p. 75).  Jobs and his predecessor as group leader “set out only basic principles; it was the personnel of the team who would concretize these.  “The Mac team was self organizing” (Nonaka & Kenney, 1991, p. 76), they were empowered to innovate.
    Another example of empowerment of their employees is the loan to own program.  Apple offered employees voluntary classes on their computer applications.  When an employee demonstrates proficiency in at least two applications, they can then participate in a loan to own program.  An Apple personal computer is given to the employee to use at home after one year, it is given to them free of charge.  The employee is thus better skilled at work, and it helps to promote the vision of computer for everybody.
Planning for and Creating Short Term Wins
    One of Apple’s significant achievements has been “the implementation of the office workplace of tomorrow” (Ditlea, 1981, p. 3).  Apple “inaugurated the workplace of the future by putting computers on most of its employee’s desks” (Ditlea, 1981, p. 1).  Mike Scott, Apple president at the time said, “Apple is an innovative company.  We must believe and lead in all areas.  If word processing is so neat then let’s all use it.  We believe the typewriter is obsolete.  Let’s prove it inside before we try and convince our customers” (Ditlea, 1981, p. 1).  This internal move increased employees effectiveness, improved job satisfaction, and led to very little turnover.  It freed managers from doing mundane and time consuming paperwork tasks.  This newly available time allowed them to coach employees leading to a much improve workplace atmosphere.
In this case, Apple was able to lay the foundation for the realization of a long term goal and vision of having the general public use their computers.  They were able to start it on a small scale with a short term goal for their own employees.  As a result, some of the lowest level employees were able to begin contributing on a higher level.  Steve Jobs stated, “Not only do our area associates (secretaries) have the freedom to do more rewarding, enriching tasks, they have a chance to get involved in solving problems that ultimately affect the success of the entire company” (Ditlea, 1981, p. 2).  Apple created a long term external winning situation for itself with consumers by creating a short term internal winning situation with their employees.
Consolidating Improvements and Producing Still More Change
    The computer industry has inherently understood and acted upon this aspect of Kotter’s model.  Much of the industries success and blinding pace of improvements are attributable to the ability of a company to make refinements to their products, building faster, and more powerful computers.  In building these superior computers, the company may change the nature of its core business.  Many companies of the past have failed to manage the transition from the mainframe era to the personal computer era (e.g. Burroughs, Control Data, Data General, Digital Equipment, Sperry-Univac, Wang) (Jackson, et al., 2002, p. 330).  The companies that have excelled at keeping pace with these changes are some of the fastest growing companies in history (e.g. Apple, Dell, Cisco, Microsoft, Oracle) (Jackson, 2002, p 330).  Many of the companies that have failed did not understand the shifting dynamics of the industry and clung to outdated paradigms.  “Paradigms are a source of both strength and weakness- strength in that they tend to reinforce successful patterns of behavior, and weakness for the same reason” (Jackson, et al., 2002, p. 331).
    Apple’s ability to change paradigms as an industry leader is obvious in the history of the short lived personal computer industry.  Apple created the personal computer industry; then they innovated the graphical user interface (GUI).  Adopted by the industry the GUI, innovated the desktop and file folder metaphor that has predominated the industry.  Apple is now innovating appliance model in computing products that integrate vertically from device to network to content.  The iPod and iPhone product lines are examples of Apple’s ability to envision a paradigm change, put that vision into action and achieve game changing results.  Kotter’s seventh step is evidenced by “using increased credibility to change systems, structures, and policies that don’t fit the vision” (Kotter, 2007, p. 7).  Apple has used its very successful music industry changing iPod product line with iTunes music store credibility to also change the smart phone application market, achieving 1.5 billion downloads in the first year of App Store operation (Elmer-DeWitt, 2009).  Apple has used the “core competencies that the company has acquired over its thirty year history, notably in product marketing and innovation” to redefine market segments (West, 2007, p. 24).  On the success of the iPod and iTunes music store, Apple launched its iPhone, creating the most successful convergence device.  The iPhone has proven that Apple can both consolidate their core competencies while continuing to innovate. 
Institutionalizing New Approaches
    In Kotter’s eight step model, Apple’s ability to articulate the connections between the behaviors that have lead to corporate success are apparent in one word, innovation (Kotter, 2007).  Kotter is concerned that the corporate vision be institutionalized as opposed to being carried by a leader.  Apple’s vision is to create products that enhance people’s lives and make the use of computers in all their forms easy, intuitive, with a seamless coherent experience.  The recent success of the iPod in the music player market space is an example of the execution of this vision.  Apple recognized that the music player market was a disjointed experience for the consumer.  They built a music player device that used Apple’s core competencies in computer, networking, product design and user experience.  They partnered with the music industry creating coalitions that learned a new method for product delivery, drastically changing the music industry.  This is an example of one product line that fulfills the vision of Apple’s purpose may appear to be a fluke.  However, each of these Apple products were innovations that changed the industry: Apple I computer, Apple II computer, Macintosh, iMac, iPod, and most recently, the iPhone.  Apple has proven that it is capable of changing the institutions that it deals with externally while adapting to the required business processes and organizational change that paradigm shifts require.
    Over the past thirty years, Apple has met with many successes and failures.  They have proven time after time that they are able to overcome challenges and rise above any disparities that may come their way.  Apple was built on a vision, yet vision alone is not enough for organizational growth or success.  An organization needs to be able to communicate their vision throughout the company and they need to empower their employees to act on this vision in order to make it a reality.  In order for organizations to achieve their vision, they have to be receptive to change and provide an environment that promotes change; only then can an organization grow.  John Kotter’s eight step model for change outlines the way Apple implements their vision throughout the organization. 
    When Apple saw the opportunity in the market place for personal computers, they established a sense of urgency.  Initially, Apple did not have strong coalition in the organization but soon learned that in order to survive, they needed to form a coalition and of the biggest step they took was by partnering with Microsoft.  Creating a vision is the third step in the model but Apple already had a vision.  Communicating this vision was a harder task for the organization because it was growing so fast, but in the end, they were able to do this by redefining values.  Apple empowered their employees by allowing them to partake in decisions that could ultimately affect the success of the company.  Apple also empowered their employees to innovate and do more fulfilling tasks by providing them with their own computers.  This was also a big step towards creating short term wins.  Before Apple could sell computers that were supposed to improve lifestyles, they had to believe it themselves so they provided their employees with free computers and classes.  Apple is continually consolidating improvements and implementing more change because the market is always changing.  An organization that wants to survive needs to be able to keep up with these changes and they need to keep making improvements.  Institutionalizing new approaches is the last step in Kotter’s model and Apple is continually experimenting with new approaches.  They have mastered the personal computer industry only to move into the music industry and then to communications.  Apple’s ability to implement their vision, innovate, and adapt to change makes them a true visionary organization.    

Apple. (2009). IPhone around the world.  Retrieved July 15, 2009 from
Apple Evangelist. (2008, December 16). In Wikipedia: The Free Encyclopedia.  Retrieved July    11, 2009, from
Business Week. (2000, September 25). Apple’s steve jobs: Our vision is we have just begun.    Retrieved July 22, 2009, from
Collins, J., & Porras, J.I. (1991). Organizational vision and visionary organizations. California    Management Review. 30-52. Retrieved July 22, 2009, from Business Source Premier    database.
Collins, J., & Porras, J.I. (2004). Built to last: Successful habits of visionary companies. New    York: HarperCollins.
Ditlea, S. (1981). An apple on every desk. Inc. Magazine. Retrieved July 22, 2009, from
Elmer-DeWitt, P. (2009). Apple 2.0 How Apple’s App Store got to 1.5 billion    downloads. Retrieved July 14, 2009, from    downloads/
Jackson, M., Mandeville, T., & Potts, J. (2002). The evolution of the digital computation    industry. Prometheus, 20(4), 323-336.
Kawamoto, D., Hesket, B., & Ricciuti, M. (1997). Microsoft to invest $150 million in Apple.    CNET New, August 6, 1997. Retrieved July 11, 2009, from    1001-202143.html
Kotter, J. (2007). Leading Change. Harvard Business Review, 85(1), 96-103. Retrieved July 11,    2009 from Business Source Premier database.
Linzmayer, O.W. (1999). Apple confidential: The real story of apple computer, inc. No Starch    Press. Retrieved July 9, 2009 from    tten_Founder.pdf
Moritz, M. (1984). The little kingdom: The private story of apple computer. New York: William    Morrow and Company.
Nonaka, I., & Kenney, M. (1991). Towards a new theory of innovation management: A case    study comparing canon, inc. and apple computer, inc. Journal of Engineering and    Technology Management, 8, 67-83.
Senge, P.M. (2006). The fifth discipline: The art and practice of learning organization. New    York: Doubleday.
Swisher, K. & Mossberg, W. (2007). Transcription of Interview: Steve Jobs and Bill Gates. D5    Conference.  All Things Digital. New York: Ubiqus Reporting Inc.
West, J., Mace, M. (2007). Entering a mature industry though innovations: Apple’s iphone    strategy. DRUID Summer Conference. Copenhagen.
Westley, F., & Mintzberg, H. (1989). Visionary leadership and strategic management. Strategic    Management Journal, 10, 17-32.


See Also:

Why Tim Cook is Steve Ballmer and Why He Still Has His Job at Apple by Steve Blank June, 2017.
"What happens to a company when a visionary CEO is gone? Most often innovation dies and the company coasts for years on momentum and its brand. Rarely does it regain its former glory."