Category Archives: Retrospectives

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

Posted on by
Reply

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 →

Improvement vs. Radical Change

Posted on by
Reply

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.

My Top 5 blog entries

Posted on by
4

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 →

ParkCalc automation – A short reflection

Posted on by
5

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 →

On Feedback

Posted on by
Reply

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.

Planned conferences in 2010

Posted on by
Reply

Zeger van Hese‘s summary of the Agile Testing Days in 2009 reminded me to write about some of the conferences I plan to attend over the course of this year. And yes, Zeger is right, since it was my first conference presentation back in October, I was very nervous. Thanks again to Gojko Adzic and Mike Scott, who gave me great feedback the evening before during the Oktoberfest took place. On a second note, Zeger attended nearly all the presentations I was also in – despite the tutorial.

That said, I’m going to attend the Agile Testing Days from 4th to 7th of October again. The submissions are still open until end of January, but I think one of my proposals may be selected. Additionally, this year it’s going to be a four day conference. So, I plan to be fully blown afterwards.

Another great conference last year was the Software Craftsmanship Conference in London in early July. Thus far Jason Gorman has not decided upon the programme, but he’s working on the submissions. If I can make it by any means, I will attend again and maybe get one or the other book signed. I don’t plan to submit an own session.

A conference I haven’t visited last year is the XP2010 conference in Trondheim from 1st to 4th of June. I’m not sure whether to participate there. I will make this dependent on whether my submission will be taken.

Last, but not least, I plan for the XP Days Germany, though I haven’t seen any planning for the conference thus far. Last year the conference was great. Personally I had great exchanges with Alistair Cockburn on methodologies, the Agile manifesto, and a possible future for Crystal. That said, I hope to attend the conference and get to know another great keynote speaker there, hopefully.

Facets of an Agile Team

Posted on by
Reply

Brian Marick started a series of blog posts on the seven pillars of an Agile team. Brian, Chet Hendrickson, Ron Jeffries, Robert Martin and James Shore came up with seven basic aspects of an Agile team:

  • Product sense
  • Collaboration
  • Focus on Business Value
  • Supportive Culture
  • Confidence
  • Technical Excellence
  • Self Improvement

Brian already started a first description on Product sense with more to come.

His description on the spider graph approach used during retrospectives reminded myself on the A Better Team questionaire based on James Shore’s and Shane Warden’s book The Art Of Agile Development. Since James contributed to the seven items, I believe this is no coincidence.