Software Development Today

Wednesday, March 05, 2014

We want to make Agile Finland even better, who wants to join? A platform for 2014-2015


The ideas below reflect the discussions we (Maaret Pyhajärvi, Martin von Weissenberg, Vasco Duarte) have had while reflecting on our Visions for Agile Finland. We hope these ideas are discussed and developed within the Agile community in Finland, and end up in a set of actions for the Agile Finland Executive Committee 2014-2015. We also commit to present ourselves as candidates for the Agile Finland executive committee in the next Annual Fannual meeting and are open to you joining our group to be part of the next executive committee.

If you share our ideas, get in touch and join us for the Agile Finland board. If you don’t share our ideas, please join the debate! Publish your ideas, volunteer for the next Agile Finland board on your own or as part of our list. Our goal is to spark debate and ensure we will have a strong group of committed individuals to continue the work that we feel Agile Finland needs to complete.

Read our ideas below, and let us know what you think.

Community services

Agile Finland needs to take a role in the progress of software industry in Finland. One way in which we can do that is by cooperating more closely with the companies that identify themselves as Agile companies, both consulting and product/service production.

We want Agile Finland to be a platform for all members of the Finnish Agile Community, be they individuals or other organizations (for profit or not). As an example of this cooperation, we want to establish a yearly market research process financed by Agile Finland that would deliver a yearly “state of Agile in Finland report” and distribute it to the companies in the Agile community as well as to the media and individual Agile Finland members. This report can include topics such as:

  • Market size for Agile contracts
  • Market size for Agile software development (revenues, number of jobs, etc.)
  • Key trends from the Agile market in Finland (topics of interest, business models, etc.)
The full list of topics to cover is to be decided by the group that will create the report.

Sponsorship and funding for Agile Finland

Over the past years, conferences (especially Scan Agile) have been a major funding component for Agile Finland. We want to propose some changes in this respect. We recognize that it is today unclear for Sponsors to know which events to participate in as sponsors. If you support Tampere Goes Agile does it make sense to support another major conference like Scan Agile? How about conferences that happen at similar times? Which one to choose?

We find these choices confuse sponsors and do not adequately serve our present Agile Finland members either. Therefore we propose a change in model for 2014-2015. We propose that companies interested in sponsoring Agile Finland be able to sponsor the whole year of events (several major events are held by Agile Finland every year) and be allowed to choose which ones they participate in. For example, if Company A purchases a yearly sponsorship from Agile Finland they could be features in Scan Agile, Tampere Goes Agile and local events that will happen during the year.

Alternatively, companies could still purchase sponsorship packages for specific events just like they did until now.

Additionally we want to propose a change in the Agile Finland bylaws to allow corporate membership. This membership would allow companies to have access to services such as market research, recruiting communication and other services that Agile Finland may want to develop in support of the Agile business community.

Sponsoring local events

Agile Finland wants to support local Agile communities around Finland, therefore we will commit a minimum amount of money to self-organized community events. All that is needed is a request to the board and the funding will be approved provided we stay within the agreed limit. If you have an idea to support your local community we want to help you without a long wait for either practical or financial support. We want to help local communities get more active, and our support (advertising and financial support) will make it easier.

Developing a future for the Finnish software industry

In 2014-2015 we want to start what we hope will become a trend for the future of our industry. We want to support events designed to support future professionals get familiar with what it means to work in a software organization. For that we will organize events with school-age children on topics such as what the “maker” community already supports all over the world. Creating projects that young Agilists could work on, from concept to execution. But we will also try to grow partnerships with student organizations, universities and companies to have a mentorship program started to help integrate students in the software industry easily.

Major events for 2014-2015

Events such as Turku Agile Day (which we want to support actively), Tampere Goes Agile and Scan Agile are events that attract a large audience and spreads knowledge and awareness of Agile within our community, but also helps establish strong links to other communities.

We want to continue to host and these events but also recognize that a voluntary-only approach has risks that must be tackled. We will consider how to support these events on a case-by-case basis and will work to make their organization a sustainable project that does not require heroic efforts from some of our members every year.

