Edge of Chaos

One wouldn’t normally relate Valentine’s Day to the office life of developers, designers, QA people and other guys involved in software development process.  Such qualities as love, compassion, care and empathy do not obviously stand out as prevailing in our work. It’s mostly rough and tough. The word SCRUM is actually derived from rugby, a guys-only sport where the winner is the one who stands tough and pushes hard. As people work to create software, they quite often tend to be unyielding, protective of their opinions; they’re used to pushing, and sarcasm often comes out as closest to ever having any empathic perspective on your colleagues.

Have you ever been in such a situation, as  a designer or as a writer or as a developer that you’re given a task, you work on it all alone, you come out with more and more drafts, and everyone seems to be criticizing your work? It takes stamina and a good deal of emotional stability to be able to withstand sometimes pushy remarks. No, I don’t mean to say that colleagues intentionally want to make you feel resented. All they want is to get work done, and their comments have the sole purpose of helping you complete whatever you’re doing as best as you could. They’re beta-consumers, the first to take a look at what you’ve created, before you shoot your design or a piece of text to the outer world.

Here’s the point.  Like I mentioned in one of my previous posts, we’re a company with trust established as one of the signature values. I’m not showing off, just citing the fact. So, a possibility that someone is saying something to hurt another person, is totally left out.  However, even in this healthy environment, and with all the love for the work that people have, the universal laws of  biology have a life of their own. The work is demanding, creative, and even as rewarding as it seems –  your brain and your neurons just get tired. It’s purely physical. People are made of flesh and bone, they’re not made of hardware. With this tiring, people become hypersensitive to the remarks about their work, and may start taking them personally.  One can’t get away with it.  So, I’d like to highlight the need of awareness about this quality of human psyche.

If a colleague is fatigued, stressed out about some work, or if some personal factors add up to the stress, what if we try to feel the challenge that our fellow human is undergoing, and instead of being purely work-focused, give a little bit of personal attention and some help to each other? It’s not that hard really. Sometimes, if someone is stuck with a design draft or something of that kind, instead of giving some remarks on what this person does, wouldn’t it be wise and nice to switch the focus from judging to helping? At the end of the day, it’s not only about helping your colleague. It does contribute to the task at hand. You can save your colleague by dropping in new fresh ideas, or see if there’s any other way to help him or her. If you don’t know how to brighten up the life of someone who spends their days near you in the office space, go ahead and find out. Wipe the dust off of your right brain hemisphere or the heart chakra or whatever other scanners and sensors you could put to test for the other folks . This would also provide a side balancing effect for your own brain, giving it some rest from analytical tasks for a change. Maintaining the culture of compassion in a geeky environment might look like a weird idea, but what your company is worth if it’s not about people? People are the greatest asset, but somehow they’re not usually  treated as such. So, is there any other better day than February 14, 2013, to emphasize the need for human relating, as well as the need to be more loving, compassionate and non-judgemental about others?

Happy Valentine’s Day everyone!

In the first part of the series on agile retrospectives, I mostly focused on the visual inventory as I went over the reports and charts we’ve been using at TargetProcess, along with some stuff from other people. I’ve also given an outline of the heuristic, trial-and-error approach as the essential methodological foundation for running retrospectives.

In the second part, it’s time to look into the secret nuts and bolts of what actually makes retrospective meetings work. I’m stepping out to embrace a broader picture, as the subject of company culture — it’s exactly about the quality of this oil that makes the retrospective engines run — is limitless. It can’t be reduced to a few worn-out, cliched how-to adages.

Maturity and the culture of trust

A team has to be mature enough to hold retrospectives. One of the common pitfalls is when teams are eager to run retrospectives just for the sake of running retrospectives. They know that if they are supposed to be agile, they need to do retrospectives. But it’s not as simple as following a guideline. The need has to come from within. The team has to develop this intrinsic feeling of power to solve their problems and – even more important – to accept the responsibility.

So how would you know if a team is mature enough to run meaningful retrospectives? If it’s not, how do you go about nurturing such a team? Do you have to bother at all?

First and most, it’s about the no-blame culture. Well, it’s better in the positive, not in the negative, so let’s put it like that: no-blame culture is the culture of trust. Let me mention here  that  trust is one of the signature values in our company.

