poniedziałek, 1 grudnia 2014

I am so delighted that article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before so please retweet it and share it wherever you can.

środa, 24 września 2014

It's been almost a week since Agile Prague finished. It was a great time of interesting discussions and meetings.
I have had a privilege to talk with Linda Rising about patterns, their history and current state (still under development). She also gave wonderful talks about Agile mindset and trust.

It was also a pleasure to discuss with Paul Klipp and take part in his talk about communication - the subject I am always interested in.

Another two interesting subject I listened to were ones presented by:

Vasco Duarte - about NoEstimates approach, which in my opinion is not exactely about not doing estimation, but to extremeley simplify the way you do it. In short: estimate an item with 1 point. If it is too big (should be more than 1), split it.

Vacation time is over and it is time to start to hard work :)
I have a privilege to speak at 3 conferences so if you would like to meet me and talk, don't hesitate - join the conferences as soon as possible.

My first talk will be about refactoring and concept of Natural Course of Refactoring in Prague on 16th September. There is a big chance that I will show more advanced example with many tricky and non-trivial transformation.
More details about the event can be found at http://touchmyconference.com/AP2014/#sessions

The second activity will be a workshop on Soft Skill for Tech guy in Cambridge on 2nd October. So if you want to learn how to use very useful model to handle conflicts just come.
More details about the event can be found at http://agilecambridge.net/ac2014/programme/

In addition to that I will be talking at great Polish conference in Cracow called JDD that I have been with for ages (from the beginning). The talks will be held in Polish. The first one will be "How your code speaks to you" and the second one with Michał Bartyzel about "Strategic refactoring".
More details about the event can be found at http://14.jdd.org.pl/.

Ohh... I forgot. Warsjawa! Yes. There will be great opportunity to put hand on keyboard and repair legacy code during "Working with legacy code" workshop.
More details about the event you can find here http://warsjawa.pl/

środa, 16 lipca 2014

Agile thinking has been with us for several years. There is a lot of humanity behind Agile thinking and this is what is great about it. But Agile like every idea is just the idea. Not easily applicable in life and many times distorted to be convenient (and not necessarily useful). People focus on practices and loose the spirit of the idea. Agile is just an example. All in all the problem is deficit of humanity in business context.

The deficit of humanity is driven by profit maximising what leads to short term optimisation. In consequence leaders face goals that are profit oriented (expressed in strict timeframes, number of features, low budget). And these forces make them afraid. And they try to force team members to achieve this profit oriented goal. It creates a lot of pressure and there is very little space for humanity.

What makes the problem bigger leaders (especially Technical ones) don't know how to deal with so called difficult situation, when someone doesn't agree, someone complains about something not forcing them to do something and be effective at the same time. It is big challenge for them to give away the power to people. Many of them declare it, but very few really do it.

And it is time to rebel! It is time for non-violent rebel. It is time to clear the misunderstanding that you can only fight in style "An eye for an eye, a tooth for a tooth" in order to change anything. It is time to see that you can be honest and take care of your needs and at the same time be in connection with other people in your team and outside your team so that you can look for ways to help them satisfy their needs... without violence. It time to settle the humanity in world of business.

Will that be easy? I want to be honest. No. I has its price. Is this possible? Yes. It will require a lot of work but very satisfying work.

If you want to look for your own just google for "non-violent communication". If you are patient or want to see NVC in IT world just come here from time to time.

czwartek, 3 lipca 2014

I have recently came across this beautiful infographics from +Anna Vital

I have been a productivity fun for ages but my approach evolved through time and it's time to make some kind of summary here.
When I look at elements in this great mindmap, I recognize almost all of them. Most of them I have tried and many of them I use. But now I look differently at such things than 10 years ago. Those days it was just a bundle of handful hints that I read from time to time and they didn't mean much to me. Just like all those fancy "good practices" that everybody knows and very few does. It was a time when I was hungry for fast solution - easy 10 points that would change my life. And they didn't of course. Because important changes require time. They require patience and perseverance and it's less and less common nowadays.
It took me almost a year to recognize how can I manage my anxiety doing workouts (runnings) with all those nuances that can be helpful to do it effectively. And believe me I am a smart guy, so the stupidity was not the reason of a timeframe.
I spent almost a year to REALLY experience what it means to focus on important things and suppressing urgent. What isn't done in most organizations although they all declare it. Because it is not easy to tell your customer with courage in heart "We will not do it under that conditions, in that timeframe".
I took me couple of months to start making conscious decisions about healthy food, understand and feel consequences.
I took me at least ten tries before I gave up being in touch with the news.
I took me TEN year before I really understood and experienced that lack of sleep is disastrous and in contradiction to productivity at all.
And so on and so on. All that stuff because knowledge not practiced is just a noise.