We recognize that each event has their own identity and we want to support that diversity.

As first actions we will:
  • Reach out to the Turku Agile Day group and learn how we can further support their goals;
  • Help find voluntaries to help host Tampere Goes Agile and Scan Agile;
  • Work with each event to make sure they receive the support needed, including professional services for event organization, design, web-hosting, etc.

Do you want to help shape the next year for Agile Finland? Participate by sharing this blog, commenting or tweeting/blogging about the topic yourself! Be active, let's make Agile Finland even better!

Labels: , , , , , , ,

at 13:06 | 1 comments links to this post
RSS link

Bookmark and Share

Tuesday, February 04, 2014

Management science's impossible quest: in search of predictability


Many years ago some people came up with a brilliant idea: "what if, we could turn abundant lead (Pb on the table of elements) into scarce gold?". A brilliant idea to be sure, but as we know now, impossible. What made Alchemy grow and thrive as a science, was that people at that time did not know that it was impossible. They did not have enough knowledge of chemistry to know that you cannot turn an element's atom into another element's atom. That did not stop them however! And thanks to those crazy idealists today we have Chemistry. How about that for a twist of fate?

Alchemy's history can be traced back for millennia, and that name stands as the prototypical failed science (except for poets and … idealists). Failed because it based its existence on a belief that was impossible to make reality in our world.

I find many parallels between Alchemy and Management science today. Alchemy wanted to find the magic Philosopher's Stone that could turn led into gold, Management scientists are in a similar quest: in search of the method that can make management succeed as a science. Management science's goal today is to find the magic ingredient that can give us predictability.

Basic Science

Many management-fads are based on the hypothesis that you can control the world around you, mold it in a way that can give you predictability. This (mythical) predictability is a core assumption that enables the management's idea of success: I will do X so that I can achieve Y and therefore succeed.

This predictability is, however, a form of causality. Many, perhaps including you, will not think of it that way, but predictability is only present in systems where you can determine causality. A predictable world is one where we can reliably predict what happens when we do X, i.e. a world where we can establish causality.

Newton's laws gave us predictability in the physical macroscopic world of objects, because they told us what would happen if, for example, you rolled a sphere in an inclined plane, or shot a bullet from a canon, or shot an arrow with a bow. Relativity theory gave us predictability (to a certain extent) in the microscopic world of atoms, or sub-atomic particles also because it established useful and applicable causality rules

Medicine gives us (mostly) predictability in the world of diseases and biologic systems like the human body because it has a system of studying and documenting causality: if you take Aspirin after a great Saturday night party, you will feel milder effects of the oncoming hangover.

You can see why management theorists (and practitioners) would want to achieve the same goal: predictability.

Predictability is management science's Philosopher's stone.

The Philosopher's stone

Planning is one of those attempts at achieving predictability. We plan, because we believe that planning will give us the predictability we seek. Without the goal of predictability we would not plan, there would be no point.

But planning itself rests on the assumption that we can predict (here it comes again) causality in the world where the plan is to be executed. If we did not believe that we could predict B to happen after doing A, then planning would not be possible. It would be illogical.

We plan to be able to predict, but plans only work if we can predict in the first place!

The problem with what is stated above is that it is a circular dependency: we plan to be able to predict, but the act of planing rests on the assumption that the world is predictable. You see where this is going, right?

The sad fact is that there are many other management techniques that both rest on, and try to achieve predictability. For example: pay for performance, management by objectives, or the yearly strategic plan.

Going around in circles

All these management techniques have one thing in common. They are static. They exist at a precise point in time: Strategy is defined in the Spring or Autumn and is supposed to be executed for the next 12, 18, 24 or more months. Objectives or goals upon which our evaluation is based are set several months in advance of the point of evaluation.

All these techniques require perfect, 20/20 foresight. How likely is that?

The basic problem with most perspectives on management today is that they are static analyses of a future environment. And all decisions are made because we believe we can predict the future.

