Recently I have spent some time thinking about teams. How it happens that few people become a team? What factors are at play? This is pretty important to me right now because few weeks ago I moved to a new team. And I want this team become fantastic. So there is plenty to think about and plenty to do.

As usual, when the topic is broad and vague I created a mindmap to put some structure around my random ideas. Here is the result.

2015_team

I have shared and discussed this mindmap with my teammates during one of the first meetings we had. It somehow helped us to realise that this is not about just sitting together. To become a team, a really successful team, we need much more.

In case you use XMind you can download the original file here.

So obviously such things need time. Group of people doesn’t become a team just like that. Unless they go through some pretty intense stuff like volcano eruption, Sharkando, or Amazon S3 breakdown. Since such things do not happen everyday (with the exception of S3 failures) there is fat chance that you will need few months till a team is formed.

What you can do is to create an environment to make things happen faster. Let us see what we can do for various aspect of “being a team”.

There is also a question of decisive power that your team has. Probably not everything is under your control. Your organization might impose some things on you. For example, there could be a rule that each team should organise retro every 2 weeks or that we all use XYZ as your build server. Also team structure might be imposed. Thanks God this is not the case for us, as we have a lot of freedom in how we arrange our working environment.

And last but not least: some of the things won’t ever happen if you have wrong people on your team (meaning you will never really be a team). As always: hiring is the king!

Structure

2015_team_structure

Roles might be imposed by your organization. Or not. What you can do here is to have a discussion. Like what roles do we need to fulfil our goals?. This leads to further discussion – do we really need a devops or can we handle the deployment on our own? Do we need a QA or can we keep the quality of the product ourselves?
Then comes more personal questions, i.e. what roles do you think you could take? or more generally what do you bring to the team? (what skills).

Such discussion might sound boring but it is not. If the environment is right and people are in good mood then there is some laughter and fun involved. It works. At least, it worked for us. We learned that some of team members would be very happy if we let them code and left them alone 🙂 Others do not mind configuring production environment and writing end-to-end tests. Good. At least we know what can be expected of whom. It is good to know it beforehand.

Skills and roles are obviously connected, but there is no simple one-to-one mapping. I see skills as a very broad term: it could be Java mastery as well as staying calm even in case of cryptic JavaScript errors.

Sharing

2015_team_sharing
Obviously we share a lot of time and space. Let us see about other topics.

Goals are interesting. Why do we exist (as a team)? What is the purpose? Where are we going? Would be nice to see if people see things similarly.

We talked about it with my peers. I asked everyone to write down the goals as he/she sees it. Not much discussion on the topic because it occurred we all see our team goals similarly (which is probably good). What was unexpected is that we added one more goal to our list: “have fun and write good code”.

As for the values we plan to discuss it as well. I guess this is a standard team-building-retro-exercise. What do we value? Speed? Code coverage? Fun? No-IDE development? Respecting each other? Whatever – would be nice to discuss it.

Exchanging knowledge is our daily bread. We talk, we talk a lot. In fact, currently we are rather talking than coding. Or talking while coding. Or coding while talking. Hard to say. Anyway. We are on the same boat now as we inherited some old projects to maintain (and new exciting features to develop). So sharing of knowledge happens all the time. And I hope we keep it this way.

And BTW. obviously one of the best ways of knowledge passing is pair programming. Or rather doing stuff together. Some time ago I assisted Łukasz deploying one of our applications to production. OMG, I tell you, I haven’t expected it at all, but I’ve learned a lot! It occurred Łukasz uses shell scripts to perform tasks that I used GUI for. Nice, really nice.

We also hope to share a similar coding style. We already started by discussing our DDD approach so that we all keep it consistent. One day probably you won’t be able to tell which one authored which part of code. Right now different styles of coding are probably easy to spot.

Feelings

2015_team_feelings
Hm, you can’t make people like each other. But if you haven’t hired some assholes it will eventually happen. Same with respect or understanding.

What you can do is to help by creating opportunities. For example go to a pub or eat dinner together so people learn/like each other. Or encourage to do intensive pair programming – it always induces some discussion, which usually entails understanding, which usually entails respect, which sometimes entails friendship, which sometimes entails love… errr… well, understanding and respect should be enough.
Anyway, even simply meeting and talking is a good start. Yes, it is. Find some excuse to move people away from their laptops and have some discussion.

Feedback is something we all crave. We have already established some strict rules regarding code reviews so we expect to get (and give) a lot of feedback.
I also hope one day to have a kudo box so we can compliment each other. And later on we will probably try some form of peer-reviews.

As for pride I hope we will be very, very proud of our code we write. Being proud of what we do and who we are means also that we will be willing to share our experiences with other teams.

Separate / mark out

