by ·0 Comments

During the Unexpected Meetup: 1st Open Space I had an opportunity to discuss the topic of changes with fellow Scrum Masters / Team Leads / Agile Coaches. Here are some notes (subjective and incomplete):

  • Books to read:
    • Our Iceberg Is Melting
    • More Fearless Change
  • You shouldn’t expect that your team will come with new change proposal every day. It will be rather your task to help them to discover that some changes are required and decide that they are worth the effort.
  • External experts can really make a difference. Somehow people from the same company are less credible (“No prophet is accepted in his own country’)
    • New hires – especially if they are seniors – are treated similarly to external experts. At least for some time.
  • Imposed changes are much less effective than grassroot changes.
  • No sense to order changes (e.g. “you will do the pair programming 100% of time starting today!”). Much better is to show the idea and let people use it at their own will.
    • Onboarding (especially with fresh devs) is a great time to inject some desirable behaviours.
  • A nice way to introduce a change is to run an experiment (e.g. “Let us do the pair programming 1 hour per day for 2 weeks. Then we decide whether we like it or not”.) Be prepared that people might not like the change. But this is fine.

 

by ·0 Comments

I was addicted to email checking. Or maybe I should say that I still am the same way an alcoholic doesn’t stop being alcoholic, he merely doesn’t drink anymore. So let me say I’m still emailoholic who checks email in controlled manner. Or at least, one who tries to achieve the inbox zero.

Checking email often was exhausting, pointless and stupid. I didn’t like it, so I decided to put an end to this bad habit. In fact, there were two goals I wanted to achieve:

  1. stop checking my email account too often,
  2. don’t let the unanswered emails pile up in my Inbox.

Interestingly these 2 things come together – at least for me. The thing is, that I used to check my email when I had no time to handle it. This had two very negative effects. The first, and an obvious one is, that I was thinking about answering my emails right after I checked my mail account. This disrupted my work, family life or whatever else I was doing at the moment. The second, less obvious effect is, that sometimes I hadn’t answered to emails at all (or I did this after very long time). This one is harder to explain, but my theory (uh-oh, big word!) is the following. There seems to be a certain good time for some things. A book should be read right after you buy it. If you don’t start reading it immediately, you probably won’t read it at all. Similarly, an email should be answered right after you see it.

So, in order to improve the situation I took one resolution: I will check my email only if I have time to process it right away. This means saying no to:

  • email checking while my code compiles,
  • grabbing tablet on my way from dining room to the kitchen only to check my email and put down the tablet on the table,
  • no quick checks in between other activities.

I started with the cleaning of my inbox. This wasn’t very hard, I had like ~40 emails there. Then I removed pinned tabs from my browsers. And hid the email icon from the front page of my tablet and phone.

Since 2 weeks I check email rarely (compared to what I used to do) – sometimes only once a day, sometimes few times a day, but the important thing is, that every time I do this, I make sure my inbox is empty before I switch to other tasks.

meme_email_inbox_zero

There are some issues, though. First of all, my email is also my personal database of various things. Sometimes I need to look there searching for something. To do it, I need to break my promise and take a look at email, even if I do not have time to clean it. Secondly, sometimes I have time to process email, but for some reasons I can’t – e.g. I need to consult something with my wife before answering, or I need to check something at home before I answer. Fortunately, neither of these happen often. Another issue, is that sometimes I wait for an email answer which I need ASAP – e.g. will I meet with X today or not? Then it is hard not to check my email every 30 minutes or so.

But all in all, it works pretty good for me. I’m not so obsessed with my email anymore. People who contact me by email should be also happier as they receive answers much faster than previously. I enjoy email-free evenings, and email-free-thoughts. My inbox is often at zero, and I hope to keep it this way.

Some time later

After 2 weeks – To get rid of unwanted emails I spent some time signing off from all kind of customer survey etc. This takes time (usually you need to log in to change your notification preferences) but I believe it is worth the trouble when thinking in the long term.

After 2 months – It is much easier (at least for me) to keep inbox at zero than to restrain myself from constant email checking!

After 2,5 months – I have never checked my email using phone or tablet. Yes!

After 3,5 months – Block site helps to fight the urge to check my email often. Not ideal, but helps.

by ·0 Comments

I performed a Journey Lines team building activity (as described by Lyssa Adkins) with various teams. In general, I was really happy how it went (and so were my colleagues).

The idea of Journey Lines is that each of the participants draws a line showing ups and downs of previous jobs. Each chart contains also some additional information like technologies used, skills acquired, names of companies they worked for, or any other comments that people find important. This activity:

fosters self-organization and cross-functional behavior because it reveals a person’s skills, experiences, background, etc. This way, the rest of the team knows what this person “brings to the party.”