We make these predictions to help our businesses be more predictable, but our predictions depend on our business being predictable. This circular dependency is why most management approaches are doomed to failure. Like Alchemy.

Looking forward

We need a new Management Science, one that does not require the existence of a predictable world. When it defines goals, it does so in a way that is dynamic, i.e. the goals change with the observation of reality. This dynamic adaptation process is what we, in the Agile community, call a feedback loop.

A future-proof management approach must start by basing it's core assumptions on the existence of feedback loops that must be studied and tested as we make decisions. And these feedback loops must be the driving factors for action in management. Not the plans!

How would such a management approach look like?

The first assumption of such a management approach must be that the world is not predictable beyond a very short time. This may be a simple statement, but the consequences of this simple statement are fundamental.

  • First, management techniques must not be based on the existence of a perfect, predictable future. Management techniques must be based on the acknowledgement that we cannot predict what is the best (or worst) possible outcome of our actions. What good is it to plan to sell 100 widgets when the market is - unexpectedly - demanding us to produce 1000 widgets? or 10 widgets?
  • Second, management techniques must be designed to include feedback loops that inform action. Not just as information collection loops, but as fundamental action-defining loops. For example: every single decision is temporary. Every decision must state it's assumptions and when one assumption is proven wrong, the decision must be reverted or at a minimum re-evaluated. When we execute our plans, we must be alert to surprises; without detailing our assumptions we can never be surprised. Surprises are triggers for action - no surprises, no learning, no adaptation.
  • Third, an individual's performance cannot be predicted up front. This tells us that we can only evaluate an individual's performance after we have the facts of what happened. Maybe a sales person failed to meet their sales target, but that could be because they helped R&D get the first pilot customers for an entirely new business!

What would your world look like if you believed and followed the three principles above? How would it differ from your current perspective on management?

Image credit: John Hammink, follow him on twitter.

Labels: , , , , , , , ,

at 07:30 | 4 comments links to this post
RSS link

Bookmark and Share

Wednesday, January 29, 2014

Fractals, why all your attempts at scaling Agile are doomed to fail! (But not yet how to solve it)


It is no secret that I love planning. I'm not coming out of the closet now, that's been true forever! And at some point in my life I was even "cool" with that.

Additionally, I want you to know (although you will not yet understand why) that I still love planning. That's me :) Now pay attention, I'm about to shoot myself in the foot.

Loading the gun

When I was in college there was a topic that I loved, the topic was Information Theory. There's so much stuff in that area of research that I can't even begin to touch the tip of the proverbial iceberg, so I'll just say - for now - that information theory is an area of research that investigates information and how it is codified. For example: how do I compress a text file? Turns out, text can be very efficiently compressed. Perhaps the blog post you are reading can be codified in a few hundred bytes. The cool thing is why that happens: redundancy. Redundancy is an unappreciated quality of all systems.

So unappreciated in fact, that we all praise it's mirror twin: efficiency. A compressed text file is very efficient (i.e. it codifies a lot of information in a very small amount of disk space - I could probably compress this post into 140 bytes and tweet it out - that would be efficient).

If we can create so efficient representation of information why would we stick the old-skool inefficient representation (for example: language)? I'm glad you ask! The reason is that language with all its redundancy is easy to understand even if you cut parts out or mangle the letters. Try reading the following paragraph (click for a larger version):

Did you understand what that said? Of course you did! Redundancy saves the day! Yay!

Now about software and organizations

In organizations and companies, we also have redundancy - plenty of it! And just as well, because without it most companies and organizations would stop working altogether. Redundancy gives us resilience! Just like in the language example above: even with parts of the words cut out of the phrase you were able to understand it! And this is just how organizations work: through, and thanks to, redundancy. This is the reason why some "downsizing" efforts end up killing whole companies, and the often touted "efficiencies" or "synergies" leaders try to gain from mergers and acquisitions end up destroying economic value more often than they create.

The trick with redundancy is to repeat

By now you probably agree that redundancy is good - and it is. But how do you apply it to your organization and processes?

