Tag Archives: retrospective

See the Whole Flow – An Exercise for Managers to Start a Transition

Posted by on 2012/04/17 No comments

Last week, I got an interesting assignment from my boss: find a way to introduce Agile/Lean to a management group in the form of a retrospective meeting so that they can start their Agile/Lean transition by finding gaps in their organization.
When I started to prepare for this meeting I thought that this particular group should do their work according to the Lean principles and forget about Agile for a while. I could write another blog post about the reasoning – I don’t want to go into too much detail now -, but in a nutshell, I wanted them to do a real top to bottom transition and I felt that the Lean approach is more suitable for this than Agile, because Lean builds from the top and Agile raises issues from the bottom.
I also felt that we’d be able to start with a more complicated exercise right away, so I decided not to bring any well known ones and put together a Lean exercise for them. The exercise consisted of four different tasks:

  1. Do the value stream mapping of your organization
  2. Show how the information flows through the organization
  3. Find out which phase is the most valuable and which generates most of the waste
  4. Generate an improvement queue based on the findings

I have to mention that we did the original exercise a bit differently than I’m describing below. This is because I learnt a lot while doing the exercise and have since made changes to the original idea as a result. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

Our Detective’s Blackboard

Posted by on 2011/09/06 No comments

My colleague Attila and I had an interesting discussion several days ago:

- Zsolt, I feel that sometimes we are missing the big picture.
- That’s not cool, and it may explain the high number of work items moved back.
- Maybe, but can we do planning together again? I miss it.
- Sure we can, but no regular planning meetings, right?
- Of course not.

As my friend @keksz_i pointed out, regular planning meetings aren’t that effective and I’m also not a great fan of them: talking to the product owner is a brilliant idea, but the traditional task breakdown is just a tremendous waste of time. After our discussion, it was clear to us that we had to bring the planning back, but we needed something new, something effective. So we came up with the following detective’s blackboard for our next feature:

It is drawn on a large piece of paper and hangs on the wall right next to our Kanban board. It has all the information we need in order to do our work: the big picture, how our user interfaces will look like and how they will communicate with other parts of the application. Additionally, we also have work items, prioritisation, test plan and estimation.

Read more »

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Code Review During Retrospective

Posted by on 2011/08/02 4 comments

Most of the retrospectives I’ve kept or participated in were about agile approaches (for example communication with the Product Owner) and organisation-related changes, but not everybody is into these. Most software engineers and craftsmen aren’t that interested in how to deliver faster, or how to communicate better, they are interested in how to be better at their profession: programming.

Usually, software craftsmen are interested in new technologies and improving their programming skills. The easiest way to gain knowledge and improve skills is to learn from each other, see how others are programming, what kind of tricks they are using, what problems they have, and how they solve them. Last but not least, when you read other people’s code, you will have more information about what is going on in the project(s) you are working in.

My proposal is to do code review during your retrospective meetings.

Usually, this kind of retrospective has the following goals:

  • learn new programming techniques
  • find quality improvement ideas
  • find coding behavioural patterns which need to be kept
  • find coding behavioural patterns which need to be changed

It is really important to keep these goals in mind, because the retrospective is not a real code review session where the goal is to find mistakes and correct them. It is about finding those things which can make you a better craftsman in the long run.

Read more »

VN:F [1.9.17_1161]
Rating: 8.5/10 (2 votes cast)

Pair Programming in Retrospect

Posted by on 2011/04/11 2 comments

I’ve been doing pair programming for two years now. During this period I gained a lot of experience, so it is time to do a little retrospective and organize these experiences. I hope that you find something useful here, or even better, you may start to do pair programming.

Basics

Pair programming is one of the 12 core practices of eXtreme Programming in which two participants sit together and do programming using one computer. One of them owns the keyboard, while the other one assists. They are continuously discussing how and what to do.

What Worked for Me

After trying out several different pair programming styles, I’ve come up with a list of things which worked out quite well for me:

  • Use the same development environment as the others
  • Close all applications except the development environment
  • Pick a pair for the whole day and do not switch pairs during the day
  • Do pair programming only the agreed amount of time
  • Work with different people during the week if possible
  • Change roles (keyboard owner and associate) frequently, at least once in every 30 minutes, but never in the middle of the TDD cycle
  • Be honest, communicate a lot and be cooperative and patient

Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

Kanban Nightmares

Posted by on 2010/11/28 6 comments

I’ve mentioned in my previous post that I have less time for coding nowadays. I’ve started to lead a new team with the intention to introduce Kanban in their way of working. In this post, I’m going to share the result of this introduction.

In these last few years I’ve had opportunities to observe coaches and consultants how they help teams and organizations. I’ve been reading about how it should be done in the proper way. In most of the cases, the person who helps the teams asks questions, points out certain areas of improvement, keeps general coding sessions, but does not get involved in the teams’ life. No offence, but I don’t see how someone can help without taking responsibility. The intention he has is loud and clear: make the teams self-aware, self-organizing and independent. But there is a fair question, though: “How can a team be self-organizing if, before agile was introduced, they had been told what to do for years? How can they make decisions?” After these years, I can state that this approach is not really effective for novice teams. It is very good for advanced teams, who might miss some improvement opportunities occasionally, but are able to react if that missing piece comes to light by a coach or external advisor.

Another common mistake and myth is that the ScrumMaster should not be involved in the team’s decision making process and daily work. In novice teams, no matter what experts say, the team members want to follow the ScrumMaster, they want to hear what he thinks and they want to follow his lead. This may sound non-agile, but if someone wants to be successful with agile methodologies, he shouldn’t ignore this fact. The ScrumMaster should coach the team like the managers at Toyota in TPS, he should give background information, and show examples on how to make decisions and how to be agile, and not just do agile. This cannot be done without the involvement of the ScrumMaster in the beginning. Teaching by example is very important. If done properly then, based on my experience, teams won’t be lost when the ScrumMaster is no longer with the team. They will continue their work, they will start being agile, and won’t depend on the ScrumMaster. There is going to be a slight setback in their work, because the team will have less new ideas due to the absence of the ScrumMaster. Fortunately, they will have learnt from the ScrumMaster how to be agile by then – and not just do agile -, so someone will start driving the changes, others will follow, and a real agile team will start forming.

Read more »

VN:F [1.9.17_1161]
Rating: 7.0/10 (1 vote cast)