Enterprise Projects Need to Start with Sprint Zero

The idea behind “Sprint 0″ is that software development teams should spend some time at the beginning of an agile project doing analysis, design and other preparation tasks. I’m not referring to small projects — a few people for a few months. I’m thinking about enterprise projects involving multiple teams deploying to multiple servers.

At the lowest level, good software is good software. The tools and techniques used are analogous regardless of the size of the resulting system. At the highest level, good design at a small scale does not translate into good design at an enterprise scale. New problems appear at scale. Those problems demand new ideas and unique solutions.

Sprint Zero Gets a Bad Rap

I think many people despise the idea of “Sprint 0″ because they envision a bunch of managers and technical hotshots hanging around trying to manage every last detail of the project. They also interpret the Agile Manifesto too literally in assuming that only delivered software has any value — everything else is fluff.

If it was possible to dive in and create an elegant enterprise system design by simply writing code, I’d be all for it. Why do extra work? Let the code drive the design.

That may work for small systems but in enterprise systems, it flops. The resulting code always requires rework — often to the point of being discarded and re-written. That leads to the second Manifesto misinterpretation. Redesigning code does not qualify as ‘refactoring‘. Look it up. Refactoring changes the internal structure of code not the external behavior.

If the design doesn’t scale, refactoring won’t help. If you have to start over after one or two sprints, skipping Sprint 0 was a bad idea.

The Challenge

We need to do some analysis and design at the outset of big projects without getting sucked into creating gantt charts, requirements specifications and technical design documents. Here are some questions to answer during sprint 0.

Implementation Questions

• What is the scope of the project (vision)? What are the key goals?
• Who will be involved in the project? Do we have a sponsor, stakeholders, user representatives and key members of the software build team?
• How many simultaneous users will the software system have to support?
• How much data will be processed each hour, day, week, etc.?
• How secure does the system need to be (authentication, encryption, etc.)?
• How fast does the system need to respond?
• When will test data be available? (Not just contrived data elements but real world information that can be processed by the new software.)
• What software and hardware tools will we use? Are they already in house or must they be procured?
• What are the greatest risks we face? What can we do to mitigate them?
• What constraints exist and what assumptions are we making? (This would be a good time to write some exploratory code to test assumptions or evaluate risks.)
• What system interfaces are we dependent upon? Are they internal or external? Do they exist yet? (Another area where exploratory code may be helpful. If an interface does not yet exist, you may need to emulate it.)
• What will the user interface (UX) be like? (This is a good time to sketch up some ideas.)

Process Questions

• How will we work? How long will sprints be? What is the definition of done?
• Do we have a product backlog? Is there a separate backlog for this release?
• When do we have to deliver something (minimal release, full release)? Are there critical dates we have to hit?
• How will we know when we’re done? What are the key measures (budget, target date, minimum feature set, etc.)?
• What metrics will we track and how?
• Is the software development environment available? If not, what needs to be done?
• Is work space available? Will all team members be together? How will everyone stay connected?

If the stars are in alignment for your project, you may be able to fly through these questions in a couple of days and begin writing code. It’s more likely, however, that many answers will be vague or missing. Apply lean principles. Think about the simplest way to answer the questions.

You may decide to put off answering some of these questions until a few sprints are done. That’s okay. Having gone through this exercise, at least you’ll know what’s ahead.

photo credit: gatogrunge via photopin cc

Don’t Ask Me What I Want, Give Me What I Need

I don’t know about you, but scenarios like the following happen to me all too often. I meet with the business stakeholders and representatives of the user community to discuss changes to a software application. We discuss new features and/or changes to existing ones. They give me a general idea of what they want. I describe how this might operate within the software. They indicate agreement and I go forth to develop the features in our sandbox.

Depending on the type of changes and which software development groups need to be involved, I may create a formal specification, write up stories and/or throw together a mock-up. For small efforts, I may simply make the changes directly in the sandbox (Salesforce.com makes this really easy). I can always write some kind of documentation after we agree on the implementation approach.

So far so good, right? I show them the sandbox implementation. They offer a few minor suggestions and ask how soon the changes can be deployed in production.

