Scaling the PO team

Second session was planned to be another session with Alistair Cockburn however, he choose to ignore the official session title and instead he conducted an interactive activity demonstrating the power of iterative development and effectiveness of an adaptive process.

after that Ive joined a session focusing on the role of the PO in a scrum process and how to scale this position without damaging the entire process.

The role of the PO in a scrum team is to represent the client. the PO is responsible of maximizing the ROI, i.e. he’s the one responsible for generating $$$. Specifically the PO is in charge of grooming the product backlog, which includes among other, writing user stories, prioritizing them and keeping track on what is getting build. The important thing to remember is that this is an active role, stories are not invented from thin air, they are discovered by talking with users, customers and sometime even the developers. A good PO will actively manage the backlog, he will keep priorities straight, refine stories as new knowledge is gained, remove less important stories and add new ones.

The key point of being a PO which is sometimes missed is that the PO should consider himself as part of the team. When a PO works in disconnection from the team, things will usually not go smoothly optimal. For example while in the Scrum “rule book” the PO approves stories during the demo at the end of the sprint, effective PO’s do not wait for it. they actively review and approve progress during the sprint work. after all why wait?

Scaling the PO

But sometime one person is not enough to effectively cover all the responsibilities of the PO role. and the big question is how to scale that role. Like anything else there is not a single answer on how to correctly scale the PO role, each method has its own strengths and its own risks. the key for success like anything else in life is to always manage the risks and be on the lookout when things are not going as they should.

One way of scaling the Po is to divide the by area of responsibility. i.e. one person (or more will work closely with the customer) and one (or more) will work closely with the team. Another option is to split the work more naturally according to the product technical components. but no matter how the work is split its crucial to first achieve good communications channels between the people functioning as PO’s. Normally a PO team will much higher level of cooperation than other teams to succeed.

another tip for scaling the PO role is to adhere to agile values, i.e. always inspect how the team of PO function and to improve. It is also possible to use a modified scrum process in order to manage the work inside the PO’s team.

When not to Scale

but the most important tip of this session was when to chose not to scale. Sometime organizations are scaling the PO not because they actually need to, but because there's an underlying dysfunction which was not recognized. for example I've seen a PO which spent so much time in customer relations, that he didn’t have time to help the development team. naturally the team complained, and suggested to add more personal to the PO. Only after sitting with the PO and raising the team issues, did we realize that the PO did have time but he didn’t fully understands what was required of him.

So before scaling, take a good look, maybe scaling i not the answer. maybe just maybe there’s a better alternative.

Read more »

Posted in: Events,Scrum,Team System

ScrumBan

After Alistair lecture the convention divided into 4 different tracks, I chose to attend the session titled as ScrumBan given By Yuval Yeret (a Coach in Agile sparks). In this talk Yuval introduced some of the ideas behind Kanban and how they fit inside a Scrum Process.

So what is Kanban

I not going to explain too much here info on that can be found here and here. I would just say that Kanban is what guided toyota when designing its lean manufacturing line and it very much resemble a Scrum process with two major differences:

1. its more flow based and less iteratice kind of process.
2. being a flow based process the amount of work In Progress allowed (WIP)is limited.

When to use Kanban

Kanban should be used in situations when one can’t plan effectively, even for a very short cycle found in Scrum. This usually happens in specific kind of projects. one example would be projects which are mainly about support and maintenance. In These priorities really change on a daily basis making planning useless.

However many projects do have specific stages in which its really hard to plan ahead and naturally they adopt a more Kanban style of working. This happens a lot towards a release date during the Hardening phase. In this phase most of the work is about solving issues found as fast as possible and there is nt much use in doing extensive planning ahead.

When not to use Kanban

Kanban is sometimes adopted to hide a Scrum smell. Sometime an organization find himself incapable of planning and adopt Kanban way of working. However, the inability to plan can sometime be a real dysfunction needs solving. Maybe the PO is not doing a proper job in managing priorities, maybe an external force like the CEO is injecting too much noise… adopting Kanab in this states will only hide the problem (at least for some time). In these contexts Kanban can be viewed as a ScrumBut

The effects of doing Kanban

The most visible effect of Kanban is that from time to time team members will be blocked. Since the amount of WIP is very limited. there will be cases in which a team member is not allowed to pick up new work and needs to find himself something to do. The first option this member has is to help others. and indeed, One of the goals of a Kanban process is to generate teamwork in order to solve bottle necks in the process.

but there are cases in which one cant help others, this is the time in which a member works on improving the process. Whether by trying to understands why the bottle necks happens and resolve them. or by doing any kind of work to improve General productivity (Paying Technical debt, optimizing some development process, cleaning up…)

another Effect a Kanban has is the that regular measurements like Velocity burn down charts lose their meaning. You cant draw a burn down when not working in time boxes, the same goes for velocity. Instead in a Kanban process one use a modified Burn up chart in order to measure the WIP at any given time (where the goal is to minimize it) and ”lead time” which is the time it take for a task/feature to be finished (naturally the goal is to shorten the time).