Before we go there, we have to tackle a very neat concept of mathematics. Fractals. Fractals have a property that is mind-boggling. Fractals are concepts that once explored end up generating infinite (yes, infinite!) information. In fact, a fractal line has infinite length even while fitting in a finite space! I won't bore you with the math details, but check this page on Wikipedia about the length of the British coast line - it has a neat demonstration of how a finite space can hold a line of infinite length.

This means that fractals are generative when it comes to information: they generate infinite amounts of information. And this happens to be a very useful property to have in mind when we explore how organizations work.

Making the case for infinity (and beyond)

In this post I argued that removing rules from your company's process book is actually better for your business and for your teams. The next step is to remove as many rules as you can, so that you end up with a small and simple set of generative rules - just like a fractal. Fractals are very simple equations that have in themselves an infinite number of solutions. And that's exactly what our processes should be: a small set of rules that, once in use, accommodate an infinite amount of possible behaviors - this is what I mean by "complex behavior" in the post on disciplined organizations.

Conclusion

Turns out fractals are perfect (yes, perfect - as in perfectly efficient) compression algorithms: a simple equation can be solved in an infinite number of ways, which when plotted in 2D or even 3D generate an infinite line in a finite space.

This property is extremely useful when applied to processes in your company because you cannot predict how people should behave in the future, but you can create an environment that - just like a fractal - allows every actor / person in the company to act in an infinite (and therefore practically unpredictable) number of ways and adapt to whatever the ever changing reality throws at them.

If you believe that your business environment is constantly changing, and that your organization is akin to a living organism you have to embrace the concept of fractal organizations.

Fractals work for you when they allow your blood vessels to reach every cell of your body (within a few cells distance), and when they allow your brain to store vast quantities of information even if it is small enough to fit in your head. Fractal organizations are organizations that can adapt in an infinite number of ways in response to an unpredictable environment.

If change is the only constant, how do I adapt to that?

Epilogue

Before we can understand how to apply the concept of fractal organizations and benefit from that, a very serious question must be answered: If people can behave in infinitely different ways, how do we prevent organizations from turning into chaos? That's a question we will explore soon - stay tuned! :)

Title image credit: John Hammink, follow him on twitter.

Labels: , , , , , , , , , ,

at 07:30 | 0 comments links to this post
RSS link

Bookmark and Share

Tuesday, January 21, 2014

Hire generalists to help your specialists shine!


Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in the world. No need, right? Wrong! Here's why.

Forget common-sense

The comment above is designed to sound counter-intuitive. The reason for that is that most of this post is counter-intuitive. I'll argue that one of the basic premises behind software project management are purely and simply wrong. This one specifically, is ultra-wrong: specialists in a software project (even a niche one) should be the majority of the team. The "favor specialists" heuristic says things like: "don't hire a Ruby programmer to a Java project", "hire only people who've done financial systems to that high-frequency trading platform", etc. You get the picture.

What is the reason for this "favor specialists" heuristic? Why did it arise? The most obvious reason is that we want to hire people that "know what they are doing", and in our functional definition of software projects that means: "people who have done that one thing before". And who could argue with that? Right?

What if we looked at projects like systems, complex systems that incorporate technical and social aspects that are very hard to control or manage? In this case we would be compelled to question the "favor specialists" heuristics, because we would look at a project as much more than a technical endeavor. We would look at projects as being social and technical endeavors.

Social is complex

Social systems have many more dynamics in place than "what is the best technical solution? How do we select from competing technical solutions? What skills should we hire for?"
Social systems change rapidly (whether you like it or not), and they require a different set of assumptions about what is the best project team composition and organization. For example - the point of this post - it requires us to question the ratio of generalists to specialists.
In the last post I talked about Emergence. I explained that system behavior is affected by many unpredictable dynamics and that simple rules favor adaptable behavior in projects. I also said that a long list of complicated rules will remove adaptability from the project team. The heuristic I described in that post is: "complex rules emerge stupid behavior."

Emergence is favored by and favors generalists

