by ·1 Comment

[Feb 2018: S3 changed the name from Effectiveness Review to Peer Review]

My comments written down after the 4th effectiveness review (ER) at Codewise.

First of all, the ERs are becoming “no-events”. I mean, people know what to expect (both the hero of ER and the participants). They come prepared, they know what to expect. Around 30 people already participated in the ERs (and few more decided to have one for themselves).

ERs Beg For Well Described Roles

During the S3 course I attended, I heard that implementing some of S3 patterns results in starting using other S3 patterns as well. I think I start to observe a little bit of this happening. The fact we started to run ERs initiated some discussions about our roles. Sometimes we are happy with what we have (usually old job specs from the ancient times when we applied for a job or we were promoted to certain positions) but in some cases ERs are a catalyst of discussion and changes. It would eventually happened anyway, but it seems it will happen sooner thanks to ERs.

The Development Plan

I observed a difficulty with coming up quickly with development plan. I struggled with this myself during my ER. It was hard enough to grasp all the improvement suggestions (there were ~25 of them) and rapidly creating a sensible plan out of them… well, this was challenging. I felt time pressure (10 people staring at me and waiting till I present a plan to them) and that definitely wasn’t comfortable.

Yesterday, I observed how the hero of ER was preparing his plan and I was under the impression that it wasn’t easy for him as well. One of the improvement suggestions he got was that he should delegate things more. So he added “delegate tasks” as one of the points of his development plan. I was expecting more concrete steps towards delegating, not only the promise of “I will delegate more”.

Can we expect the hero to come with some detailed plan just like that? What about the big tasks – like the one that “you should delegate more” – is it OK to have a development plan with point “I will prepare a plan of action on how to delegate and then I follow it”? Or maybe the hero should spent some time on the spot and try to figure out what would be the actions moving him into the desired direction (or at least the next step – like in the GTD method – to set things in motion) ?

The problems with preparing Development Plan might stem from the fact that this were our first ERs, which resulted in a gazillion of improvement suggestions. I would expect to have less of them next time we run ER for the same person (provided that we do not wait too long with it). If so, then preparing a development plan should be much easier.

Things You Learn About Yourself

One guy – let us call him Andy (a leader of one of our teams) – gave the following appreciation: “I really appreciated when you came to me to talk about X. It was good that you reminded me about this. Thanks to you X wasn’t forgotten.” I asked the hero after the ER whether he was surprised by Andy’s words. He said it was unexpected. He rather thought about his own actions in terms of being PITA (kind of: “Here I go to this Andy guy, to give him one more issue to solve, as if he hadn’t got enough of them already… He must hate me for this…”). Now he knows better how his actions are perceived by others. Valuable knowledge, isn’t it?

Hoping for More

We had only 4 ERs so far, and even though I believe they were pretty valuable, I do not want to call it a success yet. Let me wait with fanfares until we run few of them for the same people consecutively. Will we still benefit from them as we do from the first ones? Yes, let me wait before I call it a success. But what we have right now is a promising start. Good!

by ·0 Comments

[Feb 2018: S3 changed the name from Effectiveness Review to Peer Review]

