Story of being a Scrum Master – Part II

Second Milestone

Continuous Deployment

After the first month was over I recognized that the project lacked consistent processes. Besides a Scrum Framework skeleton, which was maintained to the existing standards of the department – thus without the claim to grow agility in the project or surrounding organization –, only a bi-weekly deployment of the latest green build was reoccurring. This bi-weekly deployment always caused a lot of stress among the people.
Now with CI it was better already, as not UI bug or deprecated functionality would be deployed any longer. Still every two weeks the stress grew and all too often release of features would be postponed to the end of the next Sprint. It actually became a practice in the team to better go save then sorry, by postponing releases. This was an agile adaptation already, but only to the cost of overall slowdown of the project flow.

Thus I decided to go the next logical step and move the project towards Continuous Deployment (CD). CD describes the ability to deploy the latest features of your software as soon as the coding and testing is done. The developer trusted with system engineerin tasks agreed that it is certainly possible to not trigger a full deployment to all productive systems at the same time, but to deliver to them precisely based on customer requirements.
With him onboard I started to convince the development team and the PO to work with “deployment tickets”, which would be put up whenever a Story had been closed. The PO was hesitant but with the system engineer on my side she was able to trust on the benefit of such change.

The dev. team was not used to create tickets and so I did that. I wasn’t able to change the working style from zero to hero, and so I agreed to this compromise and took a mental note to train the development team to put up tickets by themselves.
Later on I was able to do so under the two flags of Team Empowerment and Code Ownership.

The ticketing worked great, the PO was now able to drag deployment tickets to the sprint and the system engineer would pick them up and deploy accordingly. The bi-weekly pressure and introduced late work was a thing of the past.

Agility to the people

In May I had thus made my entry to the team, and earned my right to stay. Now I got tasks from all sides.
This was due to the fact, that the project had been managed in an ad-hoc management style, in combination with planning the architecture ahead in a plan driven way. This had been successful as the project had a couple of high end developers who had earned their laurels by creating this software in the first place.

Ad-hoc management describes the practice to fulfill always the most urgent or pressing requirement. Thereby it is a save way to not run into a big failure in the project. It also has the benefit that unimportant tasks will never be considered meaningful, as they simply would not pop up into the visual field.
In other words: This evolutionary approach, of whatever swims we look at and what doesn’t is dead anyway, has advantages over plan-driven management as it reduces overhead to a minimum. It also fails to make a project efficient when it grows over time, as a larger code base and infrastructure has a bigger need for maintenance and thus will generate more tasks to take care for overall.

Agile-driven management is based on trust, and therefore it is one of the most important tasks of a Scrum Master to protect the dev. team from outside influences (including the PO as long as the dev. team doesn’t has the need for clarification). During the Sprint the programmers can develop trust bonds by working together undisrupted, while the PO learns to trust that the Sprint Goal gets reached everytime, and therefor agrees to only put up new work by the beginning of a new Sprint.

Thus, I partially had to take over the role of an IT-Manager, since the developers were mostly juniors and busy with skilling themselves up with project related coding and system knowledge. While doing so I waited for team members to grow the capability of taking over such responsibilies themselves – without getting managed, but by using agility to take care by themselves.

I soon made it my habit to answer “I will take care of it”. But I never put an emphasize on showing what I did, as it is the servant leader role that ultimately makes the Scrum Master the most powerful. With this mindset I started to praise the dev. team and any successful collaboration or good practice to promote the growth of a strong team identity.

—

Thank you for reading! I will discontinue writing for now, as this project is still ongoing.. Any questions comments or else is welcome.

Best Regards,
Pau