Category Archives: Retrospectives

Leadership, Retrospectives

Which Agile project management tool should we use?

6 Comments

Maybe it’s just me, but the whole “which Agile project management tool should we use” debate drives me nuts.

Maybe it’s just me, who can’t understand what “Agile project management” means to start with. Try to think in products, not in projects. Your product portfolio is the bigger problem, not how you taylor the work to create multiple projects.

Maybe it’s just me, who does not understand a thing about project management, but about software development instead. I don’t know what I want, but I know how I can get it: take small steps, iterate and reflect.

Maybe it’s just me, who heavily remember Conway’s Law:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

(Source: Wikipedia)

Maybe it’s just me, who also understands the other direction of that law. Once you introduce a tool, it will constrain how you think about changing your organization. That said, it will keep you away from meaningful steps once they become necessary.

Maybe it’s just me, but we shouldn’t be talking or debating about Agile project management, or about Agile tools. We should discuss about what makes us successful. Remember: A fool with a tool is still a fool.

Retrospectives, Testing

2012 retrospective – Addendum: The articles

1 Comment

Happy New Year!

I was not going to blog about this, but it turns out that this twitter conversation between Lisa Crispin and Meike Mertsch prompted me to it. So, here are the articles I wrote in 2012. Since I write in two languages, I decided to separate them between my English and German articles. I also try to just mention the ones that were published in 2012, not necessarily written.

Continue reading 2012 retrospective – Addendum: The articles →
Retrospectives

2012 retrospective – The books

Leave a comment

After some reflections on my professional life, and the conferences I visited, I would like to go for the books that I read next. I will do this part of my personal retrospective in the same way I did it last year.

2012 has seen many new books. It seems no one can hide from the influencing that Lean Startup had on the products out there. That said, I also read a lot of books in beta from LeanPub. I purchased and read some books while they were written in 2012. So, you will not find all books on the platforms that I used like LibraryThing and GoodReads.

Continue reading 2012 retrospective – The books →
Retrospectives

2012 retrospective – The conferences

Leave a comment

Following up on yesterday’s blog post, where I do New Year’s resolution in Alistair’s style, today we will take a closer look on the conferences and peer workshops I visited in 2012. And I fear there are many. I remember when I sat with my colleague Meike Mertsch in early October, and we had brainstormed conferences we could submit talks to. In the end, we knew we had to cut that list down to a reasonable size, even before counting them. There were about 50 conferences on our list.

Here are the ones I visited in the past year. I tried to group them by theme, not by date.

Continue reading 2012 retrospective – The conferences →
Retrospectives

2012 – A personal retrospective

Leave a comment

Four more (whole) days are left in 2012. As the world seems to turn a bit slower in these final hours of the year, I decided it’s time for some personal retrospective. Since I read Pat Kua’s Retrospective handbook this year, I decided to do some writing about my year on my blog as a personal retrospective. I will cover the books I read and the conferences I visited in later blog entries. This blog entry will stuff that happened during the year.

Continue reading 2012 – A personal retrospective →
Retrospectives

Goes-into, goes-onto to Generate Insights in Retrospectives

Leave a comment

Currently I coach a team on Scrum, and I helped them introduce retrospectives using the five steps as outlined in Agile Retrospectives by Diana Larsen and Esther Derby:

  1. Set the Stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

I was able to attend a retrospective training with Diana Larsen in July this year. One activity I noted down back then was called “goes-into, goes-onto”. As I prepared for the retrospective, I decided to use that activity. Unfortunately I couldn’t find a reference or a write-up for this insights generating part of a retrospective. I decided to write down what I did, and my experiences with it, so that others won’t fall for the same problem in the future.

Continue reading Goes-into, goes-onto to Generate Insights in Retrospectives →
Kanban, Methodologies, Retrospectives

Improvement vs. Radical Change

Leave a comment

In the Kanban, Scrum and Lean hemisphere there is a continuous discussion about the radical change nature of Scrum vs. the evolutionary change method of Kanban. Both are often referenced as Kaizen or Kaikaku in Kanban. But what’s the difference? When do I need one or the other? And what does this say about change in general?

Kaizen

Kaizen is about improvement. Retrospectives in the Agile methodologies help to foster continuous improvement. After a limited time the team gets together and reflect on their past few weeks. In the original methods retrospectives where bound to the iteration limit, like one to four weeks. With the aspiration of iteration-less methodologies like Kanban retrospectives get their own cadence, and don’t necessarily fit the planning boundary.

Retrospectives help to improve one to three things that didn’t work well. Ideally applied the actions from a retrospectives help to change the development system just a little bit. In complex systems such changes may have unpredictable consequences. This is why we restrict changes to one to three items. If we try to implement more changes at a time, we are likely to completely turn the underlying system around, thereby getting an unpredictable system.

Over time such little changes eventually lead towards a system which gets stuck. If you keep on improving a little bit time after time, you climb yourself uphill towards a local optimum of improvements. Once you picked a particular route on that journey, you might find yourself on a local optimum besides too higher mountains. But how do you get from your local optimum to a higher optimum?