After those ten years I realised that the most important thing is to slow down and give yourself time. Important changes require time and you cannot do them in fast track mode. Many books and trainers promise us fast results but remember it is just marketing.

I remember that 10 years ago I loved such lists like the one above, because as a tech guy I liked to have short lists with most important information. So then I read them but nothing lasted in my head.

They are great as a reminder if you practice all this staff, but not much helpful to really use it as a daily routine when you start. Then you need at least a book on each subject or better go to training, and after that time practice it for months. Then you will succeed.

There is one thing when you have a deep understanding of a rule after long time of practicing: you don't need that rule at all, then you have it built in and you strictly know when to apply it and when to broke it. But it comes with time. No shortcuts.

Last thing is obsession with productivity but we have to remember that productivity is in opposite to creativity (http://lifehacker.com/5918138/is-productivity-killing-your-creativity). As a knowledge worker you cannot be 100% productive otherwise you just become a reflectionless robot.

Current polish mentality
comes from historical circumstances - starting from XVI century Poland was
mostly a food supporter for countries in western parts of Europe and it
had a great impact on internal relashionship between layers of Polish
society (master - slave relationship between "big" owners and
single farmers (villein?))

A farm mentality was focused
mostly on surviving what wasn't enough when capitalism became a mainstream
where the profit is the most important goal of the organization.

The master - slave
relationship leads to compliance but sacrifice creativity which is crucial in capitalism.

Most polish companies even
international corporations locally fall into this schema. In western
divisions vision, mission, people and values are respected but in Poland
it goes down to that master slave mentality. Top managers are masters and
all guys "below" have to be obedient otherwise they are punished.
No chance for participatory management (me: Agile for example). People in
such an environment don't take full responsibility for their work. The
opposite is Scandinavia for example.

I find similarities
in such master-slave mentality also in other
Central European countries (Czech Rep., Hungary, Ukraine, Lithuania
etc.).

I love such articles
because they always broaden my perspective and understanding of a surrounding
reality. But I am also very cautions because it is very easy to abuse the
history, consequences of different historical circumstances because it is more complex than simple or complicated. So here is my point of view that
comes from my personal experience (and dealing with different, mostly Polish
companies).

Based on the article
we could draw the conclusion that Agile mentality is not much compatible with
Polish master-slave mentality. And this is what I can see quite common
especially in big companies (corporations) that their flavour of agile is not
so agile. But also smaller companies are no better in this case. I have
seen just a few companies that fully employed Agile mentality.

But on the other
hand I wonder whether it is only Polish problem. Our industry is very
international, it is almost global industry and we know that the master-slave
mentality is quite common also in other countries (called command-and-control
way of management) and it is also very difficult to transform that mentality to
Agile. So it is difficult also in US, UK, France and other countries. What
differs these countries from Poland is that it may be a little bit easier to do
Agile transformation (what doesn't mean it is simple). There is a little more
openness and trust in people in Scandinavia, France, UK than in Poland.

What also comes to my mind is Nonviolent Communication movement that tries to provide an alternative to so
called violent communication (when there is an assumption that somebody is right
and the other is not correlated with master-slave mentality and that we were trained to be correct in social terms but
not authentical and it is source of violence) and it was invented in US not in Poland.

Therefore I wouldn't
overvalue the hypothesis that this specific Polish historical background is crucial because described
problems are not only Polish after all. I believe that it had an important
influence on our (Polish) mentality but
there are many more social, historical, financial, anthropological processes that influenced the current situation. Maybe it makes a little bit more difficult to employ
participatory management practices (like Agile) in Poland than is some western countries but we are not so special as it
was described in the article.

I can see it in a different way. The XX century was the time when humanism started to grow (thinking that people are important) and it is one of the root causes of the movement from command-and-control to self-organizing management. Every country has its own history and background that strengthened the command-and-control thinking (force based). The story in the article might be a Polish story. Other countries have theirs. Some of them had stronger or weaker influence. And that's all about it.

On the other
hand in order to employ participatory
management (ie. Agile) it really requires supporting mentality (like Japan Samurai mentality
or Scandinavian openness and trust) to make it easier.

środa, 12 marca 2014

I have had a great opportunity to take part in some kind of experiment. I consciously got rid of most tasks from my personal and professional life that I considered not be fully joyful and purposeful. What I expected was that I would be more focused on things that really matter to me and I could consciously choose what to do (and what not to do).

I stopped checking my phone every 10 minutes, including Facebook, Endomondo and Twitter. I and Michal decided to strongly simplify the way our company works (including the employment decrease). I stopped to start new books (I used to start many and finish few). I stopped to obsessively do tasks from my TODO list. I stopped doing most stuff that everyone does. I focused on family, my core professional stuff and running. I have created a lot of space and time to think.

And you know what? It is hard. It is extremely hard. It is not easy to find out what is really worth doing. It is not easy to make decisions with full awareness. It is a big relief when sometimes I forgot about my experiment and start doing things compulsively. I don't have to think! Of course I am doing much thinking then, but it is about solving a particular problem. I more react to circumstances than I am aware of what I am doing. Like a drug. Doing anything is like a drug. You loose your conscious thinking and start compulsive, reactive thinking (which may require a lot of IQ).

Now I think I fully understood (or would be better to say "I internalized") that:Doing anything, being busy is an easy way.Because (what is commonly known) it is extremely hard to do the right things. And it is really much harder to figure out which thing is right rather than do it. What I notice is that we are not taught to think this way and not used to it.

Being busy is a sickness of our times. It is motto of professional life. Most decisions are made because there are so many things to do and we have to react in some way. But these are not conscious decisions. These are reactive decisions and many time destructive ones.(photo from: http://www.intervarsity.org/sites/default/files/uploaded/busy2.jpg)

wtorek, 4 marca 2014

I have been reading a book on a fathership recently (yep, tech guys also read such books:-)) and there has been a discussion about responsibility. Even when fathers devote their time to spending time with children and doing some tasks related to children and family they may still don't take responsibility for it. So you can take your children to doctor when they are sick, bring them to school or kindergarten everyday, go with them to a playground... and still not taking responsibility.

How come?

Because responsibility is not about doing (at least in a first place), it is about having in mind what you are responsible for and taking care for it (ie. anticipate and respond to the situation).

Common! Fuzzy? A little bit :-)

Let's go back to the children example. You may go to doctor because your partner told you to do it ("Honey, I have an important meeting in the morning, please go with Kate to doctor"). This is just a task. If you accomplish it (or you can't for some reason - for example doctor is not available today), you are done. Now it is again your partner's worry. She still has to think about it. You have just done you task. To take responsibility is to think about the subject of responsibility (to have in mind) . Example: As a father I proactively think what to do when my child is sick (organize a medical appointment, a babysitter or go to a sick leave) and in longer term to remember about immunization, important dates etc. Then you can tell you take responsibility for your children's health. It is more about thinking and being aware than doing (which is also important after all).

