Do not just follow the process, observe, improvise and adapt

During last few years, I worked as a Scrum Master who is responsible for process activities, I learned a lot related to ISO/SCRUM rules and its behaviors. As a starter, I tend to do the same as what process tries to explain and implant. I tried to tally each process item to the project workflow and make an extra effort to maintain the process conformity. Sometimes I have created some documents and graphs which do not have much contribution to the smooth progress of the project. However, I do not want to think differently as I thought it will harm to the process and then the process marks will go down (NB: In our company, there are some marks for the process conformity).

But when there are a lot of issues due to particular project behaviors and stakeholder requirements, we tend to apply different principles, methodologies and exceptions become more realistic with what we are actually doing inside the project. In other words, we try to think out of the box and applied necessary process changes to be more practical, visible and productive while confirming to the process.

In the next few paragraphs, I will try to explain what are the particular project behaviors / stakeholder requirements and how we changed the way we are doing in order to be ISO confirmed and practical within an agile scrum environment.

What are the particular project behaviors and stakeholder requirements?

In that period of time, from the pool of projects, our project is the most prioritized one in their stack and we were pressurized to release features very frequently. And they did not support much for the process things since the mindset was towards release items and time to market. First they gave us 10 big features and set a deadline, which is not that suitable for an agile scrum environment. Initially we tried to explain the situation related to process, etc., but those are not much considered.

In that time we had 2 weeks sprints and we had to create a lot of artifacts in order to confirm the project and process for each sprint. And also we do not have much idea about the sprint outcome and that is not tallied with the deliverables as we cannot give a shippable product within 2 weeks. But as product owners, they are expecting a release after every sprint.

And also, due to the big regression work we have to do before a release, we have asked for test automation suite several times but, those are not accepted as they need features more than else (though that is not the correct way and maybe they were also know that). As well as test automation, we asked to do thorough performance assessment, but the answer was the same.

While these things are happening, as a Scrum Master, I also pressurized due the process and product work. But one day I thought this is not going to work and this will end up in nowhere. Hence I have started to create a process or way of working which is suitable for the current situation and also can maintain the process conformity. In other words, a way to simplify the process/work pattern to cater the project delivery needs and avoid extra work.

What we did to become more realistic in process, improve visibility and avoid extra work?

We did a few things to make the change and those are as follows:

1.  Learn the process well

First of all, what we did was we went to the process head and know about the company process well. Not only the documented points, but the essence one by one, what he said was that if you need any changes, do it and add those to the exception document. And most importantly he said that we do not need to do the exact thing what process doc says. But do things which brings what process hope to add to the project.

2.  Learn different methodologies and applied

In that period, we followed scrum but actually it was “SCRUM BUT”. Hence, we have introduced new but sustainable methodology called Scrumban which is a combination of Scrum and Kanban. Because the application is in the production and it is sort of in the maintenance + adding feature phase and we need to follow some of the best scrum practices such as daily standups, grooming sessions, demos, retrospectives, etc. It gave us more flexibility on ceremonies. And also we have changed the sprint length to one month, which minimize the overhead as we do not need to start, close sprints and no need to create documents every two weeks. Hence, we had more time to do project work while doing the bare minimum to satisfy the process needs and product quality.

Following is the diagram which I was created to depict the full process of the application (Start to Release) 

3.  Learn how to make the proper artifacts and improve customer visibility, which we really need.

Then we come up with proper artifacts such as exception document, release related statistics, project matrixes for all the releases, the progress status of the major features (10 features) and all the bugs added/resolved which all the stakeholders can see. Specially, the stakeholders are like to see the current statistics, hence we should make sure that the visibility is there. If not, they will suddenly come and ask questions which we do not have any clue at all. Glad to say that, the CTO who was there at that time, looked at the progress status page more frequently to understand the progress and releases. He always adding comments to that page so it was a live document. Likewise, proper artifacts will add more value rather than traditional documents.

Finally, hope this blog will help you to understand the real meaning of ‘Do not just follow the process. Observe, improvise and adapted’. Thank you.