Blog » Conference: AgileByExample 2015
Conference: AgileByExample 2015
AgileByExample was a Warsaw conference on agile software development. I attended two days of workshops and learned a few new things about communicating with people, organizing work and developing a product – overall, time well spent.
The talks were organized by three tracks: team, product and business. Here are some things I noted down.
-
There was a lot of emphasis on intrinsic motivation (as opposed to motivating people with rewards and penalties). As a general rule, assume people are as productive as the system allows them to be (and try to change the system to give them more freedom / sense of purpose).
-
Also, remember that programming doesn't look like work! Worth to keep in mind that when a programmer is trying their hardest, they usually look like they're daydreaming.
-
Another big topic was work in progress and how to limit it. The main insight I got is that having a lot of unfinished work is not only a scheduling and efficiency problem – if your organization is overloaded with work, it's also limiting your ability to see the big picture and make more conscious changes.
-
Treat product changes not as projects, but as bets! Thinking about what to bet on is a completely different mindset than creating a schedule for a project, and forces you to think more about the expected value than low-level planning.
-
While we're on product changes, impact mapping (example) is also a good way to hierarchically present a plan, so that the focus is on goals, not only individual features.
-
If you really want to convince people, you have to take care of their safety and appeal to them both on rational and intuitive/emotional level (convince both the "elephant" and the "rider"). To make a more powerful argument, draw what you're talking about. Another idea: games or simulations that illustrate your point.
-
Drawing is generally a useful communication tool to have. Have a look at Bikablo for some clever shortcuts.
-
There was an interesting talk on root cause analysis. The author presented a very methodical approach of drawing the whole branching diagram of causes (his team even used a mind-mapping software instead of just whiteboard!) You have to be careful of jumping too quickly to conclusions, and of presenting opinions instead of facts – as a result of these, it's easy to miss something important about the situation.
-
Belbin Team Roles sound like an interesting way of analyzing teamwork. I will have to read about them.
-
Improv exercises. This is not the first time I hear about them in the context of agile. I will have to read about them.
-
Idea: don't demo your software to the customers. Just give it to them and let them use it themselves. You will learn a lot from watching them.