Aug 032012
 

My daughter Alicia is 2.5 years old. Recently I started teaching her how to cross the street. We live in a village where it‘s generally very safe. But whenever we came to a crossing, I stopped her and showed her what to do, saying „Look left, look right, look left! No car is coming, so let‘s walk across the street!“.

She picked that up quickly. She now stops on her own, and then looks down on her little feet in concentration and speaks out loud: „Left! Right! Left!“. She doesn‘t look for cars, she just says the words. She‘s compliant with the most obvious features of the process I taught her – and yet totally misses the point.

Now I tried something new. I ask her: „Is a car coming?“. If one can only hear a car somewhere in the distance, far from being a threat, she shouts: „Yes! Wait!“

Teaching her how to identify a car which is actually coming closer may be something for later. But leading her to judge a situation on her own is obviously more effective than making her following procedures she doesn’t put into context.

Something we should consider when managing our organizations?

Jul 152012
 

At the Stoos Stampede in Amsterdam we discussed what the mission of Stoos really is and if it would require something like a manifesto.
The discussion we had is wonderfully reflected in blogs by Mark, Fabian and Peter. The outcome – some phrases put up for discussion here – is not a manifesto, but a vision:

The goal of Stoos is to bring together people, to facilitate learning opportunities and to help people discovering better ways.

So what do you think about that?
Admittedly, at a first glance this may not quite sound like the call for a revolution.
But let’s take a closer look – if you think this through, it suggests a new paradigm.

Think of how change works in the old world

You read a book or you attend a training to learn something, usually some method XYZ. Afterwards you try to convert what you learned (or better: understood) into practical use – you «implement» the method.
One could also say: You consume other people’s knowledge, and then you apply it to your own specific situation or problem (assuming that it helps).
Or to put it more provoking: You leave a good part of the thinking to somebody else.
- Wow, Taylor would have loved that!

Now what’s the caveat with this approach?
Problems, especially ones related to complex systems and human beings, tend to be as unique as the people and organizations involved in them. So solutions you learn somewhere else rarely fit exactly to your situation. What then follows is typically an attempt to make the two ends meet. This distracts you from your original problem, and may let you end up with a situation which is even more difficult than before.
Do you recall occasions where the use of a certain method or tool got more attention than the real problem to solve?

And this is the Stoos approach

Stoos takes a different approach. We say we want to help people to learn and to have moments of enlightenment. We don’t have a manifesto or a certification you can adopt or try to be compliant with. We want you to find your own better way, totally focussed on what is your unique situation.
It’s not about adopting something predefined, but about discovering what suits you best. You don’t learn things the abstract way and spend energy trying to convert them into practice – instead you get inspired and then learn by doing, focussed on your immediate outcome, and getting instant feedback.

The two approaches are radically different

The old world changes what people do (e.g. by a new process), only hoping that this would also change what in fact really matters – the people’s mindset and habits. This is tedious, as such changes can really only come from within.
The new way changes people’s minds almost as a byproduct – they create their own ways, and when they discover something that works for them, they obviously continue to use it. It is their own insights, their very knowledge driving mindset and habits, not somebody else’s instructions forced upon them.

If we take our lessons learned seriously, then discovering your own better ways is in fact the only possible approach for achieving change. Their is no standard “one best way” in dealing with unique complex systems anybody could adopt – also not a Stoosian one.

Acknowledging this is probably one of the biggest shifts in mindset compared to traditional thinking. While methods do contain a lot of valuable knowledge, they need to be understood as inspiration – not as bibles of ready-made solutions.

So Stoos is not only about a radically different and better way of management – it’s also about a much better way of achieving change. Learning not for a one time change, but as a mindset towards continuous adaptability and improvement.

Jun 292012
 

Reading the session proposals for the Stoos Stampede in Amsterdam, one could summarize some of them like this: «We need to get over linear thinking and mechanistic management! So what are the 10 best procedures to deal with stubborn managers?»