The culture of trust emerges from a dozen of subtle ingredients. There’s no exact recipe as to how much of each ingredient you should take and in which proportion. It’s not a cocktail, for better or for worse, but it does bear some resemblance to a cocktail, as oftentimes you’ve got to stir, or even shake it well before enjoying!

Communication: tell me who you are, and I’ll tell you who I am

Following the lines of cocktail making, communication appears to be the basic ingredient of the culture of trust.  I completely agree with the point of this article that “lack of communication” is an umbrella term for all kinds of hidden conflicts and unresolved issues.  It represents an antithesis of the culture of trust.

So, if in your company “lack of communication” is light-heartedly referred to as the common excuse for troublesome issues, that’s when the red lights should go flashing, better yet with the fire alarm sound.  When people don’t talk, or misunderstand each other’s messages, or are reluctant to spend time explaining their point of view– this is the surface skim of what can be a severe turmoil of contradicting values, assumptions and beliefs.

For a certain time, this turmoil might simmer as a dormant volcano, but the eruption can come at a bad time, when everyone assumes the volcano is asleep for good.  At a retrospective meeting, for example, in the form of finger pointing:

Finger-pointing, it seems, falls short among the other consequences of the notorious lack of communication. Look, if tons of paper and web pages have been wasted to research/discuss this problem through and through, but it still persists — it means that avid readers are missing the point in their own organizations, being either short-sighted or far-sighted, or sometimes even both.  It also means that some essential things are left off from those writings, as for some reason people fail to fix the glitches once and for all. That’s because they don’t get to the bottom line.

For now, I’ll take just one  cultural pitfall related to retrospectives and meticulously dissect it, tissue by tissue (surgical metaphors seem to fit better here than cocktail recipes).

The pitfall: no one wants to attend retrospectives

All right, about this one. Some common tipsy-tricksy symptomatic cures and surface reasons for this pitfall I’ve seen in some books include:

• people don’t want to spend too much time on a retrospective, that’s why they rather stay away, so let’s set a time limit of 1 hr (insert 0.5 hr etc.), and this will fix it
• no one wants to attend because it’s soo boring, so let’s make retrospectives fun! Let’s go somewhere outside and invite some clowns so they entertain us, or let’s have gourmet chefs cook delicious food for us. Only then a retrospective will work.
• people don’t feel relaxed enough. They’re shy to speak up, they experience social awkwardness, so let’s do a group therapy session with a set of relaxation exercises.

How does that sound? Shallow, at least. So, I’ll run the chain of whys to find the underlying deep reasons (see the first part for another example of the whys technique).

No one wants to attend retrospectives. Why?

They believe this is a waste of their time. Why?

They decided to take some actions at the previous retrospective, but it didn’t work. Why?

Everyone seems to be fine with the current setup. Why?

… and so on. Most typically, the chain of whys will uncover one and the same issue: a retrospective is not a meaningful activity. Sometimes, a retrospective is just a ritual the team leader or the CEO is following to do agile by the book, while in reality they’re well aware of all the problems, and already have some solution in mind. So, a retrospective in this case is more of an opinion-check meeting to sense the atmosphere in the team, and to see if the leader’s decision is aligned with the expectations of the team or not. Of course, it’s not all black and white. The authoritarian leadership style is hardly viable anymore, but some annoying breadcrumbs of this style can cause cultural itching. Nor an utterly team-based ruling will make it work ultimately.

A report from the trenches

I’ve already mentioned briefly that we’re now working on the new version of our product, and we’re back to doing  retrospectives. Recently we’ve had an intense 16-day span called Subbotnik to come up with what turned up to be a private pre-beta (not even a beta so far).

So, there was a retrospective, and the team along with the Scrum Master decided that we’re now doing it in a milder mode, with good old 2-week iterations, and even with a burndown chart. Also, there appeared to be a deadline (something unheard of in our company for several years), so people somehow decided that we need to suspend the IDP (Individual Development Program) until we release for the deadline.

A side note: we have an individual development program, similar to Google’s famous 20% time, and this is one of our signature practices based on the essential company values. Maybe the Scrum Master was too rigorous in propelling his methods to reach the desired outcome, or the team believed that this deadline is indeed a matter of life and death, either way, they decided they’d suspend the IDP until that deadline. There were signs of the latent simmering, and after some get-to-the-bottom-of-it discussions it’s been finally made clear that we are NOT actually chasing any particular deadline, we just need to do it as fast as we can, until it comes out good (in short), and we will not sacrifice the IDP practice to this deadline.