Ok. But what does it have in common with my team? Many leaders want folks in team be responsible (and what is funny they are not able to define what it means).

In business context we very often use the word responsibility mostly in context of a task. "You are responsible for this task", what usually means: do it from the beginning to the end. But in such situations it is much like going with child to a doctor. It is task-doing and not responsibility-taking - for your team, process, product. Being responsible just for tasks makes folks passive, creates the illusion they have no impact on what is happening around you, that the "others" decide. And then they feel powerless and their work becomes boring. It takes juice of life out of you. Who likes it? Hands up!

What to do in real life:

If you are a leader: Discuss with your team what "responsibility" means. Create your own definition. It is unique because of your different expectations and past experiences.

If you are a leader: Create environment where people can are encouraged to take responsibility (and not only for task-doing): let people estimate, let people choose task they do (according to priorities), let people influence the way they work (through retrospectives) etc.

If you are a team member: Suggest such discussion in a team. Discuss difference between task-doing and responsibility taking and how it harms you.

To sum up let's define what responsibility means when applied to different "things":

task responsibility - doing the task from the beginning to the end, anticipating problems and proactively looking for solutions when problems arise; it is situation when nobody else have to take care of the task (unless it is shared task);

team, process responsibility - being aware of what is happening in the team/process and proactively looking for ways to improve the way it works (yep, in my opinion it is not only team leader job); look for ideas, improvements, experiments, insights, questions that can influence what is now;