In other words, we seem to be looking for a linear and mechanistic way to «implement» change – away from exactly this thinking.
Is this a promising approach? As Albert Einstein put it:

«You can’t solve problems with the same thinking that created them!»

So what is change really about? Peter Scholtes once said:
«Changing what people do will not change the system. Changing the system will change what people do!»

Changing a system towards a new (Stoos) philosophy is about changing the culture in an organization. Culture represents the habits of the people, and these habits derive from values and principles that people in an organization adhere to.

To work on improved values one first needs to define and prioritize them. It’s not about a long list of fuzzy and generic ideas, it’s about a few concrete ones that make a difference every day. Getting them to life requires principles guiding the work to be in line with the values.

Effective values and principles will change things, no matter what people do.

This is what this session is about:
Jan 092012
 

January 2012. The Agile Manifesto turned 10 years old, and in Stoos some thinkers gathered to discuss how the world’s predominant management mindset can be changed into a new one (unfortunately without much involvement of those whose beliefs are to be changed).

With all this, what’s currently moving the minds of the people? One of the most popular posts sent around on Twitter these days is “Kanban is the new Scrum“. The other hot topic of course is the Stoos Gathering. Even before any real output from there had been published, some people already felt that Scrum didn’t get the necessary attention there.

Watching this I can’t deny some doubts that even the agile or radical management community is really ready for a new management paradigm – one that is pragmatic, naturally effective and on solid grounds.
At least some of us seem to be completely absorbed by the discussion about practices, or in other words, about WHAT we believe in and want other people to do and use. We take our chosen practices’ universal applicability for granted and think that non-believers just need to be converted.

The mere attempt to convince people of a WHAT will always lead to ideological discussions. I don’t think that will take us much further. In fact the sole focus on practices differs in no way from the traditional tayloristic thinking of having “one best way” of doing things, dictated by some being (or pretending to be) smarter than others.
We silently assume that all projects are basically the same, and Scrum is the way of doing them (well, may be it’s Kanban, and history now finally came to an end).
That is missing the point. In fact, in 2001 the Agile Manifesto was already one step further, putting processes and tools second after people and interaction.

A contribution

If we want to change other people’s thinking, we first need to sort out our own. And we need something catchy to communicate. I understand this is the purpose of Stoos, and here’s a contribution to it:

For Stoos to become an effective movement we need to answer first the WHY, then the HOW and only lastly offer some WHATs.

1. WHY do we want to change the traditional thinking in management?

  • What is the core issue, and what is it that needs improvement?
  • We ideally need a “Steve Jobs slide” for this: 3 bullet points, and you get the message and buy it. The graph produced in Stoos is certainly interesting, but it’s too complicated to get much across.
  • This is the main selling point, so it needs to be agreeable for all those whose thinking we want to change.

My input for this point:

  • We found the productivity in performing knowledge work is often suboptimal. We tend to apply management practices that were taken over from other areas such as manufacturing, and we found them not to be effective for problem solving and team work. We pursue a new management approach that uses learning and social interaction to enhance productivity and execute control more effectively.

2. HOW do we want to achieve the benefits?

  • What are the essential values and principles of the new management? (Note, it’s not about practices)

Some input for this point:

  • Knowledge work (such as software development) is about acquiring new knowledge, required to turn problems into solutions. We understand that feedback and learning are key to success and facilitate this with suitable practices.
  • We understand that effective governance is based on outcomes, and not on processes.
  • We recognize that all projects we work on are unique – the problem that needs to be solved, the individuals working on it, and the team emerging from the individuals make it singular. It is a project team’s responsibility to choose, develop and establish practices that they find useful and which enhance their individual productivity.
  • We recognize that a project always has two results – a product and a functional team.
  • We recognize that a team working on a problem has more knowledge about problem, solution and the team itself than some remote management.
  • We understand that only the customer can judge the usefulness of a solution.
  • … to be continued