This is a very characteristic example, a perfect specimen of “the lack of communication”. If the team and the Scrum Master were aware that there’s no deadline actually, they wouldn’t have opted for holding off on the IDP, as much as it means to our company. So, the lack of clear communication caused a slight shake to the cultural foundations, which later on might have developed into the subdued discontentment.

The core of this deadline/no deadline problem lies in something personal. It’s about the desire to come up FASTER with a great new version of our software, the software that is so incredibly helpful indeed.  If speed becomes an obsession, it can backfire with the unpredictable side-effects. Anyhow, in our case, the urge to deliver fast collided with the higher values, besides, we’ve learned that deadlines might only work for Subbotnik (the development practice we’re using to clean up residual bugs).

More analysis: we’re a company with the culture of trust. So, the issue of finger pointing hasn’t been affecting us much, from what I see.  But at times some communication glitches occur. Even with trust established as the core value, lack of communication might produce the effect of hidden blame placement. Generally speaking, for any production work, the people that one wants to criticize most are those who do not deliver enough information in the context of  tasks done together. This non-delivery of information, I think, is not an intentional evil act, it happens inadvertently. If someone is obsessed with speed, it wouldn’t occur to them that by keeping the latest update or idea to themselves they’re doing anything wrong. This is the case of too narrow focus, or maybe being too far-sighted, letting people out of the mutual loop.

You might ask: so what, what’s the solution? Is it just one more story about the lack of communication? Is there any real cure to it, other than the recipes fit for kids daycare? Note, that we’re still talking about agile retrospectives based on our IDP non-suspension case. The real cure is to get the point through to people who set the outer culture and the inner culture. Lack of communication would continue to be referred to as an all-forgiving excuse, until someone who is in charge truly gets that the side-effects violate company values AND in the long run slow things down,  not speed them up. That’s a paradox, very well known from the story of the turtle and the hare: Festina lente OR “Hurry up by being slow”, as translated from Latin. Things will not happen faster if you save those few seconds on not mentioning an important update to people who work all together, especially in a location that high. This famous picture brightens up the doorway in our office, along with some others, and I find it particularly fascinating.

To put it in other words, no cultural attitudes are shifted by a compulsory decision to follow some prescribed “shoulds”. The attitude might only change if an established behavior pattern is violating some higher meaningful values. I’m not giving any “how to make bad patterns change” advice intentionally, nor saying what those higher values could be. There’s no universal answer and recipe. Every organization has their own secret nuts and bolts, and in the end it all gets down to people, their personalities and interactions. Forgive me, my dear techies, but it’s about psyche and emotions, not about stats, graphs and calculations.  Binary thinking with its universal “wrong/right” -“good/bad” rhetoric has no answer. There’re countless subtleties and nuances. The point is to be able to identify the prevailing idea or sentiment or value, and go from there.

Here’s a simple life-based example, not related to software development or project management, just to show how “need” or “can’t stand this anymore” beats “should”. For my tennis practice, I have a set of balls, usually about 60 or so. They last for about half a year, sometimes longer, and then they need to be replaced with a new set. My latest set of tennis balls has been alive for almost incredible 12 months, and it suited me OK, because I’m practicing on the fast surface, and while old balls don’t bounce as fast as new balls (well, there’re different varieties, but this particular set had exactly that aging pattern), it’s almost like the imitation of the slow clay where you have more time to get to the ball and to make a good move. The fast bounce has some disadvantages, to cut it short, and it’s not what I’m focusing on at the moment.

So, my coach kept reminding me that the balls should be replaced, that they’re old and they bounce slowly. I kept dragging, finding excuses not to replace the balls, although, of course, I should have had them replaced weeks ago. Guess what did the trick to me? The sound.  Old tennis balls produce this particular “rotten” sound, and with my sensitive musical hearing, there came a time when I finally couldn’t stand it anymore, and took care of the replacement without further lingering. So, you can see that the “should” didn’t work, not until a higher value was challenged.

Single-Digit Teams and Mainstream Advice on Retrospectives