product responsibility - consciously, sometimes critically looking at a product evolution, look for ideas and express them (and it is not only your Product Owner's job).

I will be presenting talk titled:Structured soft skills (not only) for Technical Leaders
You are not a born leader. You haven't been prepared to be one but you were chosen to be. And then everything changed. Now you should be a good communicator, negotiator, mediator, facilitator, motivator. You have heard that you should be a servant leader, should prefer collaboration over contract negotiation, people over processes but … you think: „What the heck should I exactly do?“ Most of the leadership hints are general, fuzzy and unstructured. If it sounds familiar to you, this is a talk for you.
We will talk about fundamental soft skills in a structured way. You will see a lot of schemas, diagrams, algorithms, dependencies you weren't aware of before. This way misty soft world will become familiar and easier to understand for left-brainers (people loving to think in an analytical way).
What we will talk about?

How to resolve tough (conflict) situations.

How to find a problem solution.

How to conduct effective meetings in a way nobody told you about earlier.

Who will benefit from this?

Technical leaders, team leaders, any other kind of leaders working dealing with software development.

Leaders and all technical folks interested in developing their soft skills.

Technical guys (developers, testers, ux designers) at least having clue that soft skills might be really important in their work.

-----

I am excited and a little bit stressed as these will be my first talks in English.

piątek, 28 lutego 2014

I have talked recently with my colleague about importance of domain expert availability in the project so that you can clarify the domain specific question.- In most cases your work is more buggy and costly not having such a person available - I said.- But what if the product is not so important in the context of the whole company (big insurance corpo for example)? And will be replaced by another project within two year. But it must maintained and developed for that time to keep business working in this area. Then business is not so eager to dedicate valuable domain expert for this case... And then the team is wandering looking for good domain answers but it is included in the cost.
- You might be right - I said.
(Of course I could have been convincing him that people may not be motivated or frustrated, but so what if the case is not that important for business and from business point of view there is no greater sense to get much involved.)

It may sound sad but be frankly speaking not everyone works on first class projects, the shining stars in the sky, where everybody is excited just thinking about it...
Then just do your work in a way you can be proud of (with as much craft as possible) or change your job.

For IT leaders the topic of knowledge management is no man’s land. There is a silent assumption that it happens on its own. Well, to some extent it’s true, because as software developers we are used to the fact that not to fall out of circulation in our field we have to learn new things all the time. But that’s not enough. It’s not enough if all the team members (in fact half of them) will get to know something on their own. If the team is to work efficiently, they need knowledge that is consistent and up-to-date. And in this case cutting-edge technologies skills have a small value only.

Therefore, dear leader, you need to know that it is important to be mindful in managing the development of your team’s knowledge. It is often treated as secondary aspect of the functioning of the team – or even ignored, since it is not coding, it is difficult to put it into schedule and people somehow do without it. Well, as the old saying goes, the devil’s in the detail and this “somehow” makes a big difference. Based on my experience, the best teams that I have ever met in my life had really well-developed methods of team knowledge management.

Why is it so important? Below you will find selected pathologies that really happen, and heuristics that usually work well:

lack of architecture documentation – Yes… yes… Currently we are all Agile, so we don’t need any documentation. It’s high time to put these excuses aside. You DO need the documentation. Especially the high-level one. What I mean are the drawings which document the system from the bird’s eye view – context diagram/drawing, component diagram/drawing, architectural mantra, diagram/drawing with the main mechanisms that we developed (i.e. the frameworks). When you don’t have these documents, it is particularly difficult to talk about solutions, changes in the system or introduction of a new person, because we have no point of reference. Without it, how do we know that we are talking about the same thing? How do we know the structure of our system? Low-level documentation (sequence diagrams and diagrams of particular functionalities) is not very useful. This is rather a temporal type of documentation that we need for the development phase, so a simple ad hoc drawing on the board is perfectly enough;

lack of strategy for introducing new hires – sometimes you have it, but it’s rarely done in a correct way. In most of the cases (assuming that you have one), the strategy boils down to providing the new person with a few days of chaotic introduction which is more about organizational matters (company procedures), environment configuration, repo, etc. And, perhaps, a couple of words about the system… “He/she’ll will find the rest in the code.” And what happens then? The new person gets to know the system based on its code. Instead of 2 weeks, it takes 3-4 months to (more or less) look around the system, its building blocks, the preferred solutions and the domain in which this system works. Yup! Getting to know the system on your own is several times longer than mentoring provided by a selected team member. “Well…., but someone has to spend time on it instead of coding.”

At this point leaders/managers unconsciously use local optimization, which means that they want to use the new person ASAP. But it’s no use, because for the first months such a person is inefficient.

Apart from the strategy to introduce new people (i.e. a 2-3 week plan that specifies what, when and who should teach the newcomer), you need to complete the previous point, that is the high-level documentation which will shorten the time needed for mentoring. BUT it is important not to treat it as a document to be read (“There you go, just read it.”), but as a tool and a starting point for the discussion with the mentor. The document itself – regardless of how well written it is – is of no use;

people do not know the code/the system – this problem is a direct consequence of the previously mentioned two problems. Due to the fact that people don’t know the system very well or their knowledge is rather peacemeal, they waste their time on searching and other people’s time on answering their questions. Apart from that they have to learn as they code and many times copy the solutions they find – not even knowing if they are desired or not;

lack of consistent rules – currently the shared coding standard has in fact become (nomen omen) the standard, but it’s not enough. Because of the fact that there are many other factors that influence code readability or cleanness of the architecture which should be shared – consider, for example, clean coding rules, implementation patterns used and building blocks (architectural mantra). If you haven’t set that and you don’t monitor it, it leads to the erosion of the architecture caused by application of inconsistent solutions. At first you might not notice it at all, but over time, with the development of the project, you start to struggle with the snowball effect;

lack of exchange of knowledge in the team/between the teams – it often happens that you neither have money nor time for trainings, but I have the impression that leaders/managers do not appreciate the most valuable tool that they have – the knowledge and experience their people gained in their project. Can you think of any better source of knowledge that is tailored to the needs of the team? You have to create the environment for the exchange of knowledge – let a part of retrospective be a time for promoting good solutions that are worth popularizing, create a base of code examples (e.g. how to code a good service or a controller), stimulate short internal trainings such as “What have we learnt using the X library?”, let your people work in pairs – if not all the time, at least at the beginning and at the end of creating a solution. Not all the developers can work together – sometimes you have to put effort into teaching them how to do it, i.e. how to find a common solution when there are different vantage points.

Dear leader, building the environment of continuous learning should be one of your main goals. Thanks to it you will have well-motivated and efficient people who will create consistent solutions.

What will you get if you don’t initiate such a process? You might already be familiar with it – there will be implementations of the same mechanisms in difference places. You will have problems if someone leaves the team, because knowledge and expertise will be linked to particular people.

Lack of exchange of knowledge means lack of motivation and boring environment, so over time you will start struggling with higher turnover in your team and the outflow of knowledge and experience will be more and more noticeable. Apart from that the general expertise of your team will decrease. In fact, it will stop at one level, which in software development means regress.

lack of knowledge updates about system – each developer or a leader who has some experience is aware of the fact that systems change faster than we think and in a different direction than we have expected. Therefore, all the arrangements about system architecture, libraries and mechanisms used will have to be modified. Leaders often forget that they have to put effort into implementing and maintaining the change. One of the most frequent mistakes that leader or (the main) architect make is that they are the only people who know the direction of the system and “the currently correct” version of the architecture. Sometimes they even forget to announce it (that’s odd, right?). Sometimes they only write an e-mail and send a document. And that’s not enough.

First, you need to gather feedback from people and know what difficulties they see in applying the vision and what resources they need. Second, in the first phase of implementation you need to have the method for monitoring changes and focus on design during code review, applying verification lists (checklists) checking key assumptions. And you should do retrospectives, which through the analysis of problems and successes will enable you to monitor the efficiency implementing architecture vision.

lack of places to gain new knowledge – many companies have a strategy like that: here people learn on their own. This is perfectly OK. I am the representative of this way of thinking as well ;-)

