Compared to the last year the event was a bit smaller (~135 vs. ~ 235 people). Despite this the event had some very high quality content some of which I'll highlight next. Perhaps the most interesting thing about this year was the inclusion of multiple workshops in middle of the day.
Considering Tampere Goes Agile is a free event for participants the quality of it keeps surprising me year after year. Besides excellent selection of talks you get to meet a bunch of great people.
Woody Zuill - Mob Programming
The day started with a keynote by Woody Zuill. Initially I was a little skeptical. How could you possibly develop software in a mob? Apparently quite well!
Traditional Split
Traditionally software development has relied on division of labor and expert work. The problem is that once you start to split work you will end up with all sorts of dependencies. This in turn can lead to development blocks and wasted time as you are forced to wait or just do something else while at it.
Multitasking just makes the situation worse. You will end up jumping between tasks while waiting for answers. This in turn creates stress that definitely doesn't help.
Get Together?
What if all the people that have the answers would be in the same room at the same time and developed the software together? You could invite domain specialists or the client even to participate in your sessions. Even though this might sound a little strange approach it alleviates those concerns I just highlighted.
When you are working as a mob this allows you to focus all the energy on a single task at a time (automatic single piece flow!). If you end up blocked there is someone with the answer in the vicinity. It is like the concept of pair programming scaled to the team level.
Woody's Approach
In Woody's configuration there is a single driver (rotated every 15 mins or so). That person writes the code. The rest operate as navigators and guide the driver. The primary advantage of this seems to be that while the driver can think in code the rest can focus on thinking in human terms. They might also spot inefficiencies and help guide the driver towards better technical solutions that might not have been found otherwise.
Given there is so much expertise in the room at the same time this might allow the team to avoid entire categories of problems or eliminate some of the existing ones! Multiple perspectives seem to allow this and the approach helps to avoid some of the traditional sources of waste in software.
The approach isn't without its challenges. It could prove challenging for certain people as it literally brings your work out in the open. Working directly with other people isn't the way software is normally developed. For work like this to succeed you will need to remember to be kind, considerate and respect others even if they might be wrong or irk you in some way.
Besides removing waste the approach allows information to be shared more effectively (reduced bus factor). As it encourages information sharing through collaboration people pick up new skills faster. This is something you simply don't get in a segregated environment prevalent in the industry.
Takeaways
Mob programming is something Woody and his peers discovered through introspection. It was not just something that came out of thin air. Rather they ended up developing software this way because it felt like the right and most effective thing to do. To quote Woody you should find your own way. That said, maybe mobbing works out for you but don't expect it to be a silver bullet.
Per Jansson has written an introduction to mob programming that might give a better idea of what it's about.
Making Work Flow - Lauri Hahne
The gist of Lauri's talk was in how do traditional approaches fail us. He sees software development as a systems and a learning problem. This is very opposite to the waterfall view. I agree with Lauri here. The system, context in which we develop software, puts heavy constraints on productivity. Unless you are developing something you have done before exactly, learning will need to happen. Both of these contribute heavily to project success even if you aren't aware of the issue.
The Traditional Model
The traditional development model is very static in sense that it builds on things like requirements management, HR and distribution of work for maximum utilization. The traditional model focuses heavily on aspects such as technology choices, finding proficient people and division of labor. Teams are formed per project, work is performed on individual level and all of that is managed by a project manager.
If you are building something you have developed before I have no doubt the traditional model couldn't work. What happens, though, when you need to work on something more complex? How do you know you are building the right thing in the first place? How do you measure the impact of your results?
The traditional development model has a lot to owe to Taylor and the industrial era. The theories expect that people are lazy by default and need to be managed for work to get done. Specialization is required to get most out of division of labor. What if some, or all, of the assumptions we've built our development processes are wrong?
What Are Good Teams Like?
What if people aren't lazy and actually want to get things done? What if good teams are larger than the sum of their parts? What if it is beneficial for people to have cross-competencies, not just specialities?
According to Hahne teams that finish early, accelerate faster. He highlighted the importance of stable teams, swarming (single piece flow again!) and scrumming the scrum. You have to be prepared to work on the way you work for things to improve.
You will likely have to discard some of the older ideas to get better. There are plenty of sources for new ones. Of these Hahne mentioned Toyota Production System (Kanban etc. come from here) and John Boyd's Blitzkrieg. He also suggested rethinking division of work. What if you operated per technological layer, screen or feature as a team. It's not a huge leap to mob programming from here.
Hahne values stable teams of teams formed per project. Stable teams operate more consistently, eliminate HR and allows them to operate more effectively as you minimize the effect of Tuckman cycle related to forming of teams.
Hahne highlighted swarming as it will allow each team to operate on a single task at a time (single piece flow). Rather than working on tons of smaller issues at once you actually focus on getting something ready. This eliminates a significant amount of waste and multitasking which in turn improves productivity.
Focus on Process Improvement
Hahne's focus on working on the process itself was prevalent. You should have a good idea of what is blocking team's performance and take steps towards eliminating it. Again, focus on teams seems to be the key here.
If software development has taught me anything, it's that errors pile up and accomplishments disappear. When things go south, people start feeling bad and the cycle gets even worse. If you rush things to make a deadline, you will pay for it later in forms of technical debt and reduced morale. What if you could do things better in the first place and avoid this?
Takeaways
Traditional software development puts too much emphasis on artefacts that have been derived from the industrial era. What might have worked for some tycoon a hundred years ago doesn't quite do the trick in modern, dynamic world.
I agree with Hahne in that teams are a suitable smallest unit. Split work per teams and don't split up teams. Pick new concepts as needed and remove those things that block team success. It is not like you can build a superb team over night. It might form over a longer time, though. Invest in your diamonds.
I agree with Hahne in that teams are a suitable smallest unit. Split work per teams and don't split up teams. Pick new concepts as needed and remove those things that block team success. It is not like you can build a superb team over night. It might form over a longer time, though. Invest in your diamonds.
Trying to Change Company Culture is a Fool's Errand - Sami Honkonen
I have discussed company culture earlier. Sami's talk gave good food for thought. How are cultures formed? How can you change cultures? According to Sami in order to change a culture, you will have to adjust system conditions that cause it. In short culture should be seen as a result of all the things that are going on, not something you can tweak directly.
Context is the King
If you want to change a culture, you will have to adjust the context. If your cake (culture) tastes bad, you will have to bake it differently using possibly different ingredients. Maybe your cake (culture) will be better that way.
How do you know what to tweak then? It turns out system conditions are everywhere. Sami gave a fish tank as an example. Just to give you some idea, at least the following conditions affect the system: lighting, oxygen level, amount of fishes, race of fishes, amount of space in the tank, cleanliness, nourishment, decorations and so on. You can think up a lot more.
How to Change Company Culture?
It is possible to come up with a similar list affecting a company culture. In order to change the culture you will have to change these factors. As an example let's say your company is one of those cubicle farms. How do you think it will affect the culture? The work is likely done in isolation and the people rely on email a lot. The culture is focused on individual performance. This in turn prevents working with others. If you wanted to change this culture, you would have to change cubicles into something else.
Another example is limited WIP (work in progress). If you have the system set up based on teams as Hahne suggested and enforce a WIP limit of one, it gives the teams a very high incentive to focus on finishing. If you take this further and provide incentives based on team performance, you will find that it will be difficult for teams to collaborate with each other.
Takeaways
Sami's talk described well what culture is about. It's something that exists as a result based on system conditions. If you change these conditions, the culture will change as well. There is no direct way to modify it. Rather you tweak it indirectly like this. Even small things might have surprising effects and I expect it's a whole can of worms if you really start thinking about it.
In short if culture eats strategy for breakfast, system eats culture for lunch.
In short if culture eats strategy for breakfast, system eats culture for lunch.
Introduction to Retrospective Facilitation - Ville Ruuskanen
Isn't nostalgy great? Who doesn't love 80s clothing and music? Thankfully retrospectives don't have to go that far and you don't have to wear those tight 80s clothes to facilitate them.
Why to go Retro?
The primary advantage of running retrospectives for your team is that they provide a great chance to perform introspection and think about what works and what doesn't. This ties back to Woody's and Lauri's talks in which they highlighted the importance of process improvement. You shouldn't run a retro only at the end of the project. Rather the greatest benefits are gained if you measure the pulse of your team continuously. In Ville's case he seemed to prefer a longer one (2-3 hours) once every two weeks though your mileage may vary.
There is no single right method to run a retrospective. Instead you should thrive to vary their content. Ville provided a rough frame in which you can build the event itself. I won't go through the details as you can find them in the slides below.
Given there was another workshop running in the same space at the same time, it was a little noisy at times. Apart from that it was just great as I didn't know much of the topic beforehand. If I ever have to manage or lead a team, I will have yet another nice tool at my arsenal.
Self-Management, practical tips for your personal journey - Erik Anderson
In order to remain competitive in the current business environment, you will have to continuously push yourself forward. This was the topic of Erik Anderson's talk. Curiously self management is one of those topics they don't teach you at school. Rather you are expected to pick it up yourself and some people just fail to do that. If you are aware of the issue, you can probably do something about it.
Erik split the topic in three overlapping parts: body, brain and society. We can do something for each up to a limit. Especially the society part tied back to earlier talks. Where and how you work affects your well-being directly whether you acknowledge that or not.
Body
It is important to keep in mind that humans used to roam savannah. Modern life as is is quite recent invention and we certainly haven't adapted to it perfectly. This in turn causes all sorts of problems for bodies designed for something else.
If we keep these constraints in mind, we can understand better why exercise is so important yet undervalued. Being in a good physical condition affects everything. In addition effects of sleep and proper diet should be kept in mind.
Brain
Interestingly exercise gives your brain what it needs in order to change (improved learning, memory). It is possible to "hack" brains in various ways. Sadly they don't provide user's manual with them. I guess we wouldn't be so lost otherwise.
Mindfulness, being aware of what you feel, allows you to observe what you feel rather than react. If you train the brain through meditation, it will get stronger just the way body does when you learn it.
It pays off to understand how habits work and what happiness means from perspective of brains. Learned helplessness/optimism is another of those concepts people should be aware of.
It is easy to end up in a cycle of depression because depression causes more depression. Breaking the cycle is the problem. On the other hand it might be possible to gain optimist traits and get into another kind of cycle. In the end it comes down how you deal with adversities in life and react to those.
Society
Erik discussed topics of personality styles, personal strengths and team profiling. I know personality tests and such sound like pigeonholing but the fact is that each of us has their preferred way of working. It is important to be aware of that as that is something that contributes to our happiness.
If you can adjust the way you work to suit your personality better, you will likely achieve better results and be happier while at it.
The way we relate with society has a big effect on us. Erik described the concept of transactional analysis. The key thing to understand here is that a person is a multi-faceted concept in how it relates with the world. These facets (parent, adult, child) get triggered in social situations and helps to explain why responses are the way they are. If someone snaps at you, maybe there was something about the way you poked the person that triggered the child response to parent question?
Takeaways
Erik's talk showed that there is a lot to learn about. Self management and improvement are large topics. To quote Erik you will have to keep on tweaking things to see if they get better and be open for changes. That is the way forward.
Conclusion
It's probably not an understatement to say that this Tampere Goes Agile was the best one so far. I loved the talks and even the party after the event was fine although I felt embarrathed over wordings of certain agile songs performed. I hope the event will be arranged again next year and definitely plan to go it if is!