3. WHAT is there that can help us?

  • There are many methods and diverse practices out there (Scrum, Kanban, Pair Programming, Fedex days etc….). We understand them as tools – each such tool has a specific purpose and requires certain conditions in order to be effective. Understanding the purposes, and recognizing the conditions helps us to make wise choices to enhance the productivity of individual teams and projects.
  • … following a list of practices describing their primary value add and required preconditions…

Comments welcome.

Nov 132011
 

There’s a lively discussion on the web about traditional and agile management methodologies, and about if and how they could or should be combined. As so often when discussing methods, it is easy to forget to ask what really the job is like that needs to get done. So let’s take a step back.

The challenge

A team working on a software is solving many and complex problems. The job of management is to ensure that the team gets and stays on a direction towards developing a good solution. So to discuss management approaches for problem solving teams, one needs to understand how such teams act inside.

Teams are complex systems

The main characteristic of a complex system is that it shows behavior which can’t be fully predicted. The system is emergent, or in other words, the whole thing is more than the sum of its parts. Typical attributes for complex systems are a large number of parameters, intransparency (in terms of unknown parameters and dependencies), non-linear reactions or time-lags of reactions.
Good examples are the economy (think of how the reserve banks and governments try to get a handle on it since the crisis started in 2008), the human body (think of side effects of medication) or the weather (almost any forecast tells you something different for tomorrow).

Teams are complex systems as well, because already human individuals are. How a group of individuals interacts is just as unique and unpredictable as a single person is.

How are complex systems controlled?

That’s obviously now the key question for any manager and management stakeholder of software developing organizations.
The bad news is: Complex systems are difficult to control from outside. There is not enough knowledge around to know in advance what outcome some operation on the system may produce.

Because of this missing knowledge complex systems need to be controlled in a different way – with a so called feedback-control mechanism:

1. Define a desired target state
2. Operate (i.e. adjust some parameters)
3. Measure the result you get (caution, possible time-lag of reaction!)
4. If necessary, go back to step 2 and adjust again.

You do this iteratively until you have reached the desired target state.

This may be just like the heating in your house, when you try to find a setting that makes it cosy for you. (I keep on adjusting mine since years, trying to find the optimum between comfort and preserving energy. My problem there is that I have a very slow feedback cycle – I can’t see how much oil is consumed on a given day, I only know how much they put in the tank when the winter season is over.)

What does that mean for managing teams?

Traditional management typically exercises control from outside with command-and-control (“you do this, you do that”). The assumption is that the steps required to solve a problem can be defined upfront and can (or even must) be dictated to a team.
What we know today about problem solving and teams however gives no explanation why this should be effective or the method of choice. Telling a team not only what problem to solve, but also how to do it, gives more constraints to this complex system. More constraints usually make the job more difficult and lead to a lower overall optimum.

Example: You want to increase the temperature in your house by 5 degrees. Your heater can do this in 2 hours. Now, as an additional constraint, you allow a maximum fuel consumption of the burner of ½ liter per hour. Now the heating takes 4 hours. If you’d add another constraint, say you want the heating in maximum 3 hrs, the system will fall short at least one of the goals (or even all if poorly managed).

The same is for teams: Developing the software is one goal for the team (obviously it should be the most important one). Making the team follow a predefined plan is setting a constraint to this. Enforcing a process, a certain role setup, the use of certain documents and tools, separate supplier teams (e.g. offshore), all these things are adding more constraints. The more goals there are, the more difficult it is for the system to operate smoothly and to reach a good optimum on any of them.

The key lessons:

  • Goals are constraints – so be careful about what you set as a goal. The less aspects you measure, the better the results will be for those you care most about.
  • Therefore, clearly define and manage the priorities of the goals

This is basically the conclusion the agile philosophy came to – give a team one goal (the software), measure it frequently (short iterations), and apart from that let the team work and find its most productive style of working together (don’t dictate processes).