But this approach has its drawbacks.

First, when you learn on your own, you limit yourself to the context that you know. It is hard to go beyond it. For this reason it is much harder to find other, more novel solutions and a different approach to the problems that you have to solve, because your perception is limited by your so far experiences. Second, learning on your own is often snippy as you collect a lot of information, but you can’t glue it up as a whole. That is why self-learning leads to the impression that we still have a lot to learn. It’s hard to tell what is grain and what is weed. You need a few years of experience to learn how to distinguish between these two and say: that’s enough. Third, other people serve as the best inspiration that you cannot substitute with individual work. Most of our ideas stem from contacts with other people – be that personal contacts (which I perceive as the most efficient) or contacts through internet.

This is the reason why trainings, conferences and events that are not fully connected with what developers do in their everyday job are extremely valuable. Your task as a leader is to focus and catalyze the knowledge and experience gained, for example through the following question: “How can you use what you’ve learnt there?” And don’t let them give you short shrift by fast and simple answers. Dwell on and you will get a more conscious and knowledgeable team member.

czwartek, 6 lutego 2014

I have had an interesting conversation with my friend who is also a manager in one of Polish companies. In a certain moment he said:

- You know, what I have been doing recently was mostly convincing business not to start a particular project or to start it later. It took me a lot of time - he said, having in mind it was a loss of time.- That's great - I said. - I think it's one of the most important things any leader should do, especially when working in a high pressure environment. As Steve Jobs said one time: the most important tool to improve programmers productivity is reducing number of features they have to implement.

