Recenzja dostępna jedynie po angielsku. Kliknij tutaj.
On Feb 11th Agile Warsaw organized another BYOP gathering. BYOP stands for Bring Your Own Problem,
check it out here. As far as I know this was the third one happening in Warsaw and the first one using Lean Coffee formula. 
Lean Coffee
You can learn what lean coffees are in 5 minutes
here, or watching this video, but if you feel lazy, let me describe it shortly. Lean coffee is a formula for conducting a discussion with two principles – first, we collaboratively decide on the agenda and then, also collaboratively, decide when to move from one topic to another. This is really that simple. We started the BYOP meeting with everybody suggesting topics for the discussion. We wrote them down on a whiteboard, then everybody voted with dots – everybody was given two dots to pin close to the topic of their interest. This created a prioritized backlog for our discussion. With Lean Coffee when you have your backlog you just start the discussion. And you set the timer. When the timer goes off, everybody votes with theirs thumbs – do we continue this topic (thumbs up) or should we go to the next one (thumbs down). We follow the majority. If we continue with the same one the timer is set again, but this time to half of the initial time. Last thing to mention about the Lean Coffee formula is that it starts to get little messy when the group gets larger than 12-15 people. The best idea then is to split into two Lean Coffees. As simple as killing chickens with axes. There were ten of us so it worked brilliantly. I was moderating the discussion trying not to get involved too much.
What we were discussing
There were several topics on the board but before I had to leave we discussed four of them. We spent around 15 minutes on each of them. Here are the main points I remember.
Metrics
How should you measure if agile adoption has any positive effect? How do you convince a CxO that agile adoption was a success? **We agreed that no matter what the reason is and what the metric is it should be somehow connected to what you want to use it for. CFO probably doesn’t care too much about your team’s velocity (and of course using velocity to measure how close are you to the state of hyper-productiveness is a really bad idea)… Therefore the choice of metrics will be very context dependant. If you want to make more working software – measure how much working software you are making. If you are a startup you probably want to focus more on measuring validated learning or conversion rate or something similar, more than on working software. If you are a large enterprise like a telco operator or a bank it gets really complicated but that doesn’t mean it should not be done at all. Followup reading: Lean Startup by Eric Ries for startup metrics and also EVO method by Tom Gilb.
Introducing TDD
How to convince a team to start using TDD? We tried to address typical problems people and teams have with practices similar to TDD. And we agreed that if you want to convince any team you should prepare a meaningful explanation in their context… We don’t have time – well, you probably introduce TDD in order to save time… in the long run. Time that otherwise will be used on defects. So it’s kind of an investment. We don’t know how – fair enough – then do some training… And don’t be afraid to fail, just make a small failure and recover. We also agreed that having someone really motivated to do it is an enabler – a change agent. And also – often without some kind of management support (ie. accepting the investment) it will be a lot harder if at all possible.
Usability in Scrum
These days Scrum teams are built around developers. If they are skilled in programming how can we make them do proper UX or Usability? First, I disagree with such problem statement. This is not true that by design Scrum teams are composed of developers only. What Scrum Guide says (I believe) is that teams should be cross-functional. If at any point we notice that a team is lacking some competence like UX or Usability design, we should add this competence to the team (either by adding a new member or training or in any other way). Another thing mentioned was that working on usability, at least to some extent, goes beyond the scope of one user story or maybe even the scope of one sprint. Often, usability is the effect of some kind of synergy between features and you should plan and design for that (that’s thinking on a release level). Finally, someone suggested that it is the Product Owner that should be responsible for usability, and this point of view was confronted by an observation that the more responsibilities PO gets, the less responsible the team will become. And I agree – there is some truth in this statement.
Motivation
How to get oneself motivated? How to motivate a team? How to get out of apathy you feel after a few years? There is no simple answer to that but there were actually some ideas pointed out. Gamify your work – gamification aims at making work more bearable (all work and no play makes Jack a dull boy…). Make it fun – beside gamifying your everyday work you can break apathy at least a little bit with things like foosball, darts, gaming consoles and generally – building space for socialization. But, personally I think that even though those two can make a short-term difference they won’t make motivation permanent. After a few weeks their effects will start to fade… I would suggest focusing on the following two: Set goals – and these goals should mean something for the team. If your team consists of developers, you can focus on improving quality, or finishing a major release. Connect goals to strategy – to further amplify the effects of setting goals you can show how those goals relate to the strategy of your organization. Provided your organization has a strategy. And I think the only part of the strategy that is important for this purpose is having a strategic goal.
Final thoughts
Concluding, I had to leave before the meeting was finished but I heard it didn’t last much longer. I liked timeboxing and prioritization that Lean Coffee formula gave. I liked moderating the meeting, as I was focusing on keeping the conversation going on, keeping time, etc. Regarding Lean Coffee – I started from setting the timer for 15 mins for the first timebox and the next ones on the same topic for 7 mins. I quickly decreased these times to 10 and 5 minutes, respectively, but after thinking about it I believe that what Lean Coffee recommends (which is 8 and 4) is even better. At first I thought 8 mins is not enough for anything but frankly – that’s lot of time. What is perfect about this formula is that experimentation is built in – with anything you want and then adapt however you feel appropriate. Something I didn’t facilitate was creating name badges which can be really simple and I believe it allows for better connection between participants. I knew almost everybody but probably that was not the case for all. A thing to take care for next time. If you were participating in this event I will be more than happy to hear what you think – please leave a comment below. If you organize BYOP or Lean Coffee in another city – tell us how it went. You can find me on
Twitter and LinkedIn. You can find TouK on Twitter and LinkedIn.