Okt 082011
 

Much is being written these days about Steve Jobs. Rightfully so – what he has done and achieved is just incredible. Indeed, he did change the world.

Here are a few of my observations of things that make Apple so unique and successful.

The important 80%

The Pareto principle tells us that 80% of a product’s features can be achieved with 20% of the effort. The remaining 20% of features taking the product to what is considered its completion however eat up 80% of the efforts. What does Apple do about this?

One secret of Apple products is that they often have less features than competing products. However, those features are made to perfection. No 3G in the original iPhone? No problem, the browsing experience was still way better than with other phones. No MMS until the 3GS? Who cares if you have easy to use email.

Most other tech companies have a different approach. Many of them still seem to see competition in the number of features. Their products do a lot, but maybe nothing really well. Another example is Google, who follow a kind of agile approach with pushing out new products early on as Betas. However, they take it differently – often the features themselves are only 80% complete. As a user I find this annoying – I stopped using Google Contacts long ago when I saw the syncing of groups messing up my data, and I gave up on trying to sync Google calendars with Outlook. Missing features are not as bad as poorly working ones. Once they may complete the functions they’ve already lost me as a customer.

So this is about the important 80%: Do less, but do it right.

The power of saying No

Steve Jobs had the guts to take decisions as to what a product will support and what not. In contrast, many other projects and organizations suffer in fact from weak leadership in the sense that there is nobody ready to say “No, we not gonna do that!”. Too big seems the fear that somebody could object or be blamed afterwards that it is not even tried. The result is a lack of priorities and eventually mediocre outcomes – the people in the organization will struggle trying to achieve just too many different things and goals. To produce really outstanding results, an organization needs an agreement on what the common priorities are. If this is left unclarified, productivity is lost in accomodating too many different needs. The creative team at Apple has few, but very clear priorities. I am writing this on one of their results.

A Vision – concrete and consistent

Over the years the vision that Steve Jobs apparently had in mind only slowly evolved to outsiders. iTunes started as a store for digital music. Ok, video content may have been a logical add-on later. But it was further extended with podcasts, books and apps, incl. now even the operating system. This content providing started for the iPod, continued with the iPhone and now covers the whole product range.

What evolved there is based on a wonderful consistent and concrete underyling Vision. I don’t mean that all this was planned and defined in detail already 10 years ago. But clearly there are some pretty concrete concepts that remained steady over time: content, devices and software to consume the content, and on top the experience for the user. This consistent approach is finally the reason why Apple left behind its competitors, most of them too long thinking only in devices. Only Google is kind of able to follow – but after all only immitating, not innovating.

Many, if not all organizations claim to have a vision. But how concrete is it? Goals like “We want to sell the most devices in category xyz” or may be even “We want to build the best products” is ok for a start, but it’s too high level. In order to make the creative teams on the working level productive, they need an idea what their outcomes are supposed to be like. This is not only about product development, this is just as well true for any software developing team within a company.

I’m sure these are not all secrets of Apple. Isaacon’s upcoming biography of Steve Jobs will certainly provide more insights for those thinking different.

Aug 282011
 

A few days ago Derek Huether started a discussion on his Criticalpath blog about “Theory X vs. Theory Y” and asked for feedback who believes in what: Do you prefer command-and-control or do you believe in team empowerment?
It’s an interesting topic, as the question touches the fundamental disagreement in today’s management approaches. I recommend to have a quick look at the article and the comments below it.

So what’s the answer?
When confronted with two such polarizing choices (which both seem justifiable), a typical reaction is something like “yeah, well, it depends, somehow a combination of both, maybe”.
Well, probably correct. But unfortunately that doesn’t really help. Derek also highlighted the issue by asking what people “believe” in. Can that really be a matter of belief? Shouldn’t we have an understanding about management which is substantiated in a way that we know what and why we’re doing?