It's the most common disease software teams have to deal with. It's quite common that a few projects are run in the same time and then another one is added to the stream. All Kanban and Lean practitioners will tell you it is a waste. And it really is. Don't you believe? Try Knibberg's Multitasking Name Game. Play it with your business and then discuss what can you learn from it.

Intro

You might have already come across terms such as complex systems,
complicated systems or complex adaptive systems; especially, if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s
ideas about the applicability of Scrum. It might sound intriguing, but finding
logic in it is difficult without some background theory. This is the point at
which Dave Snowden’s Cynefin concept comes in handy. This concept is based on
complex systems theory, anthropology, evolutionary psychology and, last but not
least, cognitive psychology.

What’s the
matter with software development?

For
about forty years people who deal with software development have been wondering
what it really is. Can we compare it to anything? Initially, people
approached it the same way as it was in Ford’s factories, i.e. through
classical management methods and tools such as hierarchies, division of work,
specialization, plans, etc. It did not work, though. The popular metaphor,
according to which software development is like the process of designing and
building a building, did not work either. It was Agile that went a step further
– it was finally accepted that change is a natural element of any project. Technologies
change. Requirements change. Our co-workers change (which is obvious considering
the fact that it takes months or years to complete some projects). Therefore, whenever
we run a project, we have to take changes into account. And we have to adapt to them. That is how Agile has aroused, including the most popular method Scrum. Sometimes they proved effective,
sometimes they did not. People started
seeking for a theoretical background that would allow them to understand why
Agile really works and what are the criteria that would help them decide whether they
should use it or not.

The Cynefin
Model

In this respect the Cynefin model comes in handy, as it organizes
problem domains that we come across depending on the applicability of
approaches used. The basis of this model is the relationship between the cause
and its effect. As a result, the following areas of problem (system) complexity
can be listed:

·Simple
– systems, in which we can easily associate the cause and the effect. This area
includes domains that are well-identified and thoroughly described in
literature; they do not require complex interpretation and there is a huge
number of resources that deal with them. When you buy a new mobile phone and
you want to configure it using the instruction manual, it means that this is a
simple domain (of course, as long as the manual is clear enough). In this area
you can use recipes, best strategies and models that you can easily and
directly put into practice.

·Complicated
– systems, in which there is a cause-effect relationship, but it is difficult
to detect it. Finding a solution to problems from this domain often requires expert
knowledge, a lot of experience and complex analysis. Apart from that these are
usually static systems or systems that are not really vulnerable to changes (if
there is a change, you can easily predict and analyze it). Examples of such
systems include a watch, a car or a house – they are static, but to create or
repair them we need some expert knowledge.

·Complex
– systems, in which there are no clear cause-effect relationships, because they
change with time. We can detect them through experiments and investigations
into the current state of affairs. Even expert knowledge does not allow us to arrive
at a solution, but we can use it to set the direction of investigations. Systems
under this category are live, organic and changing. Where there are people,
there are usually complex systems. Examples of such systems include a stock market,
a brain, the immune system, societies.

·Chaotic
– systems in which there are no cause-effect relationships. We cannot detect
them, because they do not exist. Examples of such systems include all emergency
situations, fires and disasters.

·Disorder
– a situation in which we are unable to define the type of the system that we
deal with.

