Scales and Emergent Properties

It is fascinating how things look different depending on the distance. From space Earth looks like a blue ball with some green stuff here and there. By zooming closer one can see the continents and mountains and some of the biggest man-made structures like highways. Going closer still and taking a helicopter view the individual houses are yet indistinguishable, but cities have forms.

Humans can't usually see the forest for the trees. Trees are closer to our scale and we usually look at them from the ground up, not from top down. Also we and all the organic material around us consists of small cells. Many of them have a specific purposes (like muscle or brain cells). They are visible with a microscope.

If you could magnify even more, you would see that even the cells aren't the ultimate building blocks. They could be further divided into atoms which could be further divided into quarks (and maybe even further, but let's stop here.)

Many of these levels have their own forces and interactions. Quarks can feel the strong interaction (or nuclear force). In their world, gravity or electromagnetism isn't very interesting. On the other hand, interactions and events on the cosmic scale take so long and distances are so big that compared to them the human lifespan is only a drop in an ocean.

The same fascinating scale related properties exist also in the corporate world. Individual people, teams, units and companies work on different scales. After saying this I do admit that some exceptional individuals might match the output of a whole team or even a small company. But I'd claim that there are such efforts that simply aren't doable without the appropriate size. And yes, on the other hand bigger scale usually makes things more stiff and slower.

I think a team has a lot better chances to really finish a software feature. And I mean the whole deal: thinking about the usability, implementation, documentation, testing, optimizing, refactoring and packaging everything into an appealing form. And if we go a bit further and think about productization of an idea, I think a company is better off than a team or an individual. Sales and marketing are essential activities. But such capabilities aren't often found in the standard developer skill set. For a company to be successful, both skills are needed. But individual people can be highly successful in their roles with only one of these skills.

No-one can do everything. By working together we can make great things happen. With the joint effort of brilliant minds we have been able to reach the space and descend into the deepest ocean depths. If we could work together as a planet who knows where we would end up... But currently I'm happy to follow the road ahead with my company. :)

Release Planning in One Day

In this blog I have shared experiences of our Release Planning Days. Of course the first one was most memorable since back then everything was new and exciting. Second attempt proved that it wasn't pure luck, but that the concept was actually working. I documented also the third one, but after that I thought that it maybe isn't that exciting anymore.

One unfortunate thing to mention is that the day was a public holiday in one of our offices. But quite a few of our colleagues from that site were willing to come to work on that day and get another day free in exchange. I call that going the extra mile.

But maybe I can tell about the most recent attempt, since it was again a bit different from the previous times. For our latest Release Planning I had given some of my colleagues a few chores to fill in advance. Here's the list:

• Portfolio Backlog is in presentable state
• Product Managers have discussed their the Roadmaps with teams working directly with them
• Product Managers have made an initial Launch Plan for their products
• Product Owners have crafted Draft Release Plans for their teams

Out of these, the first task went to our Chief Portfolio Officer who is like the Grand Vizier of the Portfolio level. Second and third tasks went to Product Managers (Program level) and the fourth one to the Product Owners (Team level). 

Launch Plan is a term that isn't originally from SAFe (as far as I know). It communicates the intended usage of the Release if and when it would be successful. Previously we had identified a waste of extra waiting time when the Release was ready, but we had not decided what to do with it. The accompanied business needs are in most cases clear already when the work on the release starts. That's why it is practical to craft also a plan about the usage. And if something is left our the Release scope, the plan can be adjusted.

So, in essence we skipped the first Team Breakout. Also the organization of the presentations was modified. In our past Release Plannings all Product Managers have presented their Roadmaps in a row. But since we had the Draft Release Plans already available at the beginning of the event, I wanted to form logical entities of the Roadmaps and associated Release Plans. This also helped in focusing on one subject at a time.

The morning part of the day was heavy. That was clear already beforehand. But we didn't come up with any better alternatives. At least grouping the presentations in the new way was seen as an improvement.

All in all things went pretty much as expected. During the Team Breakout some plans were modified but most of them were almost the same as during the draft phase. The new, more compact way of conducting the day seemed to work well and we will probably do it like this also next time.