Software practices Archives - arian-celina.com

In most of my 15 years in Software Development, I’ve mainly been part of development teams which were practicing Scrum methodology. Although we have always aimed to do it right, somehow the organizational culture and operations methodology influences how Scrum was implemented in these teams. Recently, in my current team we decided to actually move from Scrum to Kanban. Here is how it turned out for us.

Why did we decided to switch?

I am very passionate about Software Development process. Without working process I believe it is not possible for a team to reach their output potential. Yet, I am not religious about methodology used. While one methodology in one environment may thrive, it may kill the productivity in one another. So, why did we decided to switch? Was Scrum not good enough for us?

Well, I would not say Scrum is not good. I’d rather say, in our organizational environment, it did not seem the most optimal methodology. There were certain details around Scrum that we were struggling to implement properly. While I believe that it’s OK if we id not implement it 100%, I also believe that if we are missing some core things, than something is not right.

What were we actually missing? Sprint goals! We were rarely actually meeting our Sprint goals and our burn down chart was rarely meeting the lower end. Why was this happening? Were we a lazy or a dysfunctional team? Actually completely the opposite. The team was and is very focused and very productive. It was just the environment that was not enabling us to achieve those goals.

In our department we embrace a DevOps culture. We don’t only develop solutions, we also run and maintain them. Also, in addition to modern cloud based solutions we have developed, we also have to support a legacy application which is old and with a lot of hidden details. Any time we were touching the legacy application, our estimation of tasks was completely deviating because of unknown surprises.

With all these constraints, it was often that while in the middle of the sprint, we had to change priorities because we needed to fix something in the legacy app or because we needed to attend to a customer incident. In such circumstances, we could not just tell our customers “wait until the next sprint because the current one is full”. Of course our customer centricity pushed us to react immediately and solve the problem of our customer, but often issues of this nature lead us missing the Sprint goals.

Another thing that was not working for us is estimations. Estimating software is difficult. Especially in Agile environments where you have to judge the “half specified” request and give a number. But then when you give the number, you have to live with the pressure to deliver on time. Plus, often we go ahead and plan for more than one Sprint because the backlog is always larger than one can deliver, and then you realize delays in one Sprint affect the others, but on the other side the business people expect the potential date you had given them. This was another major sign for us that Scrum is not the best methodology for our circumstances.

The transition to Kanban

We did the transition in small steps. First thing first, we had a joined workshop with the team and agreed on this transition and the steps. We also pictured how the new process will look like and how do we map existing process steps to the new one.

Of course, implementing Kanban by the book was difficult again for the same reasons. One has to adapt to the organizational requirements as well. We could for example transition to continuous deployment immediately. Technically we had all the mechanisms in place. Yet, we had to satisfy some organizational expectations. Our solution is used by customers around the world. Our account managers expect us to communicate the change to them so they can communicate to their corporate customers. We also get often their help in testing major changes, so just rolling updates without a schedule was not going to work well in our case.

What we decided was to apply Kanban and release to development and quality environments as continuously, but keep production releases on a regular schedule. So far, this is working quite well.

Initial Chaos

The first day or two when we transitioned the workflows things did not go perfect. We had some Jira ticket statuses mapped not exactly as we wanted, therefore our board got messed up. Fortunately, we were able to fix this in a day and things started to get back to normal. Also, during the first week, it happened that people were confused about the flow of the process but everyone got used to it quite fast

The joy of on-demand prioritization

One of the main benefits of Kanban is that we can re-prioritize the priority backlog as often as we need. Is there a new business requirement, a burning customer incident, or a support request, we can adjust the priority on demand without feeling the stress of missing sprint objectives. This has released especially the “friction” between the Product Manger (facing pressure from the customers) and the development lead (trying to maintain the sprint promise).

Feedback from the developers

Whenever I have to drive such a change, I like to constantly get the feedback of the team mates and adjust/pivot in necessary. So far, I’ve mainly received positive feedback from the team about Kanban.

Developers feel less under pressure when they do not see a waiting list of tickets for the sprint. While we have the same level of productivity, it now feels more like a flow rather than a milestone based sprint.

This change has also substituted ceremony meetings (prioritization, tech planning, retro and review) with on-demand fully focused meetings. This has created more productivity time for the team.

Conclusion

Again, going back to my initial statement, it’s not that Scrum is bad per se. It just was not the best methodology for our circumstances. Moving to Kanban was an opportunity for us to improve our process to something that fits our needs better. So far, it has been a very rewarding experience and we enjoy it. Of course, after some time we’ll have to revisit this as well and see if we need to move ahead to something else. Continuous improvement is what we enjoy!

At my current company, Springer Nature, we have a great benefit of having the freedom to dedicate 10 percent of our work time working for a side project, learn something new, or on anything that can help us learn something new. Our employer gave us this freedom so we can grow personally and professionally, but one observation I have had during these months that we are practicing this was that it also helps to unleash employee creativity.

How we do it?

This initiative firstly started as a Hack Day for developers. Then we renamed it to “10 percent time” so it can be more inclusive to other profiles that are part of our department, such as UI & UX designers, PMs, and POs. We spend every second Friday of the month by doing something other than work related stuff, something that would in one way or another help us learn something new. Sometimes we do an online course, test that new version of a library we use every day, evaluate a new framework or even learn a new programming language. Beginning of the day we do a joint stand up where we share our plans for that day with other participants. Sometimes someone likes somebody’s idea and we join forces for that day to create something awesome. By the end of the day, we gather together and share what we have created and what did we learn. Some do a demo, some showcase their code and some just summarize their learnings. During this sharing session often people get the inspiration for their next hack day, or sometimes we realize that a presented idea could be of a benefit for the company to grow as a project and we pitch it to our colleagues and management.

What did we do during these days?

During the previous Hack Day, one of my colleagues did create a simple NodeJS CRUD API as she wanted to learn NodeJS. On the other side, as I usually do backend stuff, from time to time I am quite interested to learn things about frontend. For a long time, I wanted to learn Vue.js, so I volunteered to create the frontend for that API. During those few hours of coding, we managed to do a simple Vue.js application and implement a frontend for CRUD operations of that API. The code can be found at https://github.com/acelina/books-fe GitHub repo. Of course, I didn’t become proficient in Vue.js in one day, but next time I need a frontend for my app, at least I know where to start and I value this.

In another case, me and a colleague of mine started a Hack Day project to improve the process of managing code challenges for our developer candidates. We worked on this project for three Hack Days. The result was an application that included features like managing the automatic creation of a GitHub repo for a candidate, including there her code challenge and give her the privileges to commit to that repo. It also included the feature to manage the workflow of submission, so when the candidate creates a PR of her finished code challenge, the application will remove her from project collaborators and notifies us in a Slack channel that a submission is ready to be reviewed. It was a three fun Hack Days for two of us and it resulted in a production-ready application which eliminated manual labor. There are several other successful results which came out of this 10 percent time.

What we achieved?

I understand that the projects we do during these days are never ready for production, but we achieved to create a culture of sharing the knowledge with others and by it to foster employee creativity. This 10 percent time creates space for us to experiments with things we don’t have the time to experiment during our regular work days because of deadlines or priorities. It also helps us to grow professionally and personally. Sometimes it results in a useful thing for the company as well, and most importantly it helps us to unleash our creativity while having fun. As a developer, I value this a lot in a company, and I would recommend every company to start practicing it. You never know where brilliant ideas come from!

Moving from Scrum to Kanban