We love it … But …

Here’s where it gets interesting, amusing or frustrating depending on your point of view. The changes are deployed and complaints arrive in my inbox — usually only a few but on occasion, it can be a blizzard! Why does that happen?

1. Sometimes the stakeholders and user representatives didn’t fully understand the problem expressed by the end users.

They should have dug deeper and I should have engaged at least some of the end users directly rather than having all the information filtered through their reps.

2. Sometimes the stakeholders and user representatives didn’t fully understand the solution I proposed.

They should have spent more time exercising the sandbox implementation and asking questions. I should have explained the solution better and more importantly, I should have clearly defined what the software would and would not do.

3. Sometimes the stakeholders and user representatives didn’t really know what they wanted. Their real intention was to try something, see the result, and make another set of changes to the software based on user feedback.

That’s fine too, though they should have stated up front that they wanted to conduct an experiment. This is a communication breakdown that stems from lack of trust.

4. Adding more people to the discussion by deploying the software always generates new ideas and opinions.

That’s a good thing — as long as everyone is reasonable. I always listen carefully to everyone’s concerns and opinions. Most people simply want to be heard and understood.

5. Some people simply enjoy complaining.

Sadly, there’s nothing we can do about this latter group. Let them complain and always ask them for their ideas.

These issues don’t crop up every time but often enough to be troubling. Everyone is busy trying to operate their area of the business. Everyone has too many demands on their time. These issues will never go away entirely.

Welcome to the world of software application development. I don’t know what I want but I’m sure you can figure it out.

photo credit: Sybren A. Stüvel via photopin cc

Bulky, Legacy Programming Tools Cost Us More Than Money

Building great software has become too complex. I write many posts about the software development process and how to improve it but there’s an underlying problem. The art of writing software has become overly complex. That very complexity necessitates an overly complex approach to building it. It’s a vicious cycle.

It’s time to get back to basics. There are several software development environments that need to go. Having a diversity of software languages like C, C++, Fortran, Javascript, Pascal, PHP, Ruby, etc. is fine. Being forced to run a bloated operating environment to support the language is not.

We already run an operating system — usually Linux, OS X or Windows. We run a browser that is an operating environment in itself — such as Chrome, Firefox, Internet Explorer or Opera. So now we have a software environment within an operating system. Then, some vendors want us to run yet another environment that supports the programming language. Enough!

Here’s a short list of bloatware languages that need to go.

Adobe Flash

Flash is old technology. It’s widely used to deliver animation. Advertisers are probably the biggest fan boys of Flash. They can produce banner ads that grab attention and even interact with users. Alas, Flash is big, slow and full of security holes. It’s no longer needed as HTML5 can now take over its functions. It’s time for Flash to go.

Oracle Desktop Java

Java was originally a product of Sun Microsystems. It’s widely used in application and web servers as a way to process user requests and return meaningful results. It makes sense on servers. But, why do we need it on desktops? It’s huge and full of security holes. Some developers like it because they can build the software in Java and run it on any desktop computer. They need to learn HTML5 and an associated web-based language like Javascript, PHP or Ruby. Desktop Java needs to go.

Microsoft .NET

From a user perspective, .NET is horrible. Have you ever looked at the number of .NET “updates” Microsoft ships each month? Every major .NET release has it’s own set of updates. We are forced to install multiple versions of .NET on our systems to support different applications because Microsoft has designed it poorly. .NET replaced Visual Basic which was (arguably) one the best software languages ever. .NET is not progress. Kill it!

Microsoft Silverlight

Silverlight is Microsoft’s answer to Flash. Just what we need, right? Flash in Microsoft clothing. Even worse, Silverlight sits within .NET. It couldn’t be any bulkier! Silverlight has not caught on and never will. That shipped has sailed.

It’s time to move on.

These big, bulky software environments cause our desktop and laptop computers to slow to a crawl. They demand large amounts of memory and fast processors. In turn, these items add unnecessary cost to our systems and expose us to needless security risks.

Fight back! Avoid desktop applications and websites built using these obsolete tools — the software likely won’t run on your smartphone or tablet anyway.