2015_team_separate
This also requires time. We do not have any custom habits yet. Some artifacts are ours (e.g. kanban board) while other (e.g. build server) we share with others. And this is fine. Sometimes it is simply easier to use some common resource. What we did in the case of build server is that we have our own view which presents us only jobs that we are interested in. A small step but it makes the build server more as if it were ours, even if it is still the same machine shared by many teams.

As for meetings we already have them set. Regular daily meetings and retrospectives, and (not so regular) planning sessions.

Doing things together

2015_team_together
It is all about experiencing things together. Will see what the future brings.

Reasons to celebrate? I hope so. The thing is not to miss the opportunity to celebrate. Oh, you can celebrate even small things. I need to remember about this.
Production issues so we have to work overtime? I hope not, even though that would probably make us stronger (as a team). But it is not really something I’m looking forward, you know.

We definitely share a passion for clean code. What is left is that we need to agree what do we all understand by this. 🙂 But it will eventually happen as we code together and review what we have previously done.

This is it for now

This is not the end, but this is it for now. I hope you find some inspiration here. Good work building your super team! 🙂

Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink.

The book is all about motivation. It explains why the old way of carrot & stick does not work any more. And it shows the new motivation based on three pillars: autonomy, mastery and purpose.
I will not repeat what the book says, I guess you already know it from famous video (see below). All I want to say, is that even if you know the video, the book is still worth your time.

The most inspiring thing I have learned from this book, is the tiny little thing somewhere near the end of the book. It is about defining yourself with one sentence. Like, what would you like them put on your grave, or what would you like others to say about you. The author calls it a big question and it really gets big once you try to answer it. I tried and I answered it. And it explained to me why I do things the way I do, and it helped me to choose what to do next with my life. I hope it helps you as well.

2015_book_cover_drive

All in all, this is a great book. Doesn’t matter if you look for motivation for yourself, or you wonder how to help your team. In both cases you will learn something valuable. Read it!

When listening to talks during the last conferences I attended – ACE! Conference and GeeCON – I have noticed that there are some books which titles reappear here and then. I guess this is because they are worth reading. And I plan to read them in 2015 (omg, need some extra time for this!). I have added a short note to each of them to give you idea of what to expect of them.

  • Kahneman Thinking Fast and Slow – probably the most often mentioned book. Definitely a must-read! All kinds of cognitive biases brilliantly illustrated. (BTW. Now that I’ve read the book I still have no clue what to do with this knowledge, but that is another story).
  • Dan Ariely Predictably Irrational – we are not as rational as we think. Surprised?
  • Linda Rising Fearless Change – so you have this great, revolutionary idea? Cool, but how you gonna make others see it and follow you?
  • Laurie Williams, Robert Kessler Pair Programming Illuminated – seems simple but how to do it right?
  • Teresa Amabile The Progress Principle – you can make your work place more enjoyable (for you and others).
  • Giff Constable Talking to Humans: Success starts with understanding your customers – master the interactions with humans and the sky will be your limit.
  • Brian W. Fitzpatrick, Ben Collins-Sussman Team Geek A Software Developer’s Guide to Working Well with Others – coding is a team activity, so maybe we could improve our soft skills?
  • Tom DeMarco and Timothy Lister Peopleware: Productive Projects and Teams – oldie-goldie about the social side of IT work
  • Daniel Pink The Surprising Truth About What Motivates Us – the days of carrot & stick motivation are gone. Our motivation is of different kind. We are driven by mastery, autonomy and purpose. Read the book to find out more – you won’t be disappointed!
  • Tom DeMarco Slack – creativity can’t be rushed so you better add some slack, so it can happen.
  • Kotter Our Iceberg is melting – the fear of (inevitable) change is paralysing us, so how can we take action?
  • Chris Guillebeau The Art of Non-Conformity – be yourself and prosper
  • Ed Catmull Creativity Inc – add some creativity to the life of your organization – written by one of Pixar’s founders
  • Nancy Kline Time to Think: Listening to Ignite the Human Mind – attentive listening as the key to your business and social success

Last, but not least, there are also my books. I do not plan to read them, but maybe you will. See the links below.

cover_kanban_150_pl cover_junit_a4_150 cover_btgt_a4_150

P.S. You can read the follow up of this post here.

Few days ago I learned a very simple, yet powerful trick which saved me some time. To make long story short, it happened on a test environment shared between few projects.

