... and what if you are just a small planet at the edge of Milky Way

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.

(photo: http://horoscope.com.sg/wp-content/uploads/2013/01/shiningstar.jpg)

Read More

Unknown 10:39  2 comments

Building knowledge in a team. Main mistakes and strategies.

(This is translation from original Polish post)

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.

Below you will find a short cheat sheet (click to enlarge).

Read More

Unknown 14:40  No comment

If you were to do one thing, it should be...

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.

(Picture from Multitasking Name Game manual).

Read More

Unknown 08:12  No comment

Simple, complicated, complex and chaotic systems, in other words Cynefin. And how does it relate to software development?

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	trials, experiments, discussion, limited self-organization, Agile, Kanban
Chaotic systems	1. Act 2. Sense 3. Respond	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.

Read More

Unknown 11:05  3 comments