How does it relate to software development?

Below you will find a couple of examples. We have a simple system
whenever we have a first-line support. The client calls us, because he/she does
not know how to add another lead in the CRM. First-line support worker leads
him/her by the hand and helps solve the problem (which could be solved by the
client if he/she spent more time on it).

Another situation. You want to install additional software on your PC.
It turns out that it requires drivers. You download the drivers. Next you
install them. It works. This is an example of a problems from a simple system.
But let’s assume that you work with a Linux-related OS and to install the
drivers you have to recompile the kernel. A common user just won’t manage. Thus,
we enter the area of complicated systems.

Most of our development job revolves around complicated systems. Container
and development system configuration, authorization, authentication. This is
expert knowledge that we need to develop software. On the whole, in its basic
form design and programming are complicated systems as well, but… Yeah, but
that’s not so obvious. Let’s assume that you program for yourself, you are the
source of requirements, you write a piece of code that you can complete in 10
hours or so, and your code will mostly remain unchanged. This is a complicated
system. Even when we consider a serious long-term project (at least a few
months’ long) and we are lucky enough to have requirements that are well-defined,
settled and do not change, we still deal with a complicated system.

Talking about maintenance we can also talk about complicated systems,
but only on condition that the system that we maintain does not develop (our
work boils down to fixing the bugs).

But if the situation is different, i.e. the requirements change, they
are specified in the course of the project, or the project participants change,
we have a complex system. In such cases programming – both the design and the
code – has to be perceived as a complex system. I think that we are all aware
of the fact that most development projects fall into this particular category.

Of
course, some of them are chaotic systems as well. It is so if there are no
rules, the team works ad hoc and most of the work boils down to putting out
fires. This is chaos. Both literally and metaphorically.

What does it give us?

Exactly. Theory will always remain theory. There is one important
question – what do we need it for? According to the Cynefin model, when we define
the system, we can apply means that are context-dependent. These means are:

·The
main strategy

·Leader’s
activities

·Tools

Context

Strategy

Leader’s activities

Tools

Simple systems

1. Sense
2. Categorize
3. Respond

monitor the process,
standardize,
delegate,
use best practices,

best strategies,
5 WHYS,
manuals,
recipes,
PMBOK

Complicated systems

1. Sense
2. Analyze
3. Respond

form an expert panel
mediate

processes,
standards,
expert panels,
Kanban, PMBOK

Complex systems

1. Probe
2. Sense
3. Respond

leave space for the team self-organization,
improve communication,
empower

act and conclude on this basis, communicate in a simple and unambiguous
manner,
command and control

do whatever,
intuition

Practically speaking, it is impossible to classify a project into one
type only. Contexts are mixed, but there is usually one dominant context. If the simple or complicated system dominates, PMBOK
tools will be useful. If we deal with a mostly complicated or complex systems, Agile and Lean/Kanban tools might help.

Summary

As we could
see, Cynefin gives us a way of seeing the complexity of problems that we come
across. It divides them into four main areas and suggests some workable actions
to take. Thanks to it we know that a self-organizing team does not have to be
the best solution in each development project, and that in the case of chaos
the best way is to use command-and-control management. Chaos might result from frequent
and unpredictable changes in the project or in the team. Alternatively, it may
be a natural consequence of poor skills of the team members. On the other hand,
however, in predictable environments you don’t necessarily have to struggle to
use Agile as the only justifiable solution and classical methodologies
might prove ineffective in complex domains.

Nevertheless,
Cynefin is not only a model – this is also a set of strategies that we can use, especially in complex domains.

But... life is not so simple though. The model itself doesn't give you direct answers. Even Dave Snowden is not always sure were to put some software development practices (you can dig into his blog here). On the other hand it is a quite interesting perspective you can take into consideration while making decisions.

About

Has been a software professional for more than 10 years. Passionate about learning from experience especially when dealing with real-life software projects. As a trainer and consultant works with top Polish teams on process agility, clean code, architecture and effective software practices. Co-conducts in-depth researches on critical success factors in software development. At top of that Mariusz has published dozens of articles in Software Developer Journal.
His motto is “In most cases it’s all about people” what drives his focus towards communication and team members cooperation. Domain experience: Telco, Finances, Insurance, Manufacturing, E-commerce.
All the content here is copyrighted to Mariusz Sieraczkiewicz 2008-2013. If you want to use it, please contact me.