I believe all projects are social complex systems. Yes, even two people projects (those, probably even more than larger projects. Think of the rule set on a 2 people project!). These social complex systems perform better when there are only a few and simple rules. They benefit from constant change (see here how to do that so that it does not kill you). Social complex systems are environments where generalists excel! Here's why:

  • generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages;
  • generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
  • and there are many more, let me know which you have found in your experience by leaving a comment.

Improve performance by adding generalists to your project

I propose that we start designing our projects based on a different heuristic: "favor generalists". This means that we will try to seed all teams with generalists, people who know their trade but are not invested in only one particular technical solution or process.

For Developers this means that all developers should be encouraged to learn several programming languages, work in different problems during their employment, and that we don't hire people just because they've solved the same problem in the past.

For Testers this means that we hire people that can do manual and automated testing (maybe more on than the other, but both), that know different technologies, that understand social aspects (users) and technical aspects of software development (e.g. math).

For Product Managers this means that we hire people that have worked in other industries, other types of products or even in non-software only products.

If you believe, like I do, that software projects are social complex systems, then you must not favor specialists. Hire and groom specialists but seed all teams with generalists, sit back and enjoy the higher performance.

Picture credit: John Hammink, follow him on twitter.

Labels: , , , , , , , ,

at 08:30 | 1 comments links to this post
RSS link

Bookmark and Share

Tuesday, January 14, 2014

The simple recipe for disciplined organizations


One question puzzles non-Agilists more than any other question. It is the question that uncovers why Agile does not fit their view of the world. A question that makes non-Agilists feel insecure and reject Agile completely or mostly. This question is: how can less structure, and less planning deliver software more reliably, and with higher quality, and faster, and with better usability, and with better customer satisfaction?

Do you know the answer to this question? Many Agilists don't. Here's one attempt at answering that question.

Agile is different

Those of us that have been practicing Agile for a while have learned to "break the rules" - or reach the Ha or Ri levels in the Shu-Ha-Ri model. We've practiced, and practiced, and practiced. We've learned what works (some times) and what does not work (most of the time), and we have been able to hone our practice to a point where Agile just feels "natural". But what is "normal"? How would you, a Ha or Ri level practitioner of Agile define Agile?

This reminds me of a story I heard from Angel Medinilla, a dear friend and fellow Agile journeyman:

In a dojo somewhere in a southern country, the Aikido apprentice reaches out to the sensei to understand the secret of Aikido.

Aikido apprentice: Sensei, what is the secret of Aikido?
Sensei: The secret is to breath, to balance, to connect with your opponent and whole body movement.

The apprentice was frustrated, he was expecting something enlightened and concrete for him to use.
Then, after 40 years of practice the apprentice finally says to his sensei:

Apprentice: Sensei, finally I understand the secret of Aikido
Sensei: Good. So, what is it?
Apprentice: It was simple and in front of my eyes all along. The secret is to breath, to balance, to connect with your opponent and whole body movement.

The sensei in that story knew that the apprentice would eventually come to realize that Aikido was indeed "just" to breath, to balance, connecting with the opponent and whole body movement. So, how about Agile, what is Agile all about? And how does it deliver more discipline, with less rules?

Chaos is very disciplined

While I tried to make sense of Agile, I explored many possible models. One of them was Chaos Theory. As I explored the Theory of Chaos I found a very interesting video about one of the favorite topics in the Agile community: emergence. Emergence is the process by which a system (any system) organizes itself based on real rules and exhibits what we would call complex behavior. For example, in this post I explained how a colony of Ants can exhibit complex behavior by following just a few rules. That complex, adaptive behavior emerges from the rules, and the action of the individuals. The rules are real (there is a benefit in following them), and the resulting behavior is complex and adaptable but also, very very disciplined (because there is a benefit to that discipline, you follow it or you die of hunger).

Going back in time

The counter-intuitive aspect of emergence is that it goes against all accepted "truths" about organizational design. You see, emergence can not be explained by reducing our model of the system to simply modeling of the agents' independent behaviors. Emergence is a result of all the parts interacting in the system. If you remove one of the rules from the ant colony you would get something different (possibly even the break down of the whole colony).

