Today, a friend of mine asked me this question. We both know how companies usually make architectural decisions, but how Agile teams (should) make significant architectural decisions is less obvious. A difficulty with this question is that answer has many perspectives: one could talk about business need, technology choices, documentation, who is involved in decision making, how they actually do it, what kind of meetings, etc.
Why do Agile teams fail and others are extremely successful? Why the rest of the world thinks Europe is a good thing and Europeans are blessed with so many achievements, and only 58% of Europeans call themselves Europeans? Why do you have trouble getting out of your bed and going to your work?
There could be multiple reasons. For a team to be really successful we need craftsmanship, trust, fun, transparency, and a purpose. The things a Scrum Master or an Agile Coach does, has always to do with one of these aspects in some way.
Let’s be honest. Most self-named Agile teams are slightly more successful than teams working in waterfall projects. Hopefully, customer is very happy with some visible improvements: faster delivery, better quality, changing requirements is ok, and maybe few others. The tendency is to spend a lot of time on tuning and improving these aspects, which is good.
I’ve noticed that one thing is very often lacking, and it has a tremendous impact on other aspects and being successful. It is a clear purpose. The purpose is expressed in many different forms. One calls them vision statements, others mission statement or project goals, or even business value. Today, any project or team, Agile or not, has a statement representing a purpose. Unfortunately, most of them are worthless, defined by management and ridiculed by the teams.
One might say, who cares!? Let C-level people define vague statements for their own pleasure, while teams build the real thing. Unfortunately, the reason why you are having a hard time getting out of your bed and Europeans don’t like their Europe is this lack of purpose. Despite the amount of fun, craftsmanship, your large salary and so on, this all will also be affected if purpose is not embedded in everyone involved. I believe that lack of good purpose is one of the most important reasons for teams to fail, and one of the most neglected problems. I’ve seen problems and discussions not being solved simply because the root cause was lack of purpose: “Why are we building this?”….”Because the customer really wants this”… Applying the practice of asking ‘why’ question 5 times will often end up in annoyed customer or product owner. Team might finish the meeting as if everything is cleared up, but what really happened is acceptance of the wishes of the customer, while the ultimate purpose is still unknown or even wrong. The effect is lack of energy and involvement. In worst cases, teams are chasing the wrong goal. One of the most awful experiences as an IT professional is when you spend years chasing a goal, project is suddenly killed and the imaginary goal has simply vanished.
The following is a number of common mistakes when defining a purpose as a vision statement or whatever you want to call it.
The reasoning why your team member gets out of his bed can be visualised as a tree. The roots are the personal reasons for living and not very visible to others. These might be very complicated and different from person to person, but the commonality is doing something meaningful for ourselves and even more for others. Doing something meaningful has different interpretations. One wants to get wealthy in order to support her family and chooses to work in banking business. Someone else, or the same person might change her interpretation during her life time, and gain new insight, like from getting wealthy into doing ethical banking – e.g. investing in renewable energy sources, and refusing to work for banks that support arms industry.
We tend to spend much more energy into something if it fits our interpretations of word meaningful. Unfortunately, this is often neglected when defining something like a vision statement. Leaders have egocentric tendencies where they feel that their purpose is or should be the same as purpose of everyone else.
I remember the moment I decided to leave a company when CEO was giving a speech where the main message was something like this: “We should be grateful that we are doing better than our competitors, but hard times are coming and we need to be careful with costs we are making. Even more important, every professional should be doing billable work. Also, as you can imagine there won’t be salary increase for anyone. We should be glad, because other companies are talking about lay-offs constantly”. The reason for me to leave was not the money, but complete lack of purpose I was somehow expecting at that moment.
In this case, CEO is actually doing his best to make a fit with the purpose of his workers, which is sense of security. For some this was a good and realistic speech, but most simply didn’t care about it at all. We are talking here about highly educated craftsmen / women with huge experience. They are unlikely to feel insecure. This was noticeable during diner after the speech. This kind of pointless statements and speeches usually end up in no reaction at all or sarcasme and ridicule. Effect on energy levels: they become even lower.
So many times I would read a vision statement for a software product and ask management why is it so vague and open to interpretations. The nr. 1 reason they state: “It is a compromise, and we want to have space to move in any direction we wish as needed.”. Ironically, they are not yet familiar with Agile software development, but it sounds like they are. If there is one thing that should not change, it is the purpose explained in the vision statement. Explicitly making sure the purpose behind a statement can change as needed, makes it worthless.
The main reason why companies choose to have vague vision statements is the lack of purpose. If the common purpose is there, it should not be difficult to write it down in more precise words.
On company level, by far the most vision or mission statements are talking about shareholders value and satisfying needs of the customer. The exact same statement can be used for almost any business. The statements like “Blabla company places customer at the center of our business” has a value only when explained further in the context of this specific company and its business. I hope I don’t have to explain why “shareholders value” is completely uninteresting to employees.
Another problem is that vision statement looks like a result of many loosely coupled fancy words. The thinking is: if we leave something out, it will be somehow overlooked later. For some reason, the goal becomes to be comprehensive instead of inspiring.
Let’s say we have a really nice purpose, and everyone believes in it. We start delivering first features of a product. Suddenly, after few sprints, product owner was pushed by stakeholders to deliver something completely outside of the scope of the stated purpose. According to Scrum, Product Owner has the right to do this. Nevertheless, team is confused. “I thought we had this other goal which was more important than anything else?”. PO: “Yes, but this is an exception and I don’t have much of a choice. We have to do this”.
The reality of this example is usually much more subtle. Let’s say we have a nicely stated MVP (Minimal Viable Product) and speed of delivery is crucial – the sooner, the better. This drives any daily decisions team makes together with Product Owner. Any decision should be scrutinised by team if it fits within the stated goal. It is a responsibility of Product Owner to be very careful with any deviation from this goal even slightly. These deviations are not wise for two reasons. One: stakeholders are obviously not fully in agreement what the goal should be. Two: team becomes demotivated.
Although most vision and mission statements are ridiculed and seem completely useless, the real purpose for delivering a product is still extremely important to be truly successful. Lack of common purpose is a hidden impediment. It must be made visible and discussed openly. A team should be able to give feedback, or even better, formulate vision statement together with product owner and stakeholders. There are several practices that might be helpful in this process. One of them is The Product Vision Statement – from book Crossing the Chasm, Geoffrey A. Moore.
I want you to ask your manager or product owner right now: “Why should I put my energy in making this product?” If his only answer is: “Because I pay you to do so!”, then you should be looking for some other challenge. Life is too short.
I usually write about different details of doing architecture in an Agile way and other related topics, but the reality of outside world is that Dutch government loses between €4bn and €5bn on failed waterfall IT projects. This is definitely a problem in other countries too.
As far as I know, this is the first time huge failures in governmental IT projects are discussed so openly. A parliamentary committee has questioned today five people from IT industry in the first day of enquiry. The first one was Hans Mulder (a professor at the University of Antwerp) who gives some hard statistics:
Just 7% of the projects with a budget starting at €7.5m can be said to be successful, Mulder told MPs. In total, 70% of projects fail. Of those which flop, 36% fail so seriously the new system is never used and around half are of doubtful value because they turn out to be too expensive, take too long or produce unexpected results, Mulder said. – source: DutchNews.nl
Second was Stephan Corvers (owner of Corvers Procurement Services BV). The main subject was about procurement process. His expected opinion was that failures have little or nothing to do with procurement process itself. According to him, the customer should better describe what is wanted before starting a project. In other words, more of everything what is already being done. The most noticeable is vagueness of words and statements he used when answering the questions. “Frames….bla bla….framework…frames…bla bla”. At some point a MP asked: “Frames?….euhm what?”
Third one was prof. dr. C. Verhoef. He explains clearly some real and painful issues in those failed IT projects. His main point is the lack of proper knowledge in IT industry. Nobody is willingly contributing to failures, but rather “the road to hell is paved with good intentions”. IT people are lacking knowledge to successfully deliver. Another point was lack of third element in procurement process, which is quality. These big IT projects are given to software companies based on cost and time aspects. In all kinds of games played out in this process, something perverse is happening. The companies which are capable of delivering and know the risks usually loose the project to competition, which neglects the risks or play the game of underestimating and compensating later and in the process make the project much more costly or complete failure for the customer.
It was a nice analysis of the problem, but solution was a bummer. His suggestion was to specify even more (quality aspects) before the procurement process starts. From my own experience, these beforehand “ilities” are always made up by some group of architects in their ivory tower. The effect of this is possible creation of even bigger problem – overcomplicated architecture driven by quality aspects that have little to do with reality. Another suggestion was to split up these big projects in many smaller ones.
Fourth interviewed was Tony Wildvank (ex-contract manager for large IT projects in government). Her main point was that we need more architecture and involvement of architects before we start. What she actually says: even more documents, theoretical analysis, and so on, before starting to deliver anything. The rest of her statements were either unwillingness to answer the questions because they were too sensitive or full of vague statements like with Stephan. Statement like: “software projects are same as process of making socks in a factory” is a sign of huge amateurism and lack of knowledge.
Fifth and last interviewed today was Swier Jan Miedema. He is an entrepreneur with 20 years of experience in working for or directly with companies like Centric, Logica, and Ordina. He is the embodiment of the pain many honest IT people have in Dutch government IT projects. Many of his statements were maybe too honest and too personal, but he is one of the few brave enough who speak out in such way. I really wonder how this will effect his future business.
His was really appalled by atrocities of big and well-know software integrators in Netherlands. According to Swier, IT projects in government are controlled by these companies. They define what happens with IT at municipalities.
I love his solution. Vendors must prove they are capable by delivering something in one week. If not delivered, they are not paid. After this, close collaboration starts where vendor continuously proves its capability by delivering frequently. He did not say it, but it was obviously Agile he was talking about.
Altogether, I was disappointed and sadly confirmed in my assumption of extreme amateurism in these multibillion projects. Insanity is mind boggling. A clear example is that nobody thinks of splitting a large project into many smaller ones. Even some of the interviewed people are mere confirmation of this amateurism. Some pretend to know how to successfully deliver such large projects. More architecture, better specification, better control, and so on.
The Dutch IT world seems to be completely divided in people constantly discussing why those big waterfall projects are failing and Agile world. They don’t interact with each other much.
Your Agile team(s) is incrementally delivering a product for a long time. Let’s say 4 years. After every sprint a new version is delivered into production successfully and many feedback loops are giving information on what can be improved.
There is this one issue with some stakeholders complaining that all that prioritising leaves them waiting too long before they see their needs being fulfilled. In his best judgment, Product Owner has decided to postpone some requests from a particular group of users in favour of others, mostly driven by defined business strategy. This impatience from users is effecting collaboration with team(s).
The issue is discussed in a retrospective meeting, and action is defined to solve the problem. Unfortunately, the same issue arrises again 2 sprints later. It could be from same group or this time from another group of users. The cause here is deep and might be due to lack of alignment between management and users, or different business departments.
Teams spend a lot of time on this reoccurring problem, and more important, a lot of negative energy. It is a waste, a big waste. After each retrospective, the problem is not solved, but often just postponed.
A good thing to do in this situation is first to be aware of that problem has reoccured. The second thing is to prevent statements like “We’ve tried to solve this. It is very difficult, let’s keep trying.” or “We need to do more of what we did last time.” as a possible solution. This usually does not solve the problem. Instead, try approaching the problem from a completely different perspective, maybe discovered by applying completely different retrospective techniques. E.g. Fishbone Diagram. A solution might also be to ask for help from someone outside if problem falls outside the influence of teams.
The main point is, if the possibilities for solution are exhausted, teams should also be prepared to simply accept the problem as given or work around the problem without really solving it. In case of reoccurring problem syndrome, this is better than wasting time and energy in retrospectives in the name of continuous improvement, at cost of giving attention to achievable improvements. From systems thinking perspective, improving something different that is perfectly achievable, might influence in positive way this seemingly unsolvable problem. For example, repeating the business vision and path as understood from business at the beginning of sprint review meeting.
There are many books out there about software architecture and design. Not many combine this discipline with Agile Software Development. There are also many Agile books out there. Still, these books merely touch this aspect by stating general principles. The result is that many Agile teams are still struggling with questions related to architecture. So, I was glad that Simon Brown wrote a book specifically targeted for developers. This post is my review. It will hopefully encourage you to buy the book at LeanPub.
Conclusion, as you may already guessed it, the book is good, useful for a number of purposes, but one in particular: Sketching and documenting architecture and design. The book will give you as a developer a large number of tips and tricks to make effective sketches and effective light-weight documentation. Does this book cover everything in breadth a developer needs to know about software architecture? No, definitely not. It touches a lot of subjects like BUFD, architect’s role, definitions, different types of architectures, collaboration practices. None of them is described as well as the one mentioned above.
If you think: “Architectural documentation and Agile, that does not sound good!?” Don’t worry. The way Simon presents this, it does not contradict Agile principles and Scrum in any way. It merely gives you many possible options in dealing with challenges related to software architecture Agile teams already definitely have.
The book begins with definition of architecture. The message is that there are many definitions, but can be divided in verbs and nouns driven definitions. Both are valid. In the well known confusion of different types of architectures, Simon defines his own preference: application, system, software, enterprise. The new thing here for me is how Simon stacks these. Application is the smallest perspective, system might contain multiple applications and software architecture is the combination of the previous two. While these types are well interconnected, enterprise architecture is placed somewhat outside this very much technological perspective. I like that Simon simplify things and does not put much relevance to this division in types because exact difference is not important and brings a lot of unnecessary confusion. I didn’t really find argumentation why this division is relevant or better than any other.
After explaining importance of managing risks, software architecture role is explained as something that can be fulfilled by a person or a team. How this role could be fulfilled by a team is not really explained, which further emphasises my negative opinion about having a role in the first place. At the end, I don’t share opinion that teams need an architect, architecture role, master builder, architecture owner, or anything similar. Teams need knowledge and responsibility for taking care of architectural aspects. Having a role, only confuses things, and covers up the real problems many Agile teams have as mentioned by Simon. I’m afraid that explanation by Simon will further encourage many architects to protect their kingdom instead of help teams take care of this extremely important discipline.
Simon’s further explanation is about what kind of things an architect usually does: e.g. building prototypes, proof of concepts, perform code reviews. Also importance of being generalising specialist. My opinion: these are all very important things that developers should do occasionally. All developers don’t need to know and do everything, but because architecture is such a broad discipline it is very natural to spread this over multiple developers. This happens automatically driven by knowledge and experience of each team member.
Still, I was glad with importance of having “hands-on software architect”. Simon explains very extensively what this exactly means. I suspect that by applying these things, the difference between architect and developer will blur significantly.
These parts of the book are the most useful ones in my opinion. Simon covers the most important aspects in dealing with software architecture. It starts with architectural drivers: functional reqs, quality attributes, constraints and principles. These are well explained with a lots of practical advise. Teams can use this as a checklist. I like his opinion on term “best practices”.
Simon gives a well-balanced and practical advise about usage of design tools and UML. A number of often used views in approaching architecture from different perspectives is explained. A number of useful advises are given about how to keep things simple and importance of simplicity.
Agile teams love using post-its, whiteboards and flip-charts. A big chunk of book explains how to use these effectively in communicating architecture and design. Also, many pitfalls are explained.
Chapter about documenting seems an extension of the previous two. Simon strikes a nice balance of lightweight documentation. Each type of essential information every software architecture has is explained by blocks containing intent, structure, motivation, audience and wether it is required. If it isn’t clear what I mean, go buy the book. It is very useful stuff. 🙂
The last part is about number of things named “software architecture in the development lifecycle”. It should help developers in dealing with questions of BUFD, significant decisions. The explanation is useful, but lacks argumentation. It seems based on personal experience of Simon, which is still definitely useful.
In a bit unexpected place in the book you will find very practical advise in dealing with risks. Risk-storming is a really nice practice.
Only the very last part of the book touches aspects of incorporating architecture as a discipline in teams. I’ve expected a bit more because of this huge problem that Agile teams don’t know well enough how to organise architecture process.
“Think big, act small, fail fast, learn rapidly” is a statement made by Mary and Tom Poppendieck in the book: Lean Software Development. It is a profound statement.
Nevertheless, it seems we still have so many people having never ending discussions about Architecture and Agile. The questions like: “How much architecture should we have before starting development?” or “Can architecture emerge by doing TDD?”. The typical answer is something like: “Well, you should definitely spend a few weeks” or “It can emerge, but it does not happen by itself”. Also, we love to disagree with other side based on statements full of ambiguous words.
One example is Philippe Kruchten’s post. Another one is a talk “Agile Architecture Is Not Fragile Architecture” given by James Coplien & Kevlin Henney. There is a huge amount of blog posts by a bit less respected names than these, trying to explain wether agile and architecture contradict each other, should find a compromise, or is a marriage made in heaven.
The problem here is that we are talking about architecture as a thing. But, you cannot hold architecture and you cannot point your finger and say: “There it is!”. It is an abstract concept, just like Agile. Abstract concept * abstract concept = unlimited number of assumptions!. The questions above are simply invalid. What exactly do you need to have before starting development, and what exactly emerges from TDD? Answers on the first questions above are arbitrary, and do not give us insights.
This brings me to think big, act small statement. James and Kevlin do state that Agile never forbids to think about architecture up-front, as opposed to actually putting one in stone. That is clear and useful. But then, they confuse a hell of it by stating things like, we must have some up-front design, called RUFD (Rough Design Up Front). So, how much is “rough” and what is it? Jim emphasises abstract classes, and Kevlin interfaces, and “some” documents, and so on. It is eventually one hour of endless explaining of subtleties of an abstract concept, which by itself without specific context does not mean much.
After this opinion of mine, it might amaze you that I actually totally agree with pretty much everything they say. I just want these well-respected names to tell things that are actually usable in practice and a bit less prone to so many possible interpretations, causing huge failures.
The big confusion is caused by lack of clear distinction in the process of what we call architecture. Let me try to make some distinction:
I never heard anyone saying that we should not spend time looking ahead, and having a clear vision of the product from different perspectives. “Think big” is the first part of Poppendiecks statement. I guess Philippe did hear that from some Agile coaches. Some might overlook the first part, and go directly for the second.
By having a vision, I mean first and foremost that everyone involved has it in their head. Is it also placed on a paper? Irrelevant question! It is just a mean of communication. Use youtube if you want, be creative. I don’t care, as long as you fulfil a real need. You can’t do much without knowing this need first.
There is a whole range of practices helping to define a vision. Some of these practices are not called “architectural” but definitely cover things considered architecture. Currently, we don’t have enough practices and games to support teams in this process. Yes, we do have a huge amount of overloaded architectural processes like TOGAF staying at meta level, focusing on navel-gazing models, producing documents. We need you (yes, I’m talking to you Jim :-)) to help in this process, tell about useful practices.
Some, when talking about architecture, mean to say: making or having a significant decisions about used programming language, technology, visible (system and user interface) or invisible (internal) structure. The main problem here is: What is significant? How much is really significant? Which things to postpone and how? What are the driving forces behind this? And, shouldn’t we use technologies and design techniques which enable us to minimise these significant decisions? Which one help us and which don’t?
So, once we have this decision, what do we do with this decision? The biggest and very clear difference between Agile and traditional dealing with architecture is the things we do after we have a significant decision. So, we usually design stuff. With design, I mean draw a picture or implement some code in order to….what? Prove it to someone? Whom? And is it a real proof without delivering real functionality in production first? Also, are we talking about overall internal design? E.g. definition of components on highest level, applying specific approach like CQRS, and so on. Or are we talking about user interface, or maybe something at lower level. E.g. caching technology, abstract classes, and so on.
Which one do we need to define beforehand and why? These things are completely different from each other and should be treated as such. We don’t have good enough answers to this question. Also, word “design” is just as ambiguous as “architecture”.
Besides, from a perspective of doing things up-front: How much time do we spend in this mental exercises compared to failing after 3 sprints and learning from failure? The devil is in these details. There are many different opinions and practices here:
Again, this is all great, but every single of them is completely arbitrary and so much context-dependent. Completely pointless discussing which one is good or bad. The reality is simply: tell me the context, and I will do my best to explain what the wisdom is.
Again, a relevant question here is wether we build overall decisions up-front or not. DSDM, so called Agile methodology, spends during elaboration phase (up-front) huge amounts of effort building significant decisions with, if you are lucky, one implemented use case.
Is this good, bad or inevitable? Again, it depends hugely on technology used and context. Luckily, there are more and more technologies, languages, and tools which lower the price of refactoring. It would be more interesting to have discussion about what kind of decisions must be put in code before starting with first user stories. It would also be interesting to see if we have or can improve certain technologies or design techniques in order to lower the price of refactoring.
Please, be reminded that distinction in different “steps” I make in this post is not my real message. You can probably make a better one.
My message is: Let’s not oversimplify these things by using generic words like architecture, design, structure, and so on. Let’s simplify things by talking about concrete things we actually do in software projects.
One of the questions asked by PolyU students is:
Everyone cherishes his/hers privacy. Therefore, I think privacy is more an excuse than a real reason why someone does not cooperate. Effective cooperation requires certain amount of vulnerability from everyone involved. This is much easier for a person with higher status – official or unofficial by means of knowledge, experience, or earned respect. These people are less likely to put themselves in vulnerable position, because they do not need to be vulnerable in order to cooperate. They simply rely on e.g. their knowledge. This gives them a sense of security. Cooperation with others could even been seen as a mean to further elevate their status.
I believe that most important reason why people not collaborate is lack of this security. They might feel less capable, and therefore less confident, than the rest of the group. From their perspective, they are also not / will not be appreciated for their contribution. If both of these problems are active, collaboration becomes impossible. In other words, if anything or anyone threatens to make someone seem less capable, that someone will definitely tend to not cooperate out of protection.
Some might say, a person is simply an introvert. A large misconception about introverts is that they don’t like to cooperate. Introverts definitely love to engage with others in order to create something together. They only have their own rules before spending their energy on cooperation. They also need to feel comfortable with a person first.
In Agile environment, it is simply unworkable to have people working in corners alone, protecting their privacy. Self-organising teams cannot operate without everyone’s involvement. I sometimes express this to a whole team, without ever calling the person by name. Also, in most of Agile practices everyone is involved. Mere introduction of these might solve the problem.
Another reason why people are not cooperating, is because they believe it is more effective to work alone. Why? Because of the exactly opposite reason: the rest is not as capable as he is, why bother? In IT, we call this: Hero-Driven Development. One, or few guys who do everything because the rest is too slow. It looks as if team would never work without these guys, but very opposite is the truth. In extreme cases, the best thing to do is firing this hero.
This all does not mean we are allowed to force someone to collaborate. It does not work like that. As I just described, the reasons can be very deep. It takes a lot of effort to change them. This effort must come just as much from the rest of the group, as the person in question. One universal approach is appreciation. Encourage the person to contribute by asking her help, ask and value her opinion, give compliments when she contributes. This all takes time, sometimes years in order to see a change. I’ve seen some amazing changes in the past years. Therefore, newly forged short living teams are less likely to work as really self-organising teams.
In Asia, language seems to be a problem. In more international companies, where English is the main language, Asians tend to feel a bit insecure in presence of all those British or Americans. This might influence collaboration. The word here is: patience. Let person find his words, take his time, do not interrupt him, or prematurely state that you already know what he is trying to say.
One of the questions asked by PolyU students is:
My personal experience with different cultures in combination with Agile is limited. I’ve worked in Agile context with Dutch, Serbs, British, Americans, Australians and Hongkongers. Through collaboration with Agile people from many more cultures, I have learned about their challenges.
It seems that culture plays much less of a role than we often think. Certainly, in cultures with rigid hierarchy, there are number of specific challenges to be aware of and which might make things a bit more difficult.
For example, in order to get feedback from teammates in Scandinavian countries or Netherlands, it is enough to ask a question like: “Please tell me, one by one, how last 3 weeks felt to you.”. In those countries, it is important to add: “and please, keep it within 3 minutes per person”. Otherwise, there is a chance meeting will take too much time causing all kinds of discussions. In Hong Kong, on other hand, effect of this question is usually that team members don’t really know what is expected, or don’t feel encouraged to give honest opinion in front of everyone. The meeting will likely result in an awkward silence.
We often play games in order to experience what Agile is. In some of these games, participants – girls and men – hold their hands, sometimes in awkward positions. You can image that this is unacceptable in certain countries.
Still, these challenges are easily solved. The people who facilitate this process, only need to be aware of these differences and figure out practical solutions to each of them. In above case with Hong Kong, it works much better if everyone is requested to place their feeling on paper or some scale, like Happiness Metric. This is a good stepping stone for starting an open discussion.
Embracing self-organisation is a lot about letting go of many things we take for granted. One of these is the power and privileges of managers. This one seems to be a bigger challenge in Asian countries than Scandinavian countries. But, other things are quite the opposite. E.g. Agile is all about never-ending learning process for everyone involved. Hongkongers are really eager to learn new things and change is part of their existence, while Dutch are often eager in having and stating opinions before properly acquiring knowledge about the subject. Also, managing constantly changing company is often considered as chaos and something bad.
So, rigid hierarchical structures are still less of a problem compared to a whole set more difficult challenges, which have very little to do with specific cultures. These are the biggest challenges I come across:
Most of cultural challenges and differences are solved by creating open, honest, respectful and trustful environment. Once people feel this, they usually lower their walls defined by their cultural preconditioning.
One of the questions asked by PolyU students is:
Let me start with what it means to make a decision. By the way, in english it is more correct to say: “We make a decision!” instead of “We take a decision” like many often say. I’m not saying this to be overly precise about proper use of english, but to emphasise the process aspect of decisions. Having a decision should always be less relevant than the path before and after decision is made.
Later in your first job, you will find out that some managers make decisions much faster than any team could have. At the same time, these decisions are not really good. You don’t need to be a manager to make 100 decisions in one day. The challenge is to make well-educated decisions. For this, both manager or team need information and experience. A group of people has simply more knowledge than just one manager. Also, a one person making a decision tends to have tunneled vision. There is nobody who will say: “So, what if you are wrong?” or “What are the other options even if this one seems so right?”.
So, the issue here is not really who makes better decisions. It is rather that group of people have different opinions, which complicates the process. They obviously tend to disagree with each other. That costs time. Is this bad? It depends. Let us not forget again, it is decision making process which is important, and less the end-result. So, in case of a group of people, the challenge is to have them exchange arguments in creative mode where everyone first listens to others before judging or dismissing proposals. Actually, the judgement part is postponed as much as possible and separated from creative part where everyone learns from others. If the process is creative, the end-result will be much better than having only one person make a decision. This creative mode is also characterised with presentation of factual arguments instead of only opinions. Giving opinions and making assumptions is not bad, but it should always be subordinate to proven arguments. Also, group of people should be aware of their knowledge limitations, and be humble to admit that even they as a group don’t have enough knowledge. This is often invisible cause of disagreement.
Another challenge are all kinds of egocentric behaviours. Some team members want to prove to others they are always right, and others are very silent because they are afraid to offend someone and especially if other is higher in ranking. Both are just as bad.
Nevertheless, all these challenges are very much worth spending time on. They are definitely solvable. If we consider decision making as a process, than a team makes better decisions and faster than a single manager.
We should also not forget the process after a decision is made. One of the greatest challenges managers today have is convincing others that decision they made is a good one. I’ve seen many managers spending months in this process and it is not pleasant. If this manager at least has involved his workers in decision making process from the start, than whole process would likely take much less time. This problem is very visible in organisations with highly educated workers. People naturally tend to disagree with something simply because they were not involved.
One of the questions asked by PolyU students is:
You are making a correct connection between people understanding each other and having a real team. This is an absolute prerequisite before expecting any substantial and sustainable improvement in a team. I interpret your question as what kind of practices do we have in order to achieve this.
The most of Agile practices are concerned with creating environment where team members are naturally encouraged to collaborate, get to know and help each other. The most common one is, again, retrospective meetings. Some say, if you are only allowed to choose one Agile practice, let it be retrospective meeting. Why? It is the most important driving force of continuous improvement. To have a such meeting every 2-4 weeks, means to create a moment and place where all team members stop with usual work, take a step back and observe what is happening.
This meeting can be facilitated in many different ways. There are many websites and even books describing different techniques or plans. A number of these stimulate teammates to get to know each other better. One that I particularly like is Appreciative Retrospective.
There are a number of principles behind Scrum which create environment where people are indirectly encouraged to get to know each other. One of them is that whole team is held accountable for possible failures or successes. There is much less tendency to single out one of the members even if it is obvious she contributed most to a failure or an achievement. Because of this, others in team will naturally appreciate each other or help each other.
In general, the best and fastest way for a team to understand each other better, is to simply give them a challenging goal and let them succeed or fail as fast as possible. After a possible failure, they will naturally retrospect and get to know each other in the process. Btw, a team is more likely to learn and get to know each other after a failure than after a successful delivery.
Other ways to get to know each other is to have fun together. Have a beer together, diner, organise hackathon nights, watch a movie together, a vacation, play games, BBQ, or karaoke here in Hong Kong :-).
This is a short movie of an Agile team that went skiing and snowboarding together in French Alps.
LeanArch.eu 