Kaikaku

This is where Kaikaku comes into play. If you got stuck in a local optimum, you may have to apply a radical change to your system in order to improve further. This comes with a risk. Once you set up for a radical change, you will get another system. Like introducing Scrum to most organizations comes with the effect of radical change. Where does my project manager belong in the three roles of team, ScurmMaster and ProductOwner? How do we integrate our testing department into the development teams? These are rather larger steps.

Comparing this with the landscape of mountains, Kaikaku is a large jiggle, like an earthquake, which might throw you onto a completely different area of the landscape. This might mean that you find yourself on another mountain top afterwards. This might also mean that you find yourself in a valley between two larger mountains. This might also mean that you end up in the desert of the lost hopes.

This also explains that too much radical change eventually leads to an uncontrolled system. Since you keep on jumping from left to right, you never settle in order to get a stabilizing system in which you can apply smaller improvement steps. In fact your system might totally collapse by too much Kaikaku.

This also explains that you should seek for the right mix of smaller improvements and larger radical changes. Once you get stuck, try to reach for a larger step, but just one at a time. From that new ground start to go uphill again by taking smaller improvements – one at a time. Over time you will eventually end up within a system that is continuously improving itself.

Retrospectives, Testing

My Top 5 blog entries

4 Comments

Darren McMillan asked me today about my TOP 5 blog entries which I would recommend handing out. So, I sat down today and skimmed over my blog entries from the past. I was realy delighted and got many insights about stuff that I had nearly forgotten about. So, in the end I decided to share them with my readers as well here. Though, I had problems limiting my blog entries to just five, but I tried to categorize them as good as possible.

Continue reading My Top 5 blog entries →
Agile Testing, Retrospectives, Testing, Weekend Testing

ParkCalc automation – A short reflection

5 Comments

Over the course of the past week or so, I wrote some blog entries on ParkCalc automation. Today I decided it’s time for a brief wrap-up on what I learned over the course. You can find the four parts written up so far here:
Getting started, Refactoring a data-driven test, Refactoring a keyword-driven test, BDD style tests

Continue reading ParkCalc automation – A short reflection →
Leadership, Retrospectives, Testing

On Feedback

Leave a comment

In a comment on my last blog entry, Thomas Ponnet reminded me of something I experienced during my years at the university while I was working in a local shop. By that time I was responsible for ordering beer and non-alcoholic soft-drinks, and getting them into the shelves. We had a weekly ordering cycle, and some of the better brands needed to be ordered in large amounts and refilled over the course of the week – i.e. directly before the weekend.

My direct superior switched jobs to another shop, and we got a new superior. The first thing our new boss changed, was the responsibility for all orders in the food department. Just the new boss and his substitute would make all the orders in the department. Groceries, meat, alcoholic and non-alcoholic drinks, etc. We were asked to simply fill the shelves, and keep the shop beautiful.

Now, think shortly over how this felt. Our self-responsibility was taken away. This resulted in a more senior student temp to quit. The new orders from his new boss were just too ridiculous to stay there any longer. I decided to stay, but I also got the exceptional status to still order goods myself. So, in order to demoralize a team completely, just take their self-responsibility and observe the degeneration. This holds for teams in your local shops as well as for software development teams.

Now, over time I observed the other areas, where I wasn’t mainly responsible, but helped to fill in the shelves from time to time. The food substitute ordered more and more goods. The problem was, that the substitute did no longer have the time to do the refills. Over time she was simply noting down the orders during her shifts. The problem was, that she started to make mistakes based on the time pressure I think she had to finish all these orders off in the time given to her. So, time pressure resulted in more human errors. Sounds natural, doesn’t it? This also holds for software development teams, doesn’t it?

What then happened, was striking me. We noticed all the errors the substitute made during noting down the orders. Since we took the new goods and put them in the shelves, we noticed there were blanks after we finished, and there were remains we needed to carry over to storage in the back – hopefully the remains would fit into the shelves in a week or so. But, instead, the substitute while noting down the orders for the next week, saw the blank place on the shelf. She then did the same mistake again, ordering just those goods, that were full and we had still some remains in the storage, instead of the product that was actually missing. Since she didn’t have the feedback from her orders, they got worse and worse, ever resulting in larger and larger piles in the storage. Over the course of a year the remains in the storage raised by a factor of four.

What I learned over the course of two to three years by then was, that people responsible for a job have to get the feedback of their actions. This holds for shop ordering teams in the same ways as for software development teams. Without the feedback on problems and errors, I cannot learn to avoid these errors the next time. I will be pretty oblivious to my courses of actions. In the software world, there are several things we may pile up. Maybe it’s a large test suite with unreasonable execution time, maybe we pile up Technical Debt, or maybe we pile up Design Debt, or, or, or…

This is why Agile development teams iterate and reflect. They get their feedback regularly and decide how to adapt to problems and new situations regularly. That feedback is crucial, don’t remove that feedback from your teams – and please leave them their responsibility.