Simple rules lead to complex behavior. Complex rules lead to stupid behavior.
--adapted from original quote by Dee Hock

Reductionism is the most common process for organization design used by humans today. We tend to start by modeling small independent parts, and when we are satisfied with each, we put them together. But there's a problem with that approach. When you try to design an organization, or a process, by first identifying all the necessary steps individually, and then you sequence them orderly you make the system stupid. Or, in other words, you create rules that remove the possibility for complex, adaptive behavior to emerge.

This process or analyzing, ordering, prescribing organizational and process design is labeled analytic, and it is based on the theory that if you break something apart (like the organization), and analyze those parts independently you will understand it sufficiently enough to know how the whole system works. The problem is that an organization, like any system, has dynamics that can only be seen when all the parts are assembled and never when they are analyzed separately.

By contrast, if we define clear and simple rules (think the rules of chess) and nothing else, we are allowing the system to - through emergence - exhibit complex, adaptive behavior. The big question comes next: where do you draw the line between simple rules that allow for complex behavior to emerge, and the analytic process? When do we cross from one to the other?

Drawing a line in the sand

This is not an easy question to answer, and it is highly context dependent. However, I have found that the moment you think of rules that apply to single agents in a system you are approaching that line (and possibly crossing it). For example: when you have specific rules for every type of agent in the system you are designing through a process of Analytic Reduction. Like when you have specific rules for Project Managers to follow; you have specific rules for Developers follow; you have specific rules for Testers to follow; etc. ad infinitum.

A heuristic that I have found useful is to remove rules whenever possible. Scrum, for example, does this by assigning no special role to any team member, but instead giving the team a set of simple rules and boundaries (timeboxed iterations, interaction with PO, Definition of Done, etc.)

This realization led me to understand the critical role that generalists play in facilitating complex adaptive behavior (but that will have to wait for a later post).

Conclusion

Complex adaptive behavior emerges in systems where the rules are simple, and the agents have a high degree of freedom to make decisions. By trying to analyze systems with an reductionist process we are removing the possibility for agents (us, the people) to make intelligent decisions based on their context, and therefore we are reducing the possibility for complex adaptive behavior to emerge. The analytical mindset kills emergence. But more importantly, when it comes to performance Emergence kicks Reductionism in the groin.

If you tell people where to go, but not how to get there, you'll be amazed at the results. - George S. Patton

Next time you are designing a process or an organization take this into account and remove as many rules as you can. That will help you achieve more! Define the goals and let the people surprise you with their results!

Photo credit: John Hammink, follow him on twitter

Labels: , , , , , , , , ,

at 08:00 | 6 comments links to this post
RSS link

Bookmark and Share

Tuesday, January 07, 2014

How injecting randomness into your project can help it succeed


Success and failure differ, very often, by very little. Take nature as an example. A small change in our DNA (a few mutated genes) can have catastrophic consequences. On the other hand, without these mutations humans would never have come into existence.

Humans and other species in the planet evolved because of chance (although not totally chaotic) changes in their DNA. As small change after small change happened, the surviving individuals were able to spread the viable, and ultimately the most adequate changes to the next generation - and the process repeats still in our own bodies today. If Nature has taught us something about improvement and evolution is that you must have a little bit of luck involved!

The DNA of a project

In software projects - my domain - I see some similarities to this natural model that are worth exploring. Projects also have a DNA which includes the structure and the communication connections between individuals. Communication being one of the most quoted causes for failure in software projects, and therefore one of its critical success factors.

The More I Practice the Luckier I Get

Once a project gets started, a particular structure is put in place (governance, management, teams, etc.). Very often that structure remains in place, and static until the end of the project. But is this a smart choice?

Another aspect of the project that rarely changes is the network of connections between the individuals. This network is what carries information from individual to individual and eventually "selects" the information that is acted upon by the project team. If a piece of information reaches an individual in the project, and that individual does not consider it relevant, that information will not spread further. In contrast, when a piece of information is perceived as important by an individual, that information will be actively spread by that individual.

The Illusion of Control

The structure that is set for a project strongly influences the communication links that can emerge between individuals. Who talks to whom? What meetings exist where people interact regularly? etc. But the reverse is also true. The existing communication network within an organization is a strong influence on what governance structure is put in place, how teams are formed, etc. These co-dependent processes create a positive (or negative) spiral of events for the project, but because neither (structure, or communication network) is often changed, that spiral is unstoppable. If it is positive, it will help the project succeed. If this co-dependent processes create, instead a negative spiral, that will relentlessly remove the chances of success for that project.

This co-dependent relation between two key processes (structure and communication network) is why we can increase the chances of success in our projects by simply causing random perturbations in the project. Randomness helps us explore different patterns for structure and communication networks.

As we carefully design and inject small - safe-to-fail - changes into the project, we can observe how it reacts and adjusts. Later, we can retrospectively amplify or remove/dampen the changes based on the outcome we see. If something works, keep it and ask how can you make it grow. If something creates a net negative outcome, dampen or remove it completely.

The cycle goes like this:

  • Define and implement small, safe-to-fail changes in the structure or communication network for the project
  • These changes lead to emergent behavior as the individuals and teams adapt to the changes
  • A new project configuration emerges which drives new project results
  • Finally, we evaluate the results of these changes and decide which components we will try to amplify or dampen

What Do You Mean Random?

There are many ways in which we can, randomly, explore better configurations for our projects. Below I list only a few to illustrate the concept:

  • At the start of a project, let the teams chose their own composition. This establishes new connections between individuals in the project as some will choose to work with new team members. However, these new connections will not eliminate the previous connections between individuals. The net effect should be that your project now has a more connected communication network (more individuals with strong connections to each other). In practice this works just like when we form new neural connections in our brain: more connections leads to different thinking and acting patterns
  • Organize common project events where people interact with each other outside the day-to-day routine. Planning events can be organized following a structured approach, but including also some unstructured time (à lá unconference, using e.g. Open Space) where people can interact based on their interests. This will also help form new connections between individuals in the project and spread information that would otherwise be locked down and not accessible
  • Have regular project "coffee breaks" that happen at the same time and same place. In these events people can connect with other individuals and ask questions from the project management team or the most connected individuals in the project. This unstructured communication increases the chance that some piece of information will "jump the hierarchical borders" and reach people in decision-making positions, or people with influence that can later act on that information.

Conclusion

These practices are designed to inject randomness (unplanned situations or connections) into the project. The goal is not to create Chaos (a scary word for many project teams), but to generate new pathways for the information to flow within the project team, as well as novel project structures that are more adapted to the current challenges the teams face.

Using these (or other) practices will increase your project's chances for success. They don't eliminate the need for the project to be managed, or to have structure. They do increase the chance of success for the project by exploring new organizations and structures through a process of small (safe-to-fail) changes that can lead to unplanned, but ultimately superior performance.

These were just a few examples. How would you inject randomness into your project? Have you done that in the past? Please share your experiences in the comments for the benefit of others.

Photo credit: John Hammink, follow him on twitter

Labels: , , , , , , , , , , ,

at 08:00 | 8 comments links to this post
RSS link

Bookmark and Share

Friday, January 03, 2014

Why projects fail, is why (we think) they succeed!


When I started my career as a Project Manager, I too was convinced that following a plan was a mandatory requirement for project success. As I tried to manage my first projects, my emphasis was on making sure that the plan was known, understood and then followed by everyone involved.

When I started my career as a Project Manager, I too was convinced that following a plan was a mandatory requirement for project success

I wrote down all the work packages needed, and discussed with the teams involved when those work packages could be worked on, and completed. I checked that all the dependencies were clear, and that we did not have delays in the critical path (the linear path through a project plan that has no buffer).

I made sure that everyone knew what to do, to the point that I even started using daily meetings before I heard of Scrum which would, later on, institutionalize that practice in many software organizations.

As my projects succeeded, I was more and more convinced that the Great Plan was the cause for their success.

