A Day in the Life of a PI Planner

What does a PI Planning session look like? How are different companies carrying out this exercise in reality? And how does the actual practice of PI Planning match up against the theory?

I recently had a chance to find out, when I attended a PI (Program Increment ) Planning session at KLM. For me, it was not just a good learning experience but also a trip down memory lane as KLM happens to be  an ex-employer, a company I had worked with for 14 years. Almost inevitably, I bumped into old friends and colleagues and the joy of these unexpected meetings, the convivial and productive atmosphere during the sessions, and the many new things I learnt, all combined to make it a perfect day.

It started the moment I got there. No sooner had I parked my car, than I could see a number of airplanes taxiing, a sight that immediately took me back thirty years, to a time when all my days used to start like this. It was like stepping into an old familiar world, with all the comfort that such intimacy brings. But what really brought a smile to my face was seeing some old, familiar faces. I met almost 8 to 10 people I had worked with earlier and realized that many of them had developed in the same way as me. We had all started in the days when the waterfall model ruled supreme and here we were again, after almost 30 years, all of us equally enthusiastic about Agile.

On the whole, the sessions themselves went off really well. I was given a tour of the premises by the ex-colleague and friend who had invited me there and also introduced to a number of Scrum masters, product owners as well as the Release Train Engineer who was the lead for the entire exercise. Through the day, I went around observing what was happening with the different teams and took a lot of notes about what was going on. Given below, in short, are a few of my observations:

• The first and most immediate observation was that each team had been allocated adequate space with a TV screen and a cards board. In other words, the preparation and planning of spaces had been well-thought through and each team had the support it required to carry out its activities.
• The other thing that sprang up at me was that user stories had been pre-printed on clearly readable cards. In this respect too, the preparation for the day was impressive. The printed headlines, acted as precise catalysts to spark the conversations that were needed. This was important, as it is based on these headlines, that the teams start refining the requirement (breaking the headline into its constituent functionalities or what is known as ‘story points’) and come to a consensus on what exactly each requirement entails and how much effort might be needed. Due to this level of planning, the various teams together were able to work through perhaps a hundred different user stories in two days.
• One thing that was very nice to see was how hard the teams were working and the smoothness and the spirit of co-operation with which they divided their duties amongst themselves. Usually, in such sessions there are always certain duties which no one wants to take up, things such as taking down the minutes or filling in questions and conclusions etc. However, in this particular session the teams discussed the allocation of duties between themselves, in a very friendly and pleasant atmosphere and team members strove to relieve each other of the more burdensome duties. This level of team spirit was very heartening to see.
• Overall, the model and ways of working were consistent with Agile and DevOps and yet, there were glimpses of the waterfall model in certain aspects. For instance, a number of teams had separate test plans, with testing as an activity being pushed to the end of the development cycle. Of course, as a QA Engineer/Agile Quality Coach, I quite enjoyed all the discussion around TestingJ. However, this does not take away from the fact that testing needs to be fully integrated into the development cycle.

Another aspect in which the waterfall model peeked through was in the division of roles. While Agile stresses the need for professionals with ‘T-shaped’ skills and the development of multi-disciplinary teams but at KLM almost everyone was very highly specialized. Thus, we saw coders who were only coding, designers who were only designing and testers who were only testing. This was consistent across all teams.

Of course, the question here, is whether it is even feasible to have such multi-skilled professionals in today’s labor market. Perhaps, we will be getting there in the future.

I also noticed that in general, user stories were not evenly distributed over the Sprints. This immediately caught my eye, since the user stories had been printed on cards and pasted on the wall. Even a cursory glance, was enough to see that the first couple of Sprints were crowded with cards, while the remaining ones had much fewer cards.

On seeing this, the first thing that came to my mind was that this was possibly the result of some vestiges of the waterfall model, which was still being used. However, after having thought about it for a bit, I am not so sure anymore. Perhaps, this sort of planning is almost inevitable, given the fact that it’s much easier to plan for the next month than to plan for something three months in the future.

Bringing out the dependencies between different teams is one of the key objectives of a PI Planning session and this was something the KLM team did really well. Over the course of the day, they had a number of Product Owner synchronization meetings, as well as architect synchronization meetings. So what would typically happen is that after a couple of team meetings, the Product Owners would meet amongst themselves to go over what had been discussed within their teams. Similarly, there were also a number of architects who were walking about, talking to different teams and helping them throughout their meetings. They also carried out similar synchronization meetings between themselves. Such synchronization meetings helped everyone understand the dependencies between different teams.

Another important aspect, was the color coding of the cards, which helped indicate whether it was a stand-alone feature or a capability which would be used by other teams. The dependencies between user teams were displayed by using pieces of rope. All of this was put up on the wall in a manner that was easy to decipher. This ensured that everyone was on the same page and misunderstandings or delays due to dependencies would not crop up later in the project.

On the whole I found that there were only one or two teams which used design or architecture documentation extensively. I believe more pictures of the customer journey, process flow diagrams or technical architecture would have helped set the context for all team members. The lack of these kinds of pictures confused me somewhat as I was never sure if everyone had a common understanding of the underlying context or indeed, if they were even talking about the same things when discussing certain concepts.

I would have much preferred the documentation to be clearly visible on the walls, as a lack of such documentation could lead to misunderstandings in the future.

Towards the end of the day, each of the teams made a five to ten minute pitch about what they were going to do. Some of the teams came up with really creative pitches in the form of scripts and movies and yet, I could also sense that the energy levels in the room were dipping. The whole exercise which was perhaps an hour and a half long, was carried out at the end of a long, intensive day of work and thus a number of the pitches basically went through with half-confident votes.

In short, a day well spent went out with a fizz rather than a bang as one might have wished.

Overall, it was a fantastic experience and a great learning opportunity for me. It was good to see Agile principles in action in such a positive environment. While I learnt a lot, the session also left me with a number of questions, about whether certain ways of working were inevitable for this kind of a Project Increment Planning session.

In the end, I would just like to thank KLM as well as all my ex-colleagues and friends, for this wonderful opportunity.