photo credit: h.koppdelaney via photopin cc

Great Agile Teams are Adaptive and Resilient

This is the sixth and final post in a series about building great software using agile techniques. The series began here.

Many people, managers and developers alike, view agile development approaches like Scrum and Kanban as just another way to write software. Once they decide to try an agile approach, they quickly realize how wrong they are. Agile development isn’t about writing software. We assume you already know how to do that. Agile development is about delivering software.

I’d like to expand upon and summarize my original premises as follows:

1. Enterprise software development is complex and requires many skills. [Note: This series is not about small utilities or mobile apps. It's about software systems built and used by large groups.]
2. The agile manifesto is the definitive list of guiding principles and beliefs for agile development. [As such, it is a starting point, not an end game. We need more ideas.]
3. Agile development encompasses several approaches including Scrum, Kanban, Lean, XP, DSDM, FDD, BDD and others. [All are valid and applicable in appropriate situations.]
4. Applying agile development principles on an enterprise scale is much tougher than it looks. [Note: The Scrum of Scrums idea is merely a bandage.]
5. The hallmarks of truly agile teams are simple — they are adaptive and resilient.

What does it mean to be adaptive and resilient?

One of the key differentiators for agile developers is change. I’m not referring to accommodating user requests for changes to the software. That’s easy. I’m referring to changing the way the developers work. Changing the development process. Changing the very rules followed by the team.

Such changes need to be discussed, arbitrated and applied frequently — such as at the end of every sprint or cycle. If you’re looking for the ultimate, tried-and-true way to build software, look somewhere else. Agile development is about adapting to the current business situation.

If you develop software in a business that is changing rapidly or in an industry that is highly competitive, change will come at you fast. Your team must be able to learn and adapt continually. “Evolve or perish” is a good motto to adopt.

If your team is adaptive, there’s a good chance you can also be resilient. The terms are related though resiliency goes deeper. Resilient teams bounce back. They recover from adversity and find a way to succeed.

If you’ve worked on enterprise-scale software systems, you know that things will go wrong along the way — some things will go very wrong and cause near panic on the team. Resilient teams will swarm. They’ll apply their collective skills. They’ll change the rules. They’ll find a way to move forward.

The Attributes

To become adaptive and resilient, several attributes are essential:

• The team must be highly cohesive, loosely coupled and decentralized. [See this post.]
• They must implement constant feedback cycles and continuous improvement. [See this post.]
• They must exhibit rapid responsiveness and swarming behavior. [See this post.]
• They must have diverse skill sets and share a common vision. [See this post.]

Does your software development team have these attributes?

Would you describe your team as adaptive and resilient?

If not, what’s missing and what are you going to do about it?

I hope you found this series of posts interesting and thought-provoking. Whether you agree or not, I encourage you to leave a comment and expand the conversation.

photo credit: Seiya235 via photopin cc

Diverse Skills Need To Be Combined With a Common Vision

Great agile teams have diverse skill sets and share a common vision.

This is the fifth in a series of posts about building great software using agile techniques. The series started here.

If you read any books on agile software development, you’ll see references to multidisciplinary teams. That means the development team is largely self-contained. The developers have the ability to get the job done without excessive reliance on outsiders. Why is that important?

Enterprise organizations like specialization. They create many workgroups that focus on narrow areas of expertise. If anyone wants to do something covered by one of those specialized areas, they are required to issue a request to the appropriate workgroup.

For example, enterprise IT departments have database administration (DBA) groups. They include people who have the knowledge and authority to create and modify database structures. If anyone wants to create a new database or make changes to the structure of an existing one, they must request assistance from the DBAs.

There’s a good reason for that. If the enterprise has multiple systems relying on a database, changes have to be reviewed and coordinated. Making a change for one team could cause another team’s software to crash. Centralized control makes sense, right?

Until, the concept is taken too far. What’s too far?

• Applying the rule to every database even if it’s used exclusively by one software system.
• Applying the rule to development and QA environments, even if those environments are isolated (e.g. sandboxed).
• Applying the rule to every database change, no matter how small.

[I don't mean to single out DBAs for criticism. I'm merely using them as an example to make a point.]

Now imagine that there are several such specialized groups that every software development team must use. Each time they need assistance, they have to issue a request, enter a queue, and wait for availability. Does that seem agile to you?

Being Multidisciplinary Demands Vision

Agile software development teams have to be multidisciplinary by definition. They need team members who have multiple skills so that delays and wait times can be reduced or eliminated. They need an enterprise organization that gives them the independence to do whatever the team needs during the course of the project. Only then can real agility be achieved.

Having independence and using it wisely require that teams have a common vision. The team members have to work together with a shared purpose and a unified commitment. In this way, they’ll develop trust that, in turn, fosters collaboration. So through a common vision, the team will develop the strength to be independent and work as a unit.

Swarming won’t work without a common vision (see my last post). Even simple tactics like pair programming, will devolve into pair arguing without the joint commitment and shared ownership that derive from a common vision,

I’ve never said that enterprise software development is simple. While it’s fairly easy to be good, it’s difficult to be great and impossible to be perfect.

Is your team multidisciplinary?

Does your team share a common vision?

How would you characterize your team — good or great?

I’ll wrap up this series of posts on what it takes to be a great software development team in my next blog entry.

[The next post in this series is here.]

photo credit: chrismar via photopin cc

Agile Teams Swarm to Greatness

They are known for rapid responsiveness and swarming behavior.

This is the fourth in a series of posts about building great software using agile techniques. The series started here.

I’ve said before, “Plan less, deliver more.”

Others have said, “Stop starting and start finishing.”

Sounds crazy, right? How can your team deliver more software by doing less planning? How can they finish without starting? People who champion agile software development must be nuts!

Okay, these claims use exaggeration to make a point. Agile developers don’t sacrifice planning as a way to write more software. Nor do they skip project initiation activities and simply throw software over the wall into production. Let’s get serious.

The key point is a simple one. Agile teams respond rapidly. They quickly go from planning to designing to coding to testing to finishing. Then, they do it again — and they keep doing it until the software meets the goals defined by the stakeholders.

Don’t lose the excitement.

I’ve witnessed several cases where business stakeholders were excited by the prospect of a new software application. They cooperated in a lengthy discovery phase where requirements were gathered and documented. They grudgingly reviewed and approved hundreds of pages of documentation. Finally, they were told that the software would be delivered in six, nine or twelve months.

In every case, the stakeholders were disappointed and lost interest. In some cases, they sought out alternatives because the delay was simply too long. Business can’t wait.

Agile teams know that delivering something of value, early and often, is a critical success factor. They are fully aware of the need to respond rapidly both to the initial request and to the ongoing feedback after each delivery. Stakeholders need to experience the software not simply read about it. Incomplete software is okay. Nonexistent software is not.

Great teams swarm.

One technique agile teams use to respond rapidly is swarming. This is simply the act of coming together to solve a problem or get something done quickly. Great teams don’t point fingers at others or engage in blamestorming. They pull together and do whatever it takes to finish the current activities.

Swarming focuses energy at a critical area or key activity so it gets done. Most often, teams swarm when there is a mission-critical problem such as system or customer down. That’s fine though great teams use swarming as a planned activity. They recognize that difficult issues will be encountered during sprints and everyone will have to jump in and assist.

When you reduce the time spent on initial planning and designing, you have to anticipate that unforeseen issues and impediments will surface during the project. You could simply toss them into the backlog and worry about them later but your backlog could grow endlessly. Instead, great teams swarm. They try to resolve the issue or remove the impediment now. If they can’t, fine, move it to the backlog but only as a last resort.

Does your team respond rapidly?

Do you see swarming behavior in your organization?

If you answered no, greatness will elude you. Your team may be good, but it will never be great.

Swarming is a natural, instinctive behavior. It’s been observed in single-cell organisms, insects, wild animals and humans. Take advantage of it.

[The next post in this series is here.]

photo credit: gydnew via photopin cc

Even Great Teams Need to Get Better

Constant feedback cycles are the key ingredient to continuous improvement.

This is the third in a series of posts about building great software using agile techniques. The series started here.

Perhaps the biggest mistake software development teams make when adopting an agile approach like Scrum or Kanban is assuming they can lay out the perfect process from the start. They want to implement a set of rules or best practices ( …cringe… ) and get started.

It’s only natural. If your current development process is failing, you get excited about trying a new approach. You want to get it right. You want to succeed. That’s great! Enthusiasm is a wonderful trait.

… but …

Agile approaches to software development are not prescriptive. They don’t come with rule books. There are guidelines and recommendations but few “…you must do this…” or “…you can’t do that…” statements. A major part of being agile is the ability to adapt over time. The approach you choose will be simple in principle and must be adapted to your situation — once you get going.

Start somewhere, anywhere. Do something, anything. Learn and adapt as you go. That’s agility.

Approaches like Scrum and Kanban appear to be inherently simple. They are easy to learn and can be implemented quickly. You’ll need to add complexity as you adapt your chosen approach to your situation. The key is to get started with a simple model, then learn and adapt rapidly and continuously.

Agile teams must define a feedback loop. (Yes, that’s a rule!) They have to record everything. I don’t mean writing formal documentation for every activity. I simply mean informally gathering information that the team can discuss and use to improve their efforts. These feedback discussions need to happen often — usually at the end of each sprint (though I wouldn’t wait more than a month between them even if they occur in mid-sprint).

The best method we have for achieving good feedback and continuous improvement is the retrospective meeting. This may be one of the most under-used aspects of agile development. It’s not easy have an open and frank discussion with your teammates about what happened — why was a defect missed or how did a requirement get dropped — but it’s the best way to prevent adverse events from happening again.

I won’t go into detail on how to conduct retrospectives as much has already been written about the topic. Essentially, you want to ask questions like:

• What is going well?
• What isn’t going so well?
• What should we continue doing?
• What should we do more of?
• What should we do less of?
• What should we start doing?
• What should we stop doing?
• What should we track and measure?
• What can we stop tracking and measuring?
• Who can help us do better?
• What skills are we missing on the team?

You get the idea. Keep it simple and impersonal. Always keep Norm Kerth’s Retrospective Prime Directive in mind.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Today’s enterprise businesses change faster than ever. Even if it was possible to derive the perfect development approach for your team, in six months — twelve at the most — it will break. Don’t wait for your process to break. Keep learning and adapting.

[The next post in this series is here.]

photo credit: fish2000 via photopin cc

To Build Great Software, You Need a Great Organization

This is the second in a series of posts about building great software. The series started here.

In my last post, I introduced the idea that great agile teams exhibit a set of attributes that clearly distinguish them from legacy teams using waterfall approaches. Their techniques are also quite different from software teams who claim to practice agile software development but don’t. Here are the attributes I listed in that post:

• They are highly cohesive, loosely coupled and decentralized.
• They implement constant feedback cycles and continuous improvement.
• They are known for rapid responsiveness and swarming behavior.
• They have diverse skill sets and share a common vision.

This post focuses on the first entry on the list — They are highly cohesive, loosely coupled and decentralized. What does that mean? Let’s break it apart.

Highly Cohesive

In simple terms, a cohesive team is one that is closely united. The team members stick together. Their activities are logically consistent and supportive of one another.

These characteristics can’t be fully developed during the course of a single software release cycle — for example, 3-4 months. It takes time for great teams to “gel”. It’s not easy. Some companies fail at agile software development simply because they expect too much, too soon. Invest in training and coaching, and give it time.

Loosely Coupled

Great software teams are able to split large chunks of work (often called “epics”) into smaller elements (“stories”) and deliver working software iteratively and incrementally. They don’t rely upon a single individual to fully define or implement a major system capability. Anyone can select a portion of the system and work on it.

This doesn’t mean that everyone on the team needs to know everything. Refer back to “highly cohesive”. Team members help each other and accomplish their tasks collaboratively.

Decentralized

This term is self-explanatory and one of the most difficult attributes for enterprise organizations to implement. Enterprise managers are measured by their ability to control and execute. There is usually an expectation that every decision the team made — everything the team did — was pre-approved by a manager. If the team succeeds, it’s because of the manager. If the team fails, the manager takes the heat. If you were a manager in that situation, how would you handle it?

Great managers lead. They do not control. Great managers do not make all the team decisions. They do not approve everything. They most certainly do not make everyone wait while they “think about” the situation.

Great organizations decentralize. That does not mean that software development teams are allowed to run wild and do whatever they want. No! Great organizations enable their managers to lead. They establish goals. They offer guidance. They monitor and measure. They remove impediments.

How does your software development team measure up?

Is your team highly cohesive in your opinion?

Is your team loosely coupled?

Is your organization decentralized?

If you answered “no” to any of these questions, implementing Scrum, Kanban or any agile approach will be difficult. You are likely to end up with some form of iterative (or incremental) waterfall. That’s not a bad thing but it’s neither agile nor adaptive.

I’ll continue this discussion in my next post. In the meantime, please join the conversation.

[The next post in this series is here.]

photo credit: Rebecca-Lee via photopin cc

If We’re Not Agile Developers What Are We?

There are many Internet debates about what agile software development really is. Unfortunately, the term “agile” is misleading. The dictionary lets us down with definitions like “move quickly” or “think quickly”. Synonyms for agile lead us to fleet, graceful, nimble, spry or supple. Do any of those terms describe how your development team operates?

Agile development teams shouldn’t focus on being quick or nimble. They should focus on building great software. There’s a big difference between: 1) getting an entire software system completed quickly; and 2) delivering great software on a frequent, incremental basis.