To summarize Kanban is an agile process, which resemble Scrum but takes it a little further by adopting a flowing kind of process. It was successfully adopted by Toyota , and it can be adapted to enhance a Scrum process or to replace it in specific stages during the prodcut life cycle.

next Scaling the PO Role

Read more »

Posted in: Events,Random Thoughts,Scrum

Opening talk – Alistair Cockburn

The opening talk title was “Effective software development in the 21st century”. As promised by the title this session was packed with so many great insights, advices and ideas for me to be able to repeat them all. But some stuff did stick and I thought i should share.

Agile has grown beyond small organizations

Yes, this simple fact still comes as a surprise for people outside agile circles. However one must remember that originally Agile methodologies (mainly XP and Scrum) were created for such teams. A fact that some Agilists tend to forget. What is important that current methodologies, as used today, have grown, changed and adopted to all kind of projects and they are still growing. For example the trend in which more engineering practices are picked by organization doing Scrum might soon force the powers to be to finally include some of them in the “book of Scrum”. Yes who knows what the future of Scrum might be.

Software development as a cooperative game

A great metaphor the full details can be found here. In short, when looking at development as such a game we can say that:

1. Writing code can be viewed as a finite cooperative game with set targets, goals and an end.
2. Developing a product can be viewed as an infinite game in which the only true goal is to actually play the game hopefully as long as possible.
3. The process that we choose is the actual “Strategy” by which we choose to play the game.

so where that leaves us?

With two (actually more) important observations. First, like any other complex game you don’t find yourself in the same state twice,and a single winning strategy does not exists. In fact, when talking about strategies, the terms right or wrong does not apply, strategies are either weak or strong. What’s more important is that one can and should pick different strategies for different situation. A process which works for a startup company probably wont work as well for a big team. Second, the different in nature between writing code and developing a product might explain a very basic developing dilemma. On one end we want to ‘win’ the game of writing code, which has specific goals and a known end date. On the other side we must remember that from a product POV the game is infinite (hopefully) and we always want to be prepared fro the next “round’. Meaning that its not enough to write working software satisfying current needs. The quality of the written code must be kept good enough to support future development. And those two needs sometimes pull us in different directions

Developing Software is a Craft

its not the first time i hear this, there’s an ongoing growing movement of developers calling all to start treating writing software as a “profession”. Alistair however summed it up quite well

“A developer must relearn how to program every few years”

and indeed software development techniques are continuously changing. When I started out my first programming job involved writing code in C/functional C++ for an embedded system. A couple of years later I had to relearn how to program when i switched to develop using object oriented C++. A few year passed and I was introduce to Agile, which came with practices like TDD, pair programming. So again I had to relearn the skills of writing software, and last a couple of years ago, I started to developing under .NET which again made me relearn much of my skills. Bottom line I feel all these relearning is the only way to keep up with the profession of writing software.

Decisions as unit of inventory

The last part of the session discussed the idea that actually software development is mostly about making decisions, and that the speed by which we transfer those ideas between minds is what actually dictates the productivity of a development team. The best way to speed up development is by locating and removing all barriers which slows down this flow of ideas. For example the reason why distributed team are less efficient than collocated teams are that they communicate using inferior channels which of course reduce the efficiency in which we can transfer ideas.

The nice thing about using this analogy, is that the entire development cycle can now be reduced to a manufacturing line and all the appropriate theoretical knowledge can now be drawn upon. Specifically by using decisions as unit of inventory we can now map the stations along the development “line” and try to locate bottlenecks by recognizing the places in which decision are being delayed.

Summary

There was much more going in the session, in fact I’m sure that in order to grock it all ill need to listen to it at least a few more times. I do hope however that I managed to convey at least some of that knowledge.

Next post ScrumBan (how to use Kanban in Scrum)

Read more »

Posted in: Events,Scrum. Random Thoughts

Second Israeli Scrum Gathering

Well the second gathering has ended and it was great. while the amount of people coming this time seemed to be a little less than the first time (I estimate there were about 150-200). Content wise this day was way better. I think that this time most of the sessions were aimed for a more advanced audience, assuming at least basic knowledge of what is scrum and Agile.

Another improvement was that this time the keynote speaker was physically present. While it was nice hearing Ken Schwaber through a live feed, it didn’t have the same effect as having Alistair Cockburn in the same room. And hearing what Alistair has to say is fascinating (more on that will follow).

Like last time, the day was opened by a lecture given by the key note speaker followed by breaking up into 3 tracks lasting until the end of the day when we gathered for an ending panel discussion. all and all i was able to attend 5 sessions all of them were immensely interesting. I just wish that someone would find a solution enabling a person to attend two lectures at the same time.

Read more »

Posted in: Events,Scrum,XP

Off to Second Israel Scrum Gathering

The second Israeli Scrum User Group gathering is happening today. Last time was really good and I expect this time to be even better. the Key Note speaker of the Day is Dr. Alistair Cockburn and the rest of agenda also looks promising even more.

so if don't have any special plan I'm sure its not too late to come.

Read more »

Posted in: Events,Scrum