Since the last blog post(see http://tomek.kaczanowscy.pl/2016/12/sociocracy-3-0-effectiveness-review/) we run 2 more effectiveness reviews (ER in short). This blog post gathers my thought, comments and lessons learned. Hope you find it useful.

Preparations.

Based on previous experience I took the following steps to make the next effectiveness reviews even more fruitful:

  • I prepared a document explaining shortly what it is and what is expected of the participants.
  • I tried to make driver & role description more visible during the meeting – so that the appreciations and improvement suggestions were more related to it.
  • Last time we ended the ER with development plan in form of some additional notes added to the “improvement suggestions” flip-chart card. This time I wanted to end the meeting with more explicit development plan (i.e. written down separately, so there would be no confusion on what was really decided).

Also, I created a short checklist for anyone who wants to run an effectiveness review (with some basic stuff like how to prepare room etc.)

Time

Recently I’m pretty focused on the meetings efficiency. I hope to run ERs regularly so I want them to be as concise as possible.

In one of today’s meeting I set some strict rules: we speak straight to the point, no discussions, no preamble, no starting with “Uhhmmm…. Well… so…. Of course I agree with what [name of previous participant here] said, because I also feel this is very important. And also I would like to add that …” (15-20 seconds gone, now multiply it by number of participants and number of rounds!). It worked wonders – we avoided a lot of time wasting talking and the whole event was much shorter.

However, later when I discussed the event with some participants, I learned that there are some downsides of this approach (excerpt from an email I got):

“I thought the meeting was slightly rushed with the onus being on short sharp bullet points of feedback however I think we could have elaborated on our points more and given examples which could help benefit the person.”

In general there is some tension between having an efficient meeting and allowing people “to do the long and non-value talking as they usually do”. Currently I value efficiency more (but I try hard not to be rude interrupting people etc.) Still, my approach could be improved – one person suggested that giving examples (context) for appreciations could be valuable, and I agree with this idea.

Anyway, I believe that with artful participation it is possible to have a very fulfilling first ER taking less than 30 minutes. I also think that the consecutive ones (for the same role) can take half of this time.

My learning also is, that if you clearly state the purpose of the meeting (easy-peasy in case of ER: first we do appreciations, then we do improvement suggestions, so in the end we can have development plan) then it is pretty simple to stop any discussion that is not moving us towards the goal of the meeting.

Taking notes

Taking notes sounds simple, but it ain’t so. After one of today’s ERs we had notes so good, that people who wern’t there would benefit from reading them. The notes from the second ER would be completely cryptic to someone who wasn’t there.

In general, I think taking good notes is a skill that could be trained.

As for now, flip-charts worked for us better than whiteboards. The notes on flip-charts were more readable. Not sure why – probably because the flip-charts offer infinite surface which encourages the scribe to write longer sentences (and thus achieve better readability afterwards).

My ER

One the ERs today was mine (“lead by example”, isn’t it?). I have to say this was a positive experience. First, it is really encouraging to hear the appreciations and learn that this thing, that maybe I was even embarrassed about (oh, no, I can’t bother them again with this, no, I really can’t), that they actually appreciate it. Second, the participants gave me some really valuable feedback on how I could improve. Some of the things I was aware of (“delegate more!”)  but some were new to me. And even for things I knew about it makes a difference if you hear it from few people. At least for me.

And BTW. I think I did a good job on selecting people – I took some close cooperators but also few “independent thinkers” that I do not work on daily basis but who are influenced by my job. Thanks to this, I got feedback from very different perspectives. 

I ended up with a 5-points development plan. Some of the tasks too big to be “action points” but rather directions I should move into.

During my ER I had this feeling that some participants are actually more nervous than I was. It seemed to me, that it was hard for them to express their opinion in a public setting. Probably my role might have some impact on this, however, I know all of the participants pretty well and we are on friendly terms, so I’m not sure where this hardship is coming from. Also, it seems that for some people it is awkward to give feedback in such public setting. No problems with appreciations, but improvement suggestions are hard for some. I wonder if this is only because we are not used to do it in such manner? Some also dream of good, old, corpo days when managers would handle the hard stuff (an excerpt from the email I got afterwards):

“Obviously its a lot harder to give more constructive criticism face to face so I prefer anonymous then the manager will collate all feedback.”

Final Notes / Random Observations / Concerns

Notes to myself on what to improve:

  • Work on roles – our old job descriptions we use instead of driver&role are not good enough.
  • We need more skilled scribes.
  • We need more skilled facilitators.
  • Sending email with guidelines for participants seems to work pretty well.
  • I still have no clue how to efficiently amend the driver/role during the ER meeting.
  • The 1-month frequency is not good for everyone. Need to be flexible with this.

Some doubts:

  • If the role is not clear enough then so are the improvement suggestions. So, first work on the roles.One of the concerns we have is the following. The ER concept seems to work fine when there are no major issues with roles. The atmosphere is friendly. How will it work if there are some serious issues with person in role? Will the participants be polite enough to express their doubts in form of civilized “improvement suggestions” or will the whole meeting divert into some kind of judgment and punishment for the hero?
  • In general I feel ERs are a valuable addition to what we do, and we should continue. However, I have doubts whether ERs are suitable for everyone. Will developers benefit from this kind of meeting? I’m not sure. I think in the case of many devs code reviews, 1-on-1s with tech leads and team retrospectives might be good enough.

by ·0 Comments

[Feb 2018: S3 changed the name from Effectiveness Review to Peer Review]

I rarely write about S3, but when I do, it is long and boring. 🙂

Below you will find my experiences with the S3 effectiveness review  – an idea that I borrowed from S3. I hope that maybe some comments that I share will help you to run yours. 

Ah, names of people are changed in order to “protect the innocent”.

So, there is this team, that was going some reconstruction, meaning people changed roles. And I thought, that maybe this is a good point to introduce some new practices (and I have to admit I was looking for some opportunities to introduce selected S3 patterns since I attended an S3 training with Lily & James).

Fortunately, John, who was appointed team lead, agreed to become my guinea pig. So here is what we did plus some comments/improvement ideas:

  • Started with the driver (why this team lead is needed) and with role description. All written down by John & me, and later reviewed and enhanced by another member of the team. We ended up with 1-page doc (used google docs which is nice for collaboration/sharing).
  • Decided to run effectiveness review once a month.
  • Asked Joanna – an agile coach from an agile consulting company (with some S3 experience) – to facilitate the meeting and help us prepare.
  • From the very beginning we planned (and John agreed) that this event will be opened to observers – I wanted few leaders of other teams to join us so they could observe and learn how it looks like (and hopefully want to introduce effectiveness review for their teams as well).
  • Since we had no previous experience, we tried to plan it very carefully. Joanna & me worked (shared doc again) to list all things to be done – like what kind of materials should be printed, who the scribe will be, what should we tell the participants beforehand etc. In short, we wanted to make sure this event will be well prepared, so that it runs smoothly.
  • I talked with every participant (selected by John) explaining the idea and their role. Also, I talked with all the observers. All received an email with links to:
  • We set the room so there was a circle of 6 chairs (for the main participants) and some places outside the circle (for the observers). We decided to take notes on flipchart.
  • The scribe, wrote down every appreciation & every improvement suggestion on the flipcharts. Tip: We used two different colors alternately so each idea was well visible.
  • We ended up with some action points for John (all related to the gathered improvement suggestions) for the next weeks.
  • After the event the scribe sent around all the notes gathered during the event
  • The whole event took us ~55 minutes. I think we can cut the length of this meeting by at least 10 minutes next time.

The results / comments / improvement suggestions:

  • Reception
    • In general this was well received both by team members and by observers.
    • I asked some team members how they feel about it. They say it seems really valuable.
    • Some comments from the team members like “a pity we haven’t used this approach earlier” (this team has quite a troubled past, so maybe such effectiveness reviews could had been useful).
  • What was good
    • Friendly attitude is IMHO crucial. The fact that our facilitator (Joanna) was beaming with positive energy helped a lot.
    • Asking “external expert” – Joanna in our case – to facilitate this event was a good idea.
    • It is very valuable to have different people participating – in our case we had 3 team members, a product owner, and IT recruiter. All of them had recently worked a lot with John. Thanks to this diversity John received very different comments. Good.
    • A note about transparency: as I said before we sent around the notes from the event. Surprisingly, this helped another team member (who wasn’t participating) to understand his situation in the team (do not want to go into details here, only stressing out the fact, that unexpected – and good – things happen after you let the information flow.
    • Flipchart notes worked very well. Recommended.
  • Emotions
    • One person told me he would probably die if it was his achievements being discussed in such public setting. This is an important information to me – maybe for some individuals we should go with something less public (kudo cards?).
    • John is a very open person, but I observed that he was nervous before we begun. Fortunately, he was doing a really good job recently so he received a lot of appreciations and this relieved the tension.
  • Next steps
    • I talked with the observers trying to persuade them that maybe, possibly they could also benefit from establishing roles and running such effectiveness reviews. One person wants this very much, others are more cautious, but in willing to give it a try.
    • And yes, we will definitely run the next session for John in one month time.
  • From the discussions with some observers we have this idea, that such effectiveness review might not be feasible for some roles – for example, we were wondering if for regular devs, this would give anything more than what they learn during daily code reviews & architectural discussions. Not sure about this one, will see.
  • When discussing the idea of organizing such effectiveness review for a specific person I heard that “in case of this particular person, such a very positively-aligned meeting could make things worse”.
    • The context here is that the person in question has a very high idea of his skills/quality etc. And since effectiveness review is pretty much about positive feedback it could result in even bigger ego.
    • Also, in this particular context, the idea that the person selects participants seems kind of dangerous – we could expect this particular person would select only those, who would praise him. I guess in such cases the list of participants should emerge from some discussion among e.g. person and his boss, and not based solely on person’s opinion.
  • Improvement suggestions
    • We should focus on the driver and role description more. We drifted too much from John’s responsibility to general ideas of team improvement. It was also valuable, but not exactly what we hoped for. Next time I want to have the driver/role visible all the time (overhead projector).
    • We need also to help people prepare even more than what we did this time. I think it is crucial to first have a good discussion about the driver and the role with the whole team. Also, all participants should understand that the meeting is about helping someone fulfill his role better. However, as for the first time I’m really happy with what every participant brought to the discussion.
    • We will probably ask Joanna to facilitate few more events but then we want to do it ourselves. After all, it doesn’t seem such a big deal.

That is all folks. Comments/questions welcomed! Cheers!

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

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

by ·0 Comments

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.

by ·0 Comments

Code reviews. Very helpful if done right, completely useless if done recklessly.

Below you will find a mindmap of “code review” (using Xmind). I simply sat down and tried to gather everything related to code reviews. Hopefully you will find some food for thought here.

2012_code_reviews

Some comments:

  • I knew one team lead (hello Marcin! 🙂 who had a very nice system of publishing code reviews by email to project’s mailing list. He believed (and had some good results to support this belief) that by doing such “public” code reviews he educates the whole team, and not only the author of the particular code. It worked for him and his team pretty well!
  • Marking code with TODO and FIXME during the review works pretty well for me. Nope, I haven’t used gerrit or any other tool like this yet.
  • IMHO code review should be a part of Definition of Done – no task is finished until someone else checked the code.
  • I don’t like the idea of team lead doing code reviews for the whole team. He has probably no time for this. The other thing is that some people find it hard to discuss with your “boss” (so they will follow blindly what the reviewer says). I like much more the idea of peer reviews. Even if some junior guys are not capable of performing code reviews properly (at least from the very beginning).
  • There is a great discussion regarding code reviews here.

by ·0 Comments

So I’m taking over a new project as a technical team lead. This team has been working for some time (for a long time). Now my task is to lead its further development. I’m excited and worried at the same time.

I spent some time wondering about what should I know about this new project and about the team. Here is the list of topics that I think I should gather some information about. Maybe someone else will find them useful. I also hope for someone giving me hints about things that I forgot.

I did not mention some obvious stuff like “what the project is all about”. The list is chaotic, but so am I. 🙂

Team

  • who? + characteristics + how long they work with the team + strong/weak points + maturity level / how independent they are? + maybe there is some BSC mechanism, if so, take a look at the previous records
  • language skills
  • contact – mail, skype/jabber nick etc.
  • working hours? anyone working half-time? anyone with unusual working hours?
  • where? one room or many places
  • some people from other teams involved? independent consultants? some project partners (external companies) that we cooperate with?
  • what are the roles of people
  • who knows what?
  • are team members involved in other projects?
  • questions to ask to each team member:
    • what are you proud/angry/annoyed about? what (de)motivates you?
    • please draw the architecture of the system
    • please write down the “definition of done”
    • what issues do you think we have? what is the most common source of bugs? which bugs are the most annoying for us / for clients?

Meetings / Telcos

  • internal (only the team is involved) – Scrum – daily / sprint / backlog ?
  • with clients
  • with higher-ups?
  • traveling? where? for how long?
  • how are the invitations send? who sends them? who sets the agenda? who sends minutes (if any)? who attends?
  • how long is the meeting? who participates?

Documents

  • where can I find them, how are they generated, who maintains them?
  • technical documentation
  • user documentation
  • developers documentation
  • reporting – internal / external
  • templates – documents? mails? reports? presentations?
  • bug tracker – how are issues commented?
  • where is the database schema?

Infrastructure

  • SCM, FTP/WebDavs, Sonar, CI, bug tracker, artifacts repository, wiki
  • keystores, certificates
  • mailing lists (internal, external)
  • adresses, credentials, who creates accounts? who administrates?
  • environments – local, testing, production?
  • Can anyone, besides the team, access any of these (e.g. client reading bug tracker issues) ?

Processes

  • SCRUM? how does it really look like? how are user stories sized – hours or t-shirts (M, S, XL)? what meetings, how often etc., are daily standups held regularly
  • code reviews – formalized, informal, who does them? peer reviews? external audits of code?
  • any visualization tools? (well, these are the easiest to notice, aren’t they?)
  • what is the “definition of done” of this team?
  • any special recruiting process for this team?
  • build process – automated?
  • How are versions/releases created? What is a naming pattern? Are there different internal (for team) and external (for client) versions? How can one learn about the changes between versions X and Y?
  • statuses of issues on issue tracker (e.g. todo, in progree, done, accepted etc.)
  • production deploy & rollback, tools used – Puppet, Liquidbase?
  • code conventions – format (Eclipse formatter?), checkstyle etc, but also use of TODO/FIXME tags in code
  • SCM (SVN/git) – branches? how/when created, when merged?
  • CI – schedules, how are they set?

Testing

  • unit
  • integration
  • end2end
  • does client test?
  • automation? which requirements functional and non functional are being automatically tested?
  • code coverage – how high, is it automatically calculated, is code coverage of different tests merged?

Development Tools

  • what tools/software is being used by team members
  • OS? IDE? build tools? testing libraries? mocking libraries? code review tools?
  • specific applications for Win (Visio?, Outlook?)

Problems

  • what we know? what are the main problems from our point of view? (e.g. internal code quality, our build process, client?), does client is aware of this?
  • recent problems, what were the causes, are they fixed?
  • what is the main concern of client?
  • common bugs, how many critical bugs, are they added to the current sprint?

Client(s)

  • communication – how do we communicate with clients? with whom exactly should I talk about certain topics? who has the right to make decisions?
  • communication – how does client communicates with us?
  • communication – what hours is he available? does he answer emails immediately?
  • what does he value, what are his goals?
  • does he own the code?
  • does he has a say in technologies we used, should we ask him for approval for new libraries/tools that we plan to use?
  • is it possible to negotiate the scope?

Next steps

  • What is the most pressing matter? Are we late with anything?
  • Any meetings/telcos ahead?

Architecture

  • software
  • hardware

question-marks_0
Questions, questions, questions… Surely there are many more things to ask and topics to understand when you join a project. I will try to use the above list for the task at hand. Will see if it turns out to be any good.

by ·0 Comments

When can you say that a task is done? This is an old topic but still important and still being discussed over and over by almost any team. Lately my team decided to come with a definition of done. This post presents our view on “what is ‘done’?”.

Introduction

We tried to address every aspect of development – from coding & testing to documentation.
BTW. the order of things on our cheat sheet does not determine the order of work. For example TDD is more than welcomed so it is not like tests come after the code. Similarly javadocs don’t have to wait for the finishing of code activities.
The important thing is that our cheat sheet groups all things that should be done in one place.

Another issue is to realize that you will never be able put every detail on such cheat sheet. If you want it to be readable you need to choose words carefully. The point is, that everyone should follow the spirit of the law more than the letter of the law. If there is a point on “code quality check with Findbugs/PMD” it is rather obvious that you should use Codenarc instead, if you code Groovy. It is also obvious that often only some of these points are relevant for certain tasks (e.g. if your task is to write a user manual you won’t write integration tests for it, will you?). Common sense is always more important than strict rules.

This is What Done Means To Us

So, here it goes – our definition of “done”. As you can see it is quite generic in nature but at the same time contains some things specific to our team (like issue tracker schizophrenia uh…). It also addresses some issues that we had earlier with our code (like poorly commented TODOs or lack of information sent to project partners about some significant changes).

what_is_done
These cheat sheets now hang on the two opposite walls (so everyone can see it) and we treat them seriously, which means that if a task is marked as “done” this really means it is DONE.

A very important aspect (at least from my point of view) is that the points were discussed, changed and rearranged by all team members. Even the graphical form of these cheat sheets was done together (in fact in 3 days we had 4 different versions hanging on the walls cause we believe that details are important, so we polished it till we all agree both with the content and with the form).

What surprised me (and made me very happy!) is that my teammates set some expectations regarding “done” tasks higher than I would!

Lets say few words on some points of the cheat sheet.

FIXMEs and TODOs

These are the tags that we put into comments to mark fragments of code that should be reworked (and later find them using IDE or Maven Taglist Plugin).

  • TODO is for minor stuff. The code works, but it might and should be improved but at the moment we have some more serious things to do than to make the code pretty.
  • FIXME is for serious issues – if you don’t fix it, the code won’t work.

We decided to clear (that is to solve) all FIXMEs before the task can be marked as done. But we are less strict with TODO comments – as long as they say precisely what is to be done they are ok. So, a comment like

//TODO change it

is not permitted but

//TODO change variable name to be consistent with DAO naming conventions

is ok.
BTW., we are still discussing if it is ok to mark a task as “done” if the code still contains some TODO comments. The experience tells us that they tend to stay in the code forever (because of their low priority) which is bad. Ideally TODOs should also be removed. If we find it to be an issue, we will rethink our policy.

Code Coverage

We don’t set any strict coverage percentage. We write a lot of “integration code” which is not easily tested with unit tests, and I don’t feel like we would gain anything by setting some high threshold here. What is expected of every team member is to have a look at the coverage report in order to find untested regions and think if it is sensible to write some tests that would cover them. That is all.

Does it Work?

It is too early to say if it works because we introduced this “feature” a week ago (along with Kanban board, but this is another story).
Right now I can only say that it helps me to remember about all petty but important things that one have to do before moving on to another task. Will it have a same impact on the team? Will see about this soon (I plan to write some more on this in few weeks time).

Why do we Need it?

Answering question asked by Jacek:

why did you think you’d have to formalize what’s DONE?
Did you notice teammates don’t follow your take on it or was it something else?

Few things here.

First, as mentioned before, we started to implement Kanban. So now we have this board with few columns and the last one is called “done”. Fine, the board looks nice, but what tasks can be moved to this last column? So we needed a definition of “done”.

The other reason is that we had some issues with our code like the thing with poorly commented TODOs (that no one knows right now what should be done there). Or issues related to “code ownership” which means that each person on the team knows his code and not much more. This will be hopefully addressed by peer reviews that now have to be done before a task is finished.

I also believe that such simple thing like preparing together such a cheat sheet is very good for team health. Definitely I would like to have more stuff done together in the nearest future (I guess that is the outcome of my recent interest in Agile and Kanban).

Links

No links this time, because search will give you plenty of answers if you ask for definition of done or sth similar. Many of them really worth reading and quite inspiring. I would encourage you (and your team) to have a look at them before you start working on your own definition.

What is Your “Done”?

How do you define “done” within your team? Is it just a common sense of decency floating around in your heads, or do you have it “carved in the stone” somewhere like we do? Please comment.