Number 1 is about getting the software out the door as soon as possible with whatever compromises need to be made. Number 2 is about building what the customer wants in a high-quality fashion.

Every situation is unique.

There are circumstances where #1 is the right approach. For example, your company may desperately need to respond to a competitive threat. The company may need to demonstrate a new capability right now or risk losing market share. Forget the rules. Just get it done or jobs will be lost.

If we are doing our jobs well, situations like the above will be rare — not non-existent, but rare. More commonly, software developers will have a set of goals and a workable timeframe. I define “workable timeframe” as one with enough duration to accomplish a lot of great work but not necessarily enough time to achieve all of the desired goals. Compromise is always needed.

Making matters more confusing, agile is an umbrella term covering multiple development approaches including Scrum, Kanban, Lean, XP and others. Agile software development is a set of beliefs that influence and guide specific approaches like Scrum and Kanban. It is not a prescribed methodology.

Being agile is harder than it looks.

Enterprise software development is a complex and labor-intensive effort requiring many skills and multiple teams. Let’s agree that no single word can capture the essence of what we want enterprise software development to be. It’s just too complicated.

So, if the word agile doesn’t adequately describe what we want software development to be, what does?

We must recognize that developing software with agility is an enterprise-wide endeavor. Software developers cannot be agile if the corporate environment is rigid and prescriptive. With that in mind, I believe there are several key words and phrases that distinguish agile organizations:

• They are highly cohesive, loosely coupled and decentralized.
• They implement constant feedback cycles and continuous improvement.
• They are known for rapid responsiveness and swarming behavior.
• They have diverse skill sets and share a common vision.

I also like what Anders said yesterday, “…the ability and willingness to learn by experience and failure is the most important item on the path to becoming agile.” I’ll address learning by discussing actions organizations can take to facilitate learning.

It takes all of the above to fully-practice agile software development. Simply having daily standup meetings does not mean you are practicing Scrum. Simply using sticky notes on a wall to track tasks does not mean you are practicing Kanban. Simply testing the software iteratively rather than waiting until the final project phase does not make you agile.

It’s time for a more rigorous and structured definition of enterprise agile software development. Over the next several posts on this blog, I’ll offer my ideas and opinions. I hope others will join in whether they agree or not.

[The next post in this series is here.]

photo credit: Sagolla via photopin cc

Agility Depends on Your Ability to Learn

Guest Blog

I’m pleased to have Anders Ingerstedt, founding partner of Colabpro Outsourcing Ltd, as a guest blogger today.

Agile is a buzzword. It is replicating and spreading into new domains beyond technology and software development, where it originated. Agility is — no denials accepted — a good capacity in any corporate environment, as it depends upon learning. Firms struggle to be more agile in every sense powered by a rapidly changing business landscape.

