Improving our (Agile) process

I attended two presentations on improving the Agile process once it's implemented. Sven Peters of Atlassian gave us seven ideas to make good teams great, and Trisha Gee and Isra Rodriguez of LMAX talked about the problems they encountered using the Agile process.

The underlying message Trisha and Isra gave was to apply the scientific method to any problems you may encounter: make the flaw visible, think up a solution (we are all smart people here after all), implement a change, then measure again to see if it helped. Repeat. This is of course not new, but it is important to realize that implementing Agile is not the final cure for all your development problems, and that teams will have their ups and downs always. You will fail!

Sven gave more practical advice, some of which I will discuss to see how well it would work with Avisi.

Two things that are less applicable to my team are "Eat your own Dog Food" and "Experimentation Time". The former means everyone in the company should alpha-test your product, while the latter aims to give developers more influence on the product by assigning a percentage of their time to implement features that they would love to see. The problem for us is that we don't build a product to sell, but we build a specialized application for a third party. This makes it hard both to test it and to think of new features in everyday life.

One of the things that we already do is to "Feed your brain": keep learning new things! That's why I am at Devoxx and that's why we have our tech days. We also already have (and are proud of) our "Report Robot": we automatically generate a lot of information on how teams and systems are doing and we radiate that information back to our people with our wallboards.

It is always important to "Say: Well Done!". Praising people individually for a job well done motivates them, even if it does not include a gift of any kind. I don't think we need a system where employees can nominate each other for gifts like Atlassians Kudos program because our company is still small enough for everyone to have a feel for the work other people do.

Something that always bothers me is the Collaboration vs. Flow conundrum. I want people to work closely together. I really do. So I want people to be near each other, in an open space, always accessible to answer questions or discuss problems. But when I'm working on a complex task I also really don't want to be disturbed, so I want a closed room for the team without external interruptions. A solution that Sven offered was "concentration time", a few hours each day when email and phones are turned off and no other people are allowed to interrupt the team. I think it's a great idea, but I doubt whether it will actually work. We have team members who are on another team as well, which makes it hard to not have people from that team interrupt them for several hours.

Something that I really want to try in our team is "Do a Special Day". Our backlog always contains some tasks that no one wants to pick up. They are ugly, they are no fun to implement or solve and we just hope that if we ignore them long enough they will just go away. Obviously, that doesn't happen, so we should have one day every sprint to attack these beasts with the whole team, so we can share the pain and have them out of the way.

There's always room for improvement, even if your team rates itself as a good team. I certainly want to try out some things that we don't do, but we should also seek to improve the things we already do, and finally we should keep in mind that ideas that are not relevant for us now may very well become relevant in the future.