The closest I can get to a “how-to” style is as far as saying that a single-digit group (<10 people) is less likely to have communication problems, and more likely to act sensibly as a team, at retrospectives as well.  But again, organizations change and grow, and what has started as a small start-up becomes a mid-sized well-established business.

Back to the tips and tricks I’ve mentioned above. I can’t say that they’re good for nothing at all. Quite often, in a larger organization, there’s no real lever to influence culture shifts for people assigned to run retrospectives. If someone is confined in a certain space, like, a singled out task of doing a retrospective – then they would look for the ways to create some ado around this ritual, and operate in the limits for which they’re accountable. Role play, shuffling moderators, allocating fixed times, inviting clowns etc. — such advice is tailored to this very audience.

But I hope the awareness is there. The rituals do not set in motion the really powerful driving forces in a company. That’s what I’ve tried to outline in this part.

To be continued

Why do teams gel? Why some teams are trustful, enthusiastic and passionate; while other teams are apathetic and boring? There is no recipe to build a great team. You can’t add 5 grams of trust, 3 grams of fire, pour in some communication and boil till ready.

Why we need teams at all?

Working Alone

Team adds some new qualities in comparison with individual. When you program alone, you don’t need trust. Of course, you most likely trust yourself, otherwise you need  medical help. Besides you don’t need communication skills, if you speak to yourself very often you need medical help as well. All you need as a lonely programmer is problem solving, technical skills and passion to move forward. However, these are not enough to work effectively as a team.

If you work alone, you are free to make any decision fast. You have zero overhead: no meetings, no discussions, no phone calls, no questions.

If you work as a group of people (I mean, team), everything is not that shiny. Suddenly, you have to visit meetings. You have to participate in various discussions about technical issues and solutions. You have to answer questions and sometimes you have to do things you disagree with. Is that all so awful? Yes, it is.

So, why people do form teams? Simply, to solve problems that can’t be solved by a single person. Team is a necessity and it suddenly brings more formality to problem solving:

You have to communicate to have aligned vision. Otherwise you will solve two parts of the problem differently and solutions will not fit.
You have to coordinate work. Otherwise you will have huge delays and inefficient process.
You have to find common language to understand each other.

Team brings an additional overhead.

Working as a Team

In general, an effective team reduces overhead to minimum and lets people really solve problems and focus on main activities (I mean development). If we think about team from this interesting angle, we can easily find good practices to  improve team’s efficiency:

• Less people. Small team has less overhead.
• Common language. All should understand each other as quickly as possible. That is why offshore teams have huge problems.
• Less meetings. Ban all meetings and activities that don’t help to solve problems.
• Minimum people on meetings. Invite only those people who can really bring value to problem resolution
• Team isolation. It is generally a bad idea to have 2 teams working on different projects sit in one room.
• Fast communication channel. In general, the goal is to have less communication. Really. It is. It means if you have to discuss something, you should do that using the fastest available way, and it means in person talk most likely near a whiteboard.

But. Improving team’s efficiency, we can easily decrease team’s creativity. It may happen that team will solve problems quickly, but these solutions will not be the best. It may happen, that some unstructured chats about stupid things cause a genius idea. We can’t predict what will help us to find a really cool solution. Most likely we should not strive for complete rigid team that communicates only about problems and solutions. There should be a slack, and it is always there. People instinctively feel that unstructured chats are good and helpful sometimes.

Trust

You can’t have a good team without trust. Why? Simply because trust reduces communication time and helps to solve problems quickly. Imagine a team where people don’t trust each other. You immediately have political games, suspicious questions, indirect wording and rounded phrases. You have hidden conflicts, but polite discussions on a surface.

If you come and see this team in action, you will be astonished by stupid decisions and dumb solutions. Everybody’s goal is to cover his ass in such an environment.

Trustful team doesn’t spend time on all that shit. Discussions are hot and straight to the point. People can even scream on each other sometimes, but if they trust each other it does not really matter. They critique bad decisions fearlessly and don’t hesitate to provide fresh ideas.

Trust saves time on communications and leaves more time to do the real job.

Passion

We all saw people with extinct eyes. We all saw boring and semi-dead teams that work from 9 to 7 and can’t wait to leave the office. Nobody wants to work in this place. But still many do. I personally can’t understand why people do that. I don’t accept any usual arguments like stability, money, habit. I can’t work in a boring place on boring projects. It is not fun, it is not interesting, it is not valuable.