What was the truth six months ago may not be truth today. As small firms encounter global competition, no idea, concept or patent is a safe path to win the favour of customers. The dynamics of the free flow of information, available in every corner of the earth, requires new approaches and new standards. It is all about learning and agility.

Where It All Began

Lean manufacturing is a concept widely accepted and implemented in competitive manufacturing companies of today. Without principles from Kanban, for example, just-in-time systems would not exist. Kanban is an agile technique that can be used in more circumstances than just manufacturing. It proves that agile thinking and principles have merit.

“Agile” is a word that has become associated with technology development, specifically software, and has become confined to that environment. That is a big mistake and I will try to explain why.

In software development, stakeholders learned that they rarely got what they needed, back in the 1980’s. As a result, driven managers started to reorganise priorities, often clashing with corporate hierarchies. They focused on the most important items needed to satisfy the customer. That approach turned into a practice called “prototyping” and included frequent demonstrations of the product. This enabled the customer to influence the developers and the product. Learning was enabled and the final result improved.

Software development is performed by highly capable and intelligent individuals, who know what to do. They are aware of corporate goals and customer needs. The complexity of software development and the urge to deliver useful applications drove a group of engineers to define, document and develop practices that help to overcome the complex demands of adaptability in a rapidly changing landscape.

Where Are We Now