I deployed a new version of one application there, and after some time received emails with errors. Uh-oh, apparently I have broken something! Hmm… but what really happened? The stacktrace hasn’t really enlightened me in any way… Hmm…. But you know what? The entity that was printed out in the exception message looked like this:
User{email='john.kowalski.somerandomstuff@whatever.com}

And it happened that John Kowalski was my colleague working on a different team (but using the same test environment). To solve the mystery of “why-oh-why-it-does-not-work-all-tests-are-green-for-gods-sake” all I had to do was to have a short chat with him. It appeared that he was running some IT-tests which were using some incomplete data (at least from my point of view), well, it doesn’t really matter. The thing is, that thanks to him signing his work, I was able to solve my problem pretty fast.

So don’t be shy about your IT/E2E test. Sign them, and maybe someone will be thankful for this.

And BTW if you would like to learn more about writing high-quality tests then check my Bad Tests, Good Tests book.

ACE! Conference 2015 is (unfortunately) over. Great time, great people, great event!

It was the first time I attended an agile conference, and I have to admit, I enjoyed it. I listened to few really interesting talks, and I had some interesting conversations with other attendees. There were also some very interesting discussions during the Open Space Market.

Some comments and things to remember:

  • Talk with people during breaks. Choose random victim and start the conversation. 🙂
  • Badges / achievements seems to be a cool idea (not sure if the link is right: http://signup.badgerbadger.io/)
  • Thinking Fast and Slow by Kahneman https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow was probably the most often mentioned book during this conference. All kind of biases were also mentioned many times.
  • Some conferences do WiFi right – ACE! did.
  • 250 people is a very reasonable number. The rooms and corridors were full but not overcrowded.
  • It seems there are at least few (small) companies in Cracow getting quite well with flexible working time, flat hierarchy, netflix-like culture, and some ideas taken straight from Jurgen Appelo’s books. Good!
  • You are very lucky if your team is collocated.
  • Some people like to work with stars programmer, while others would happily get rid of them (cause they harm company’s culture).
  • Many teams start with http://hipchat.com and then move to http://slack.com Never heard of any team moving in the opposite direction.
  • Do not build cool products but rather solve problems of your customers.
  • Feedback – important thing! https://www.psychologytoday.com/blog/psychology-writers/201206/giving-good-constructive-feedback
  • I loved the fact, that the organisers were able to improve some things the 2nd day, after reading feedback from the 1st day. Kudos!

My ugly slides are available at Slideshare:

It was good to see you there! Thank you all!

The question is what to do with the kanban cards after they were taken from your kanban board?

The simplest answer is to “throw them away”. Well, yes, sure, they are not needed anymore.

My colleagues from the next-door team (hello @tkowalcz!) have a different idea. The cards end up on a stake. Sweet, isn’t it?

2015_kanban_cards_fatality

And you? Do you have any creative/fun/useful idea of what to do with the finished cards? Please let me know!

The beginning of a year seems like a good time for some predictions. Today I planned a very short and simple game for my team to check our future telling abilities.
blog_future_telling

(picture from http://freedomwatch.ipa.org.au)

I have printed out a short form with some questions related to our product and the team. The questions were are aimed at the end of the year (Dec 2015). I have prepared a mixture of technical and “team” questions, for example: “how many TPS we will handle at the end of year?” or “how many kids will we have in total by the end of 2015?” etc.
There were 13 questions in total, all to answer with simple yes/no or a number.

I have also provided a data sheet which described the situation right now so it would be easier to predict.

And now what? Well, I have gathered the answers and put them into an envelope. They wait for Dec 2015 when we open this “time capsule” and have a laugh. 🙂

P.S. The best “future teller” will be appointed the task of doing estimates. 😉

P.S. 2 – Short info about the results is here.

I’ve been reading “Thinking in Systems” by Donella H. Meadows recently. A good book, definitely worth my time (and yours probably as well). Among many interesting things I have found three, which draw my attention, because of some IT/programming connotations.

Big Black Box

Well, yes. A poem. It is about systems, but fits quite nicely to some of our experiences with software. So here it comes:

Kenneth Boulding (published in “General Systems as a Point of View”, 1963)

A system is a big black box
Of which we can't unlock the locks,
And all we can find out about
Is what goes in and what comes out.
Perciving input-output pairs,
Related by parameters,
Permits us, sometimes to relate
An input, output and a state.
If this relation's good and stable
Then to predict we may be able,
But if this fails us - heaven forbid!
We'll be compelled to force the lid!

You See, You Care

In the book there is a short side-story about some Dutch families. To make this extremely short, I will tell you only that the electricity bills of families in the same neighbourhood differed by 1/3. All of them lived in very similar (if not same) houses. The only difference was the place the counter was located – in some cases it was hidden in the basement, while in other cases it was somewhere near the entrance. The “basement families” paid about 1/3 more than the “entrance families”. Why? The explanation is, that seeing the counter moving caused people to think more about the energy (and money!) saving. Period.

When I read this, the bell rang in my head: information radiators! It might be, that just by looking at the status of CI jobs, or some important production metrics, we tend to care more about the products we create. Wow!

Drift to Lower Performance / Eroding Goals

Another interesting point taken from this book is about the systems drifting towards low performance:

“Drift to low performance is a gradual process. If the system state plunged quickly, there would be an agitated corrective process. But if it drifts down slowly enough to erase the memory of (or belief in) how much better things used to be, everyone is lulled into lower and lower expectations, lower effort, lower performance.”

And the “way out” of this trap, is to “keep performance standards absolute”. Avoid excuses like: “Well, we’re not doing much worse than we were last year.” Avoid lowering your standards because you are out of time. Keep them high.

From time to time it is good to see what are the latest versions of the libraries you use (because maybe you would like to upgrade). You can use the Versions Maven Plugin like this:


mvn versions:display-dependency-updates versions:display-plugin-updates

but the output is too verbose. And for multi-module project you will get flooded with same information about each module (cause if you use not-the-latest version of e.g. JUnit, then it will be reported for each sub-module).

In order to make your life easier you better create a bash alias (~/.bash_aliases) like this:


alias mver="mvn versions:display-dependency-updates
 versions:display-plugin-updates | grep 'INFO' | grep '>' | sort |
 uniq"

and then after you run it, you will see something similar to the following output:


[INFO] cglib:cglib ............................................... 2.2 -> 3.1
[INFO] com.googlecode.flyway:flyway-core ..................... 2.0.3 -> 2.3.1
[INFO] com.google.guava:guava ................................ 16.0.1 -> 18.0
[INFO] javax.mail:mail ................................... 1.4.7 -> 1.5.0-b01
[INFO] org.aspectj:aspectjweaver ............................. 1.7.3 -> 1.8.2
[INFO] org.springframework:spring-webmvc ..... 4.0.6.RELEASE -> 4.1.0.RELEASE
[INFO] xml-apis:xml-apis .................................... 1.4.01 -> 2.0.2

There is still some room for improvement but it works good enough for me. I hope you will find it useful as well.

Cheers!

Recently during the lunch at work, we have discussed the operating systems. You know, the usual Windows vs. Linux vs. Mac stuff. The discussion wasn’t very interesting, because no one opted for Windows. 🙂 So, lacking an opponent, we moved to some Linux related issues.

2014_09_flame_war
[from: http://guide.notizie.it/come-evitare-una-flame-war/]

During the discussion I realized how I do not give any damn to the graphical desktop environment that I use. I use KDE at home (I had to check if this is really KDE, because I wasn’t sure…) and XFCE at work. The reason I use KDE is very simple – this was the first desktop I used, so I stick with it, and that is probably why I use KUbuntu rather than Ubuntu. The reason I use XFCE at work is because the Kubuntu version available at the moment had some issues with VPN connections, and one of my team mates told me that his XFCE did this with one click. So I switched. And you know what? I haven’t noticed any difference (besides the aforementioned VPN connection). So I asked myself how this is possible, and how come I’m not affected by the quasi-religious wars between KDE, GNOME and others?

When I started to think what features I use and care about, there are only few that came to my mind. First of all I run all apps by using ALT + F2 (on my old Kubuntu) or “Windows” keys (on XFCE). Then I type “kons” and hit enter, which runs the konsole. After this I use the same key to type “fire” or “oper” or “calc” or “write” to run Firefox, Opera, OpenOffice Calc or Writer. I never use the Start Menu.
2014_09_firefox

My KDE has also this super cool feature that the same “window” which I open with ALT + F2 can also work as calculator. Which is pretty useful.
2014_09_calculator

I have also realized, that I do not give even the slightest damn about where the close button (X) is located – in the top right corner of the window or in the left one. I remember there was a long flame war about this, since some version of Ubuntu broke some unspoken rule (“You shall have your close button here, and never there, or the fire will consume your dark soul.”). As long as ALT + F4 works, I do not need to click it.
Ah, a nice settings panel for dual monitors is also very handy.

One more thing is that, I never got convinced to used any file manager (Konqueror, Nautilus or whatever they are called) and always install Krusader (which is quite close to Total Commander – the best app for Windows ever written). Twin panels kicks ass of one window. Period.

The rest does not matter to me. I do not care about any fancy settings, windows animations, cool screen savers. I do not care about plasma beauties. I switch all such things off if they bother me, or let them be if they don’t. I do not even use different workspaces/desktops – two monitors are good enough for me. I ignore the possibility to change the location or width of the task bar, and ignore the plethora of options it comes bundled with.

So, all in all, I think I use only a small subset of what graphical desktop managers provide. Is it because I’m only a dev, who cares only about his IDE and konsole? Or maybe this is because more and more application run using the operating system provided by web browsers, so the graphical desktop managers are not that important anymore?
I even ask myself what would happen, if I had to use something as ugly as Windows 3.1… And I come to the conclusion, that I wouldn’t care that much. But this might be not true – probably I feel better looking at the nice icons of current KDE/Gnome/Unity and having smooth animations when a window is opened, but I just do not realize how they influence my user experience.
2014_09_windows31