The most important thing to know about methods is why they worked for somebody else. So let’s look at the backgrounds of X and Y.

X vs. Y

Theory X resembles a lot of the ideas that served Frederick Winslow Taylor as a basis for his approach of Scientific Management, published in 1911 and first used by Ford’s Model T production.
Basically it expresses a fundamental mistrust in people doing work as employees. The assumption: What they produce is not theirs, so they’re only interested in the money they receive and they will try to get away with as little dedication to the job as possible.
For management to stay in control this must result in a strict command-and-control approach: Tell people exactly what and how they should do it, and verify compliance with the given orders.

In contrast, Theory Y reminds more of the idea of man that the agile approaches follow. People and teams  act responsibly towards an agreed goal, and they are able and willing to organize themselves. Empowering the team is considered more productive for problem solving and creativity than command-and-control.

When does X work?

As said above, the philosophy of Theory X dates back a hundred years and aimed at industrial manufacturing. What are the characteristics of that?

  • There is exact knowledge upfront about what has to happen. E.g. the process for assembling a car is precisely known in advance.
  • The human beings in that process fulfil a function – the function stays the same even if people are replaced.

This kind of work – i.e. routine with only few (if any) unknowns – can in principle be executed with command-and-control.

Having said that, I have my doubts that even in these environments a pure command-and-control approach is the most productive choice. While it is necessary to some extend, e.g. Toyota already years ago allowed their workers to stop the production line if they find a problem with the car they currently assemble – the management counts on people’s responsibility and dedication to a quality product.

When does it have to be Theory Y?

Is Theory X and pure command-and-control transferable to the world of projects and software development? Not really  – for three reasons:

1. Software development is about solving problems, which is unlike routine work. The “one best way” how to solve a problem can’t be defined and commanded upfront – the knowledge is simply not there (if one knew everything, it wouldn’t be a problem).

2. In contrast to Theory X, the vast majority of people in the project business definitely have a broader motivation. They do not only work for money, they like the intellectual challenge, being creative and they care a lot about the outcome they produce.

3. A team solving a problem is a dynamic system, and an individual’s contribution is beyond a mere function. A person in a team influences both the way how people work together as well as how the solution is found. If you replace a person, the team will afterwards be a different one.

These aspects are dynamic and can hardly be controlled from outside the team. This is why problem solving teams in fact work like a feedback control system: Given the right feedback, teams can and will do a lot of the adjustments that otherwise a commander would need to order – but here teams do it better, because they know and feel more than any commander outside the team ever could.

But…

So does that mean that you can or should abandon teams to their fate and just wait until they come back with their result? No, probably not. Here’s why:

Theory Y is – as the name says – a theory, which means it assumes ideal circumstances. However, the world out there is not perfect, and neither are teams. Things that may not fall into place by themselves are e.g.

  • priorities (e.g. time-to-market is key for client, but team considers a refactoring more important)
  • team doesn’t make progress as problem is too difficult (for this team or in general)
  • team doesn’t arrive at productive team processes (e.g. requirements definition)
  • hidden agendas (e.g. trying out a new exciting technology)
  • solutions more complex than necessary
  • … and more

This is why leadership is important. Leadership needs to help ironing out any inefficiencies a team may run into (both team internal and considering the project context). It doesn’t necessarily need to come from one person in charge of management – depending on the team there may be different people ensuring leadership in their respective areas.

In any case, this kind of management is basically another source of feedback for the team. It differs from command-and-control in the way that it doesn’t dictate internals to the team. A problem solving team needs to grow and stay intact in order to be productive.

Aug 072011
 

One of the agile methods’ claim is to overcome the tayloristic approach seen in the attempts to “industrialize” software development. For example, they don’t separate roles within the team, and they develop the product stepwise and evolutionary instead of defining it upfront. So is tayloristic thinking now history? It is worth taking a closer look.