That was 20 years ago. The corporate challenge to adapt to the dynamics of a changing landscape has not been met in any sense. Processes and documentation are prevailing institutions in any enterprise, and it is clear to me that they are losing. The reasons are the inability to learn from the past that is embedded in strictly described process thinking.

By the thousands and increasing, new firms are developing with new ideas, challenging every aspect of the established corporate market. What was a safe market share yesterday is not so today. The new information sources made available to customers disrupt old patterns and put the customer in the centre, not the shareholder. This is a major shift — now evident — smaller firms have a built-in learning capability.

Big firms who rely on established thinking are less able to learn since it is one of the purposes of establishing a process. Furthermore, separate processes are commonly established to provide the learning and thus censor the real experience, effectively preventing any useful feedback. Thus, adaptation to quick changes in market conditions will not be reflected.

Agile as the term in software development is growing rapidly outside of technology and the new CIOs understand that agility is necessary to create competitive product solutions that are more attractive to customers than the basic engineered offerings. Firms like SKF, Atlas Copco and Sandvik, promote their products with apps available on a tablet. The next step is integration with the hardware they produce. Clients are increasingly looking for solutions and less for items.

The answer to this demand is software. Almost everything sold today has a component of information technology in it, and that component will not decrease. The ability to learn and adapt to new settings requires an agile mind-set — a learning mind-set.

Software development is a complex process, and as such it has evolved over 40 years into orders that help to simplify and improve, by learning. The practices established over the past decades prove that complex processes can be managed to success.

I believe some of the most profound impacts of not being able to learn are shown by firms like:

• HP
• Kodak
• Microsoft
• Nokia

They are stagnating companies, struggling with learning about new market conditions and seemingly unable to learn and adapt. The list can be made much longer.

Agility is not a state, it’s a mind-set.

Upspring challengers to corporate giants are very agile today. They use completely different approaches in terms of supply chain, administration, manufacturing, strategy and corporate culture.

These companies hire the team players they believe can learn, not the MBAs who believe they know everything already. These companies believe in the capacity of the empowered individual together with accountability, not the theoretical credentials that assume capability. Ability and willingness to learn are becoming much more important, as is the corporate culture of allowing for failure.

I argue that the ability and willingness to learn by experience and failure is the most important item on the path to becoming agile. The willingness to accept failure as a way of learning, the breakup from strict process controlled behaviour, the power to try and fail and then try again, and succeed — that is agile.

Please visit Anders’ blogs to read more of his thought-provoking articles.

‘Learn’ photo credit: Mark Brannan via photopin cc