Some observations:

  • Some people need to check LinkedIn to help them remember all the places they used to work (especially freelancers with short-term contracts really need such reminders),
  • The time required to tell the story differs – some people needed 6 minutes, for others even 15 seemed to be not enough (next time I will probably put some time constraints). The whole exercise took an hour (for 4 people team) and more than 2 hours for 8 people (including 15 minutes pizza break).
  • Even though this activity is intended to be used when forming a team, we played it a long time after the team was created and it was also fun & informative. Team members learned a lot about each other, even though they worked together for a long time already.
  • Personal things (marriages, kids) showed up rarely.
  • It was very interested to see how many different ways lead us to this particular company that we work for now. Also, it was funny to notice that in the past we all went through similar stages (e.g. freelancing during high school, hacking games etc.).
  • Some people draw really beautiful charts with nice fonts and additional drawings.
  • There was a lot of new things about each team member that no one knew before.

Probably the most interesting for me was to learn about the “down” moments (where the line of journey went down, down, down – often very abruptly and usually resulted in job change). There were few reasons for this:

  • people issues – stupid team lead / manager / boss can ruin even the best place,
  • stagnation – nothing new? maintenance and bug fixes for too long? people will look for a different place to work,
  • people leave their jobs when put in a position they did not want (e.g. someone was appointed a PM, another dev ended doing some office-management tasks).
  • a lack of vision (“why are we doing this?”) or lack of business impact (“we did it, but then they started to argue if they really need it, and it never went to production”) is a serious motivation killer

One more thing. I like this activity because it creates a symmetrical situation – “I show you mine, you show me yours”. Also, each participant can decide how much he wants to reveal. The only potentially intimidating thing is that at some point you need to stand in front of your colleagues and tell your story. But somehow, it hasn’t been an issue for any of devs I worked with.

P.S. Ask participants to write neatly on their charts so that later all can read it! 🙂

by ·0 Comments

It is almost the end of January, but I believe it is still a good time to make some New Year’s resolutions. Today I want to describe one of mine, which I believe could be a good fit for many of us.

As you know, it is very simple to make resolutions but much harder to fulfill them. So before I reveal it, let me tell you why I believe I will keep it:

  • it is not hard to do,
  • no special equipment/weather/mood required,
  • doesn’t take much time
  • requires only a little bit of preparation
  • I have heard many people saying it is a very valuable habit
and last but not least:
  • I have first started doing it and I already like it (and only later decided to make it my resolution – usually first you take a resolution and then you start).

And the resolution itself is very, very simple: I decided to perform a short (5-10 minutes) retrospective of my work achievements each week. Have I done what I promised (to myself or to others)? Have I worked on really important stuff or maybe I spent my time doing 2nd rate stuff? Have I started new tasks without closing the older ones? And so on.

In order to be able to do that, I take notes every day before leaving the office: few bullet points with major things I have been busy with. Then, on Fridays (I set up a reminder so I don’t forget it) I go through the notes from the last wee and ask myself questions. And then I write down some TODOs – like “do X – don’t wait any longer” – but also I praise myself – e.g. “good job with Y!”.

After three weeks I already have few observations and ideas:
  • Maybe Monday would be better, so my TODO list was kind of fresh and I would be able to jump into the action without waiting for the weekend to pass.
  • Why only work achievements? Why not introduce the same idea to my family life?
  • A week is kind of long, at least in some cases. Wouldn’t it be better to have it twice a week or daily to shorten the feedback loop? I’m not sure.
  • I do not have a good way of reminding me about the TODOs I created during the review. A sticker on the monitor doesn’t work for me – somehow after an hour it is like I don’t notice it anymore. Maybe I should set up a reminder for this as well so e.g. every day I got reminded about things I decided to do?
  • I have already been able to achieve some small victories (e.g. doing some stuff I have been putting off for weeks…) so I can say it works for me. So I plan to continue.
There is still time to change this year into something more valuable. Why don’t you give a try to this self-retro idea? I hope it helps you.

Cheers!

by ·0 Comments

Few months ago I published a list of books that I really, really wanted to read in 2015. 2015 is finished so I can now tell you how it went.

…and there isn’t much I can be proud of. Out of the 14 books I read.. well… around 3. Not exactly 3 because in fact I read 2 books and also halves of another 2 books. At first I was really disappointed when I realized this. But after some thinking, it doesn’t look so bad any more.

  • The list was published end of May 2015, which gave me only 7 month and not the whole year. Still the 3/14 ratio sucks big time.
  • I have read few books outside the list. Apparently, new topics (e.g. user stories) got my attention in 2015 and I decided to devote more time to them .
  • I have read numerous blog posts and watched many online presentations. It seems much easier to read/watch them than read a book. You can read a blog post during a short break but you can’t (or at least I can’t) read a book like this.
  • The books on my list were mostly about “background” stuff – things which aren’t urgent but crucial in the long term (think Eisenhower method important and not-urgent tasks). It is OK I haven’t read them all as long as I go back and pick one from time to time.

Now, what has it thought me?

  • Long list of books “to read in the nearest future” doesn’t work. I still have a list of “books I want to read one day” (and it is always growing and rarely shrinking) but I do not fool myself into thinking that I will eventually read all of them.
  • Sometimes reading a book is a waste of time – it is enough to read what others have learned from it (at this point it is hard not to mention Pierre Bayard’s “How to Talk About Books You Haven’t Read”)
  • I have very limited time for reading books. I should pick them wisely so I do not waste it.

I will end my today’s mumblings with the quote of Stanisław Lem:

“No one reads;

if someone does read, he doesn’t understand;

if he understands, he immediately forgets.”

Enjoy reading, folks! 🙂

by ·0 Comments

One year ago I blogged about a game we played during retrospecitve. A year has passed and it was time to open this “time-capsule”. No one guessed the right answer to all 13 questions, but some people were pretty close on many of them. Some questions got kind of outdated – e.g. we asked about the number of traffic-handling servers but in the meantime this functionality was split in two.

We liked the idea so this year we played it once again. The questions were similar to the previous ones but we tweaked them a little bit. Also, we invited our account managers to join the fun so the number of players grew to 14 (last year it was devs-only event, and there was only 9 of us).

P.S. Some people decided it would be fun to play it at company level so we prepared 5 questions and played the “New Year Predictions game” together. Will see what 2016 brings!

by ·0 Comments

So you have just developed this new feature and your application can calculate things. Some very, very important things. Business people are happy. …at least for few days. Then they start asking questions. They want to know how the numbers you give were calculated.

This is a recurring pattern that I observe.

For the first time it happened to me few years ago. Back then I was working on some fancy system which allowed to calculate bonuses for sales of financial products. Oh my gosh, how many (stupid) rules where there! And they were time-bound and they changed oh-so-very-often. Marketing people were adding new rules (new bonuses) for different products on daily basis.

The software used Drools (ver. 2.0 if I remember correctly) and had a nice GUI so users could create quite sophisticated rules by clicking. It worked like a charm.

…and then they started asking questions.

Of course they wanted to know! After all, it was all about the money. And every salesrep had his/her own excel with calculation. And whenever our system said they should get less money than what their excel calculated then they wanted to know how the hell we calculated our result.

An interesting thing is, that they were always wrong. They made mistakes. They always did. They forgot some rule was no longer holding when they made a sale. Or that some other rule was only applicable when sales was over 20k. Or that they needed to sell 3 items of certain type and they sold only 2. Really, this is the kind of mistakes they made.
And we never made such mistakes. We calculated money without emotions. Our answers were right. But it was not enough.

Lesson learned: it is not a valid result unless you can explain to users why it is valid.

So after having our perfect system working perfectly we spent few more days on making it output not only the final result but also how it was achieved. As far as I remember, we ended up with list of all rules with green dash (rule applied) or red tick (not applied) next to each rule. It was enough to radically cut down number of questions.

After this I got a little bit wiser and now, whenever I feel users might be interested in learning about the reasoning behind the final result, I try to think about such features from the very beginning (no, it is not a YAGNI, cause you definitely gonna need it).
And the thing is that often it doesn’t have to be anything fancy. Few log entries with crucial data used for calculation might be enough. If someone asks all you have to do is to find the appropriate log lines. Once you get tired with logs browsing you can think about exposing this data via some API or even GUI. But this can wait.

…and if you do not implement anything to explain the result then you will spend your time writing (No)SQL queries so that you can understand why the answer you gave to your user was 44. Good luck!

by ·0 Comments

I remember some time ago I was really excited about the idea of soft assertions. The latest blog post by Rafał Borowiec reminded me about them. …but wait, if I was so crazy about them some time ago, then how it happened that now I need to be reminded about their existence?

So first of all, I believe they make sense only for integration or e2e tests. Only, where execution of test is so costly (in terms of time) that you really, really want to learn as much about the tested scenario as possible. So, if you have a long (Webdriver) test, which ends with bunch of asserts, then I think it might make sense to write them using soft assertions.

But for unit tests? Oh no, you do not need soft asserts! Execution of such test takes milliseconds so rerunning them is simply a matter of few keystrokes using your IDE. Not much gained by soft asserts here.
And I also see a potential downside. I think that using soft asserts might lead you into the wrong direction: it might encourage you to verify much more then required, or to verify different thing “because you can”. No, thank you, I strongly believe you should go with one (logical!) assertion per test.

So, all in all, my initial excitement about the soft assertions has vanished over the years. I would never use them for unit tests, and I do not use them for other kind of tests. Why not? I think that when I first learned about them they were not supported by the tools so I gave up the idea. And later… well, I think I got used to not using them, and as I think now about my E2E/GUI/Integration tests I do not see compelling reasons to change my mind.

Just my 3 cents.

by ·0 Comments

We all know that rubber duck is programmer’s best friend (it was also proven that such duck should be yellow for maximum effect). Not surprisingly I have also a yellow toy on my desk. But it is not a duck. It is a little yellow human-like figure.

Usually it sits and waits for me to start explaining some code. It waits patiently till I get to the aha! moment. Sometimes it waits long. But it never gets bored. From time to time I can see it’s smile widens when I explain the nuances of my-oh-so-perfect-and-surely-working code.

2015_09_yellow_static

But that is something which every rubber duck can do for you. My yellow friend has one hidden superpower which makes it much more useful. Look at the next image. Awesome, isn’t it?!

2015_09_yellow_hold

See? When I take my laptop home my yellow friend makes sure next time I come to the office I won’t have to dive under my desk to catch the cables. Cool, isn’t it?

by ·0 Comments

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! 🙂