Different Roles in a Full Stack Team

I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.

I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)

But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.

At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.

When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.

Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.

Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.

As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)

Second Release Planning Day

Before the summer I wrote about our first attempt to do a whole company Release Planning Day. Since we do releases in regular cadence, now was the time to try this activity again.

After the first trial I had received feedback that doing everything in one day was maybe a bit too overwhelming. One concrete remedy was to divide the activities to two days. Another improvement that I was happy to witness, was that this time the Product Managers really prepared for the event. They discussed and worked on their Roadmaps together with the teams during the past couple of weeks. And this activity really paid of in the quality and in the level of realism.

People took the event seriously. Even though one of our Business Owners and a Product Manager were visiting customers abroad, they took the time to do their part in the agenda. Their presentations were broadcasted over a VOIP connection. But for me the message was clear: this event is really important.

The first day started as during our first time. The schedule for the day had been delivered to everyone already via email, but I briefly revisited the agenda. Then our Business Owners gave an overview of the market situation. What is happening now and how we should prepare for the future.

Next the Product Managers shared their Product Roadmaps. We are still working on these and lot had changed since the last Release. Mainly many not-so-well prepared themes had been dropped and returned back to the funnel stage. There were clear pros and cons for this approach. Now the organization was able to focus the attention on the few Epics, but on the other hand, the longer term visibility was missing from the plans. But I'm confident we can work that out in the future.

We are still figuring out our Architectural Runway and how to coordinate it on the Program level. But as the manager of our System Team, I used some time to tell about the tool changes we are about to carry out during the coming Release Period.

After the common sessions it was time to split into teams and start forming the draft plans. Teams collaborated with the stakeholders and tried to formulate the needs of the business into a realistic set of PI Objectives. Actually, in our company language we call these Epics, since that's how they are called in JIRA Agile. The lunch hour was also incorporated into the first Team Breakout.

The next common session was the Draft Plan Review. Every Product Owner presented their team's draft Release Plan. This way it was easy to spot if something was missing or required coordination with other teams. There were no major surprises. It was as if people had actually discussed their plans together. Oh boy, who could have seen that coming!?

After the Review there were two options. Teams could continue planning today or go home and rest. The next common session was scheduled for the morning of the next day. Since we have development team members in multiple time-zones, I thought it was ok to offer possibility to carry on the planning on one site and pick up earlier on the next morning on the other site. Also the splitting gave people more time to do the planning. And at least I felt rather exhausted in the afternoon already.

I don't actually know how the teams decided to do. Maybe some continued the planning, maybe some went home early. Anyway, the next morning we gathered again to a common session to go through the finalized plans. Most of the plans had not changed much since the draft phase, but I believe it was good to have time to digest them a bit and work out the dependencies if any. There were still some questions and comments but generally people were satisfied with the plans.

In the end I wanted again to have a vote of confidence for the plans. Just so that nobody could walk away from the event and say it was not their plan. At first it felt a bit silly. And it was. So in the end I turned holding the microphone to the crowd and yelling "DO YOU BELIEVE IN THIS PLAN!!?" And they did. :)