Passionate team is built from passionate people. That is it. They really care about what they do, they focus on real problems, they do everything to improve things. Passion is an ultimate team’s engine. No passion — no drive.

Wrap Up

Great software development team is built from passionate skilled professionals that trust each other. They collaborate effectively to solve problems and improve team work.

Our company is quite small (25 people). Most companies of this size focus on rapid growth and don’t pay much attention to learning. We are different. Fortunately, learning is very important in our company. We boost it in all possible ways:

• We highly encourage people to try and learn new things.
• Every employee can dedicate up to 12% of their time to unstructured learning (5 hrs per week).
• We organize internal trainings twice per months.
• We organize so-called Friday Shows every other Friday where we watch and discuss some interesting videos about UX, development, business, etc.

About a month ago we decided to structure our trainings in a better way. The resulting idea was internal mini-conference. Mini-conference is a full-day event dedicated to sessions and discussions. All sessions are prepared internally. The idea is to have a very focused learning event instead of several trainings over 2 months.

Our first conference will take place this Friday. Here is the program

10:00 Registration, “wake-up” coffee
10:15 Data Visualization Alex Tsayun /45 min
11:00 coffee break /15 min.
11:15 Node.js intro Vadim Gaidukevich /30 min
11:45 MongoDB (NoSQL) intro Oleg Seriaga /30min
12:15 coffee break
12:30 Exploring Good Experience Seth Godin (guest video) /20min
13:00 History of Kanban Anton Marchenko /30 min
13:30 lunch
14:30 Performance Metrics Alex Fomin /1h
15:30 coffee break
16:00 Marketing and Sales @ TargetProcess Andrey Mihailenko /1h
17:00 free discussions.

I am really curious about the outcome. Wil people like it? Will we keep this practice? Not sure. But we are trying new things :)

If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc.  Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives.  Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences :)

I tend to think that with all the  information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile  - it’s hardly that something will be totally new to you (“totally” is the keyword).

Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) .  As opposed to most attendees,  I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team :) I’ve seen a bit of those “paper sword fights” :)

After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way  (including live jazz night in Krakow).

This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration.  In a sense,  that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire  even if this is your first experience as a speaker.

And.. it’s great that there’re many more agile conferences to come :)

Recently I’ve read a very interesting post by Anna Forss called “Stupidity of the Team”.  While Anna concludes, that it’s healthy to introduce diverse opinions and invite opposing minds to dissolve the like-mindedness of homogeneous teams, I think there’s one important nuance that shouldn’t be overlooked.

Let’s think:  teams exist for some purpose. To resolve some goals. If it’s a small product development company – then this team exists to develop a product. Permanent rebels are not welcome in any group – because what they do with their rebels, argues, drawing attention to themselves – they blur the focus of the whole purpose why team exists. Of course, a team will naturally outcast this person.  Next, if a team is bombarded by controversial opinions and judgments, they will spend all their time evaluating and thinking if this is right or wrong. They will get busy sticking tags on new opinions instead of focusing on their work – and they will inevitably lose their focus.

Life in a small development team can be compared to living in a sheltered reality, with it’s particular culture. An isolated sheltered reality will not last for long if it’s completely isolated, so emerging on the surface for a gulp of fresh air is really needed.  As a member of a small team – can you remember when the opposed rebels and opinions really did help? When they triggered something that the team would not have thought by themselves? Well, of course, if someone comes up and says – “your UI is bad” – then another person comes up and says – “your UI is bad” – then you start thinking that it’s indeed something wrong with it. You’ve got this signal from outside world. You work on it. Basically, you know what you should work on. The outsider’s opinion has accomplished it’s task – the outsider’s opinion can now go, because you’re not interested in hearing variations of one and the same opinion.  You get to work, and you work to develop a nice new UI.

There’s no need to focus on outsider’s opinions and pay too much attention to them. Outsider’s opinion is just a trigger to team’s actions – it’s not something that the team should busy their brains with all the time. In a way, diversity of opinions may be even harmful. I guess that’s why we’ve got leaders – authorities who tell the crowd “THIS is your Holy Grail”.

My conclusion is: healthy vaccination with opinions opposing a team’s culture is  good. But don’t overdo with them. Too many opinions will not increase collective intelligence for this team’s specific purpose, they will blur it.