A bit of history
Frederick Winslow Taylor published his thoughts in 1911 in a paper called “Scientific Management”. As widely known, his ideas were first implemented by Ford in the production of the famous Model T car (“You can have any color you want, provided it’s black!”). Soon after, the method revolutionized all of the manufacturing industries.

The basis for Taylor’s approach is the following thinking:
There are two groups of people – scientifically educated managers and uneducated workers. While the managers strive for excellence and higher goals, the workers’ only incentive is the money they receive.
Of course this view was criticized later, but it was just the way of thinking in the early 20th century.
Based on this, “Scientific Management” suggests the following:

  1. Strictly separate management and workers
  2. Management shall define “one best way” how work is to be done, and check for compliance
  3. A high degree of division of labor has to be achieved, as only with very small manufacturing steps it is possible to implement the second principle (defining and controlling “one best way”)

So this is it – published 100 years ago, and made for the manufacturing industry. But could it be that there is still an influence on how we think and act in today’s knowledge work? Let’s check.

1. The importance of methods
Did you ever notice the headlines in professional discussion groups on Linkedin and similar networks? Here are some recent examples:
Does anybody have a WBS for setting up a datacenter? Does Kanban have a product owner? Get the PMP certification now! Is it possible to combine Scrum and Waterfall?

What is interesting: The Agile Manifesto implicitly tells us that methods that work for someone do not necessarily work for someone else. It depends on problem, team and context (Andy Hunt just published a good article about this).
But this insight does not yet seem to be part of our thinking. Instead people and organizations are looking for the “one best way” how to solve their problem. As one can see from the questions, understanding an approach as such (and reflecting on its applicability) is sometimes not even tried. The belief in standards is so strong that way more attention is paid to the methods rather than to the problem itself.

Interestingly, as one of the agile methods even Scrum seems to be marketed and discussed in exactly that way – Scrum is the “one best way”, and you can even get certified for it. Discussions often go around how to interpret something, rather than how to adapt it to a specific situation.

Methods are an important market with demand and supply. But in the end this comes from a tayloristic thinking. Not that methods are useless, but applied to unique projects and situations they need to be looked at with reason and understood as guidance. Progress will be made once people start asking “This is the problem I have – how do I best tackle it?”

2. Staffing
Did you ever think about the human resource management seen in companies today? On the one hand the importance of teams is emphasized, but on the other hand HR is very much focussed on individuals, roles and functional skills.
We want teams to perform and deliver projects, but while e.g. successful sport teams spend a lot of time training together we

  • hire individuals
  • put them in pool organizations and “job families” to develop them within a predefined role
  • and we measure individual goals and achievements

This is a modernized taylorism. A step forward would be to value and develop teams as a whole, and spend more attention to improving their productivity.

3. Monitoring and Control
We still have the separation of management and workers suggested by Taylor (even though the workers are extremely well educated as well today). But that is not the point.
Management of course needs to know what’s going in the company and ensure things are on a good way. But how do they usually do this? They define and monitor procedures: Standardized processes, mandatory tools, review boards checking projects for compliance.

Focussing control on how the work is done again is tayloristic thinking (and again is not overly effective when applied to knowledge work). A new (and powerful) way of monitoring and control would instead be to focus on the outcomes. In order to still have regular checkpoints this would lead to smaller projects with more frequent deliverables. In fact it is about applying the philosophy of agile and lean to an entire organization.

We’re clearly not there yet. There is a hidden Taylor in us and our thinking, and in the way we run projects and organizations. And it is still hindering us from further increasing productivity of software projects and knowledge work.

Changing a mindset requires more than just changing methods.

 

Jul 292011
 

With the return of Atlantis on July 21st the era of the Space Shuttles has come to an end. It certainly was a fascinating program that has delivered quite a few highlights. However, it was not entirely successful.
Do you remember the praise that was given to the new concept of the shuttles 30 years ago? Here are a few things I remember:

  • The shuttles are cheaper, because they (and the booster rockets) are reusable
  • They are safe, because they partially work like an airplane
  • There will be weekly launches to space, because it’s quick to get the vehicles ready for the next flight