As my projects succeeded, I was more and more convinced that the Great Plan was the cause for their success. The better the plan the more likely the project would succeed - I thought. And I was good at planning!

Boy, was I wrong!

It was only later - after several successful, and some failed projects - that I realized that The Plan had little effect on the success of the projects. I could only reach this conclusion through experience. Some of the projects I ran were "rushed", which made it impossible to create a Great Plan, but had to be managed "by the seat of the pants". Many of them were successful nonetheless.

In other cases, I did create a plan that I was happy with. Then I had to change it. And then change it again, and again, and again - to the point that I did little else but change The Plan.

Confusing the chicken with the egg, which came first?

The example above is one where I had confused the final cause (chicken) with the original cause (egg).

When something works well, we will often retrospectively analyze the events that led to success, and create a story/narrative about why that particular approach succeeded. We will assign a "final cause" to the success: in my example I assigned the "final cause" of project success to having a Great Plan, and the events that created the Great Plan.

This is normal, and it is so prevalent in humans that there is a name for it: retrospective coherence. Retrospective coherence is what we create when we evaluate events after-the-fact and create a logical path that leads from the initial state to the final state via logical causality, that can easily be explained to others. These causality relationships are what lead us to create lists of "Best Practices".

Best Practice lists are the result of Retrospective Coherence, and because of that many are useless

When the solution becomes the problem

However, this phenomena of Retrospective Coherence is not necessarily a good thing. In my initial example about Project Management I was convinced that the Great Plan and the related activities were the reason for success because that is what I could "make sense" of when I looked back in time. But as I gained experience I was forced to recognize that my "Best Practice" did not, in fact, help me in other projects. This realization, in turn led me to question the real reasons for success in my previous projects.

After many years of research and reflection I came to realize that many projects are successful purely by random reasons. For example: someone did an heroic effort to come to work during the week-end and recover the Visual SourceSafe database that had been corrupted once again and for the 1000th time!

But there are many other reasons why projects succeed by pure random chance. Here are some:

  • In one project we had a few great testers that were not willing to wait to the end of the project to test the product. What they found changed the requirements and made the project a success
  • Some projects were started so that we could deliver the "perfect feature set" to our customers. But as time went by and the deadlines were closing in, some managers - sometimes even me - understood that delivering on time was more important, and therefore changed the project significantly by reducing scope.
  • Some developers were single handedly able to both, increase product functionality, while reducing the code base by 30%. This feat increased quality massively and made a delivery on time even possible.
  • In one project we tried to use Agile. As a result, we started practicing timeboxed iterations and eventually ended up releasing so often that we could never be late

These are only a few of the reasons why projects succeed despite having a Great Plan, rather than because of it.

The Original Cause

The reasons for project success that I listed above are only a few that can be called "original cause" for project success. Original causes are those that actually start a chain of events that lead to success (or failure), but are too detailed or far into the past to be remembered while doing a retrospectively coherent analysis of project success (after-the-fact).

The kicker

But the kicker is this: when we get caught in "Final Cause" assignment through the retrospective coherence lenses or our logical mind, we lose a massive opportunity to actually learn something. By removing the role of "luck" or "randomness" from our success scorecard we miss the opportunity to study the system that we are part of (the teams, the organization, the market). We miss the opportunity to understand how we can influence this system and therefore increase our chances of success in the future.

Many people in the project management community still think - today - that having a Great Plan is a "Best Practice", and that you cannot succeed without one. I would be the first to agree that having a plan will increase your chances of success, but I will also claim that the Great Plan alone (including following that Great Plan) can never deliver success without those random events that you will never recognize because you are blind to the effects of chance in your own success.

In our lives we must, always, strive to separate Original Cause (what actually caused success) from Final Cause (why we think success happened by analysing it after-the-fact).

In a later post I will discuss how to increase the chances of project success by - on purpose - inserting randomness and chance into the project. Stay tuned...

Image credit: John Hammink, follow him on twitter

Labels: , , , , , , ,

at 08:00 | 2 comments links to this post
RSS link

Bookmark and Share

 
(c) All rights reserved