Reality was much different: 2 out of 5 orbiters were lost, killing their crew; a single launch weighed in on average with half a billion dollars; and it took more than one year to prepare a vehicle for launch.

How could that happen?
At a first glance, the concept of the shuttles sounds pretty straight and quite suitable to achieve the original goals. What turned out later, however, was that details of the implementation weren’t that simple at all and finally made the Space Shuttle to probably the most complex machine men have ever built. Just a few examples:

  • During countdown, Launch Control at Kennedy Space Center monitored 22000 parameters to decide if a shuttle is ready to go or not. It is no surprise that often they found something and delayed the launch.
  • The heat shield of the orbiters with its thousands of tiles was a weak (and expensive) point from the beginning. The Columbia accident further revealed a fundamental design flaw that eventually could not be fixed. After the issue was known, it just became even more expensive trying to prevent further accidents.
  • Even the Solid Rocket Boosters, apart from the main tank the apparently simplest part of the shuttles, caused the loss of Challenger.

Now compare this to the Russian space program. The Soyuz rockets only slightly changed since the 1960s. There have been more than 850 launches, fatal accidents are rare (also due to a rescue system). Like for the shuttles, the time for a launch is defined months in advance – but did you ever hear of a delay?
The Russian space program almost works like Swiss clockwork.

So what can we learn for software projects?
The Russian spaceships are a typical 80% solution. They are cheap and reliable, but they are not reusable and they can transport only either crew or cargo. The Soyuz rockets are not overly sophisticated, but they do the job.
The US Space Shuttles tried to get close to a 100% solution, combining different kinds of goals. The attempt to create something perfect finally led to a complex beast, which was difficult and expensive to control.

I once attended a talk of Charles Simonyi, one of the co-founders of Microsoft and the only space tourist who was up there twice.
He said, the more he was trained for the Russian spaceship, and the more he understood how it worked, the more secure he felt. It is so incredibly simple, it just has to work.
We should be able to say that about our software systems as well.

Jul 272011
 

A while back, I gave trainings for the “Certified Professional for Requirements Engineering”. As part of the course material there were exercises based on the story of an Amazon-like webshop where participants had to develop a vision, identify and specify some use cases, model the objects and dependencies and so forth.
A typical question raised during the modelling exercise was the following: The shopping basket and the order – are these two separate entities or are they one entity with different states?
My answer always was that you can choose either of the options – whatever you and the team prefer and what fits best into the rest of your model.
Sometimes this question followed: “Yes, but what is the correct way?”.
I always wondered what people had made of one answer or the other.

To me these episodes indicate a more fundamental problem:
A team member is there to contribute to the work of the whole team. The more the rest of the team can make of an individual’s contribution, the more valuable is this input. However, some don’t seem to worry about the usefulness of their results. They occupy themselves trying to fulfil a specified function – they want to do something “right”, but they don’t consider if this is also effective.

Reasons for such a behavior may be among the following:

  • it’s the character of the person, possibly formed by education
  • the person could be overwhelmed by her task and looking for a simple “recipe” she could follow
  • the environment makes people to keep their backs covered

Whatever the reason is, it hinders productivity of the whole team and requires action.

Smart contributions
The contributions a problem solving team requires are variable and depend on current needs. They can hardly be defined upfront with templates and checklists. Instead, each team member needs to listen, feel the vibes and be able to adjust.
Management needs to facilitate this by creating an atmosphere where people feel that their individual contributions matter and are valued. The team as a whole needs to be focussed on the outcome and allowed some room for finding a good solution. This includes making mistakes and learning from them.

The more you have people capable and motivated of delivering smart inputs, the more productive the project will be – especially when it has to deal with many unknowns and frequent changes. Individual reason and experience are the most valuable contributions a team and a project can get.