Outlook : Coping with digitization and automation in an organisation
Digitization
has become the buzz word in the growing world of any industry – it has more
specifically struck the IT world majorly.
Digitization is the ability to do
things differently with the help of technology to deliver new added value to
the existing customers and business. Automation on the
other hand gives the ability to process the tasks done by humans to be done by
machines now.
Clubbed
together – they are here to revolutionize the industry with its set of pros and
cons and this is definitely the way forward for the Indian IT sector.
If I could explain this with an example – let’s say in a hospital a patient has been admitted. Now the traditional setup demanded that the nurse would take the reading of the patient each morning and put the board across his bed. When the doctor would take his regular round for each of the patients, he would see the sheet only then. There could be possibilities that the doctor would notice some anomalies/symptoms now, which might have been missed by the nurse. This could result in uncertain mishaps.
Going digital would mean ditching the regular paper method for the tablet or laptop or phone to be used for collecting the readings.
But going a step further and digitalizing and automating the process would mean as soon as the readings are taken by the nurse, in case of any anomalies in the readings based on certain parameters a notification would be triggered to the doctor – which would draw his attention to any probable issue sooner. Furthermore, also if this data is stored in the cloud and made accessible across hospitals and doctors – it could be used as a metric for any future problems which would occur with the patient. The data could prove to be a useful metric in determining future health issues and averting them.
Digitization and automation are a medium to provide ample opportunities to innovate and do things in a manner which will better the entire process. In the quest to accomplish digitalization and automation, in the world of IT, no company wants to be left behind in the usage of the latest technologies or the methodologies to achieve this. The companies are jumping fast to implement procedural changes that will help them accomplish their goals and deliver values to the customer.
Like
every other company competing in its own way to cope with digitization and
automation to provide the best to the customers and their employees - our
organization also revamped in a major way with the implementation of the Agile
process.
If I could explain this with an example – let’s say in a hospital a patient has been admitted. Now the traditional setup demanded that the nurse would take the reading of the patient each morning and put the board across his bed. When the doctor would take his regular round for each of the patients, he would see the sheet only then. There could be possibilities that the doctor would notice some anomalies/symptoms now, which might have been missed by the nurse. This could result in uncertain mishaps.
Going digital would mean ditching the regular paper method for the tablet or laptop or phone to be used for collecting the readings.
But going a step further and digitalizing and automating the process would mean as soon as the readings are taken by the nurse, in case of any anomalies in the readings based on certain parameters a notification would be triggered to the doctor – which would draw his attention to any probable issue sooner. Furthermore, also if this data is stored in the cloud and made accessible across hospitals and doctors – it could be used as a metric for any future problems which would occur with the patient. The data could prove to be a useful metric in determining future health issues and averting them.
Digitization and automation are a medium to provide ample opportunities to innovate and do things in a manner which will better the entire process. In the quest to accomplish digitalization and automation, in the world of IT, no company wants to be left behind in the usage of the latest technologies or the methodologies to achieve this. The companies are jumping fast to implement procedural changes that will help them accomplish their goals and deliver values to the customer.
Background
It was an incremental approach of rethinking on our business model to catch up with the buzz words of digitization and automation – faster, agile and closer to customers. Without the framework in hand, automation and digitization would be a distant dream. The implementation helped us take our customer a step closer towards the digitization and automation world – giving them the niche for it.
It was the cultural shift and the flexibility that was needed, was to be made first – this would slowly empower the people to think in a certain way, a through process needed to improve the business.
From following the traditional waterfall model which had been followed in the organization for a long tenure – the Agile way of working demanded a reorganization at both the customer and organization level. It meant it was just not enough for the organization to go agile, even the customer would need to go agile along with us.
Our customer and organization needed to work hand in hand, for this implementation to flow through successfully.
Where for a project to be delivered, it could essentially take more than 6 months and per say if at any point there was any change that was needed, it would mean going back to scratch and starting from there. This was immensely time consuming and cost consuming for both the customer and the company.
Moving from this traditional waterfall approach to the Agile world had its own share of impediments.
To implement Agile in just a competency center of over 600 people was a hard one to hit on.
As we know, Agile demands development cycle to be done in a complete different manner, it has hence ensured its place as the “gold standard”.
It is based on the four core principles outlined in the Agile Manifesto, where it aims in planning in an adaptive manner, delivering pieces early and a chance provided for continuous improvement – it provides a way to respond easily to change and act on it.
Manifesto for Agile Software Development:
-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan
The organizational decision-making processes
The decision-making process was not a difficult one to get through – adding to it was an initiative driven specifically to benefit the organization. The leaders had a clear goal and vision to move to this change. And the information was trickled down to all the stakeholders appropriately.
As Agile promotes continuous iteration of development and testing through the entire cycle of the software development, it was in the best interest of the organization to take in more work and serve the customer in a way that quick changes could be delivered to them – which would in turn could render more business for them. Although there was a lot of work that needed to be done to align us to Agile methodology of working –yet it was worth the effort.
Stakeholder imperatives
Scrum, is a method which concentrates on how to manage tasks within a team based development environment.
A trivia – scrum is derived from an activity that occurs during a rugby match.
The key concept - giving the customer the ability to provide early and frequent feed backs as the software is being developed. Although slightly unstructured I would say, but it aided in quicker implementation – allowing changes to be incorporated at any stage of the software life cycle till it has been floated to production.
Scrum takes a highly iterative approach and follows a completely different format than the traditional waterfall approach. It definitely reduces the risk and provides value to the customer. It is the iterative approach that makes it a viable option to implement - where the traditional waterfall methodology relies heavily on the documentation, Scrum reduces this to quite an extent – because heavy documentation makes it harder to change the features as the stages move forward.
The key members who are involved:
-Stakeholders – business folks, Implementation managers
-Scrum product owner - owns the project having an end to end knowledge of the where about of the project. The Scrum Product Owner would be the go to person who would have a clear understanding of project and be the point of contact for the scrum teams. They would interact with the business regularly and get regular feed backs on the features being developed. The Scrum Product Owner would be responsible for creating the features and placing it in the product backlog. This would further need to be prioritized as per the customer urgency of its implementation.
-Business analysts
-Scrum master - The traditional team lead roles were aligned with that of Scrum Master – whose main responsibility lied in getting the tasks done in the right way, on time, removing the impediments and managing the obstacles.
-Developers
-Testers Since Scrum methodology calls for a collaboration between the testers, developers, business analysts quite early in the game – it helps in a better understanding of the requirement by all the stakeholders.
Manner in which the change was implemented
As a result, the team having a size of 25 members – was broken down to smaller scrum teams with about 6-7 members at maximum. The team members were assigned to each scrum team based on their specialization in development and testing. This alignment was done such as to promote the ability of each scrum team to take up tasks independently and execute the project end to end.
The tool that was used to manage the entire implementation was moved from the in house application to CA Rally. There were major changes implemented in the deployment timelines of the projects.
A development cycle had the key features as:
-Iteration which is known as Sprint –> The development is done typically in a Sprint, which can be anywhere between 2-4 weeks.
-Product backlog –> repository of the requirements that are to be tracked and pulled into respective release. It must be maintained and prioritized by the PO.
-Feature –> A functionality which creates marketable value to the customer. Although this implementation also necessarily meant elimination of an important phase in the software development cycle i.e system testing.
There was changes implemented from ground level i.e right from Requirement gathering till the deployment. Let me get you through each of the phases and its implementation:
Requirement gathering For each project there would be multiple business analysts who would be contributing towards the project, by working in various applications involved in the project. But for each of these project being implemented now on, there would be one Scrum Product Owner who would own the project having an end to end knowledge of the where about of the project. The Scrum Product Owner would be responsible for creating the features and placing it in the product backlog. This would also need to be prioritized as per the customer urgency of its implementation.
Sprint Planning In this phase, the Scrum Product Owner would meet with the Scrum Master and align what work would pulled in Sprint from the product backlog into Sprint backlog. Then the Scrum Product Owner would create related user stories for each of the features that is pulled in to be worked on. The user story would hold the details of what would be developed and clarify the acceptance criteria. Each user story would have the progress tracked – Development, In Progress, Accepted , Blocked.
Sprint Grooming In the grooming meeting, the capacity planning would be done to see what is the amount of work that can be pulled in the Sprint based on the availability of the scrum team members. This calculation would be based on a common matrix developed for the team – number of working days of the team members, planned leaves and a buffer of unplanned leaves would also be considered. An end to end overview of the features would be provided by the Scrum Product Owner to the Scrum team. This would serve as an official hand off to the Scrum team. Here in this phase, there would be story pointing done – where each scrum team member can choose which user story they want to work on, and how many days/points it would take to complete the task in hand.
Development The Scrum team starts to work towards the features assigned in the Sprint. The scrum master owns the responsibility to maintain the Rally, making sure each user story has respective tasks assigned to it. The tracking of the progress of the Sprint lies on the shoulder of the Scrum Master – to aid this, there are daily 5 minute stand up meetings arranged where the scrum team members would provide update for 3 questions – What they did yesterday, What they would do today, Any blockers they are facing. Automation was majorly used in the development phase from using tools like Junit, test driven development, Sonar, automated test cases, Jenkins and various other tools. Once a user story is completed by the developer, the Scrum Master would then arrange a demo meeting with the Scrum Product Owner. If all the criteria of the acceptance for the user story are validated, then the Scrum Product Owner would accept the user story.
Sprint Retrospective It was here that the team would get together again at the end of the Sprint – they would each have a sticky note with the below details:
- One good thing in the Sprint
- The lesson learnt in the Sprint
- Improvements needed.
Impacts on the people, their behaviors and attitudes
This required restructuring at a larger level - the company tried to align our roles as per the norms of scrum.
This led to elimination of many static roles in the hierarchy. Although we were aligned to the benefits of the implementation, there was quite some resistance to this change process right from the development to the higher management.
It meant people working in some roles from a long period of time, had to now align themselves as per the new roles and responsibilities. These new roles and responsibilities would not be something they would be comfortable in working on. The ownership of each individual considerably increased for the tasks done by them.
The process also meant right information needed to be trickled up the hierarchy and everybody needed to be well informed about the developments happening – as the timelines were tight to deliver a shippable product.
Did the intended outcomes occur
It came with its set of challenges right from aligning people mindset, role alignment, correct implementation of the scrum methodology. The complete alignment of the existing work force to now, towards the Agile Methodology was a tedious and time consuming task – took over 6 months to stabilize and put everything in place.
We were now in a position to take up projects that could delivered in a time frame of 2-4 weeks – continuous development, continuous deployment helped customers come up with better ideas to digitalize their business because of the platform we had provided.
What were the positives and negatives associated with the change
It also involved more engagement from the development, who in the traditional waterfall would have to wait for longer to get work on their lap.
It led us to suggest better business ideas which would add overall business value. It helped our customer business grow because of the faster implementation.
Negatives: An entire competency center of testing had to eliminated as a result of this implementation.
The testing team members were embedded as a part of the Scrum team which essentially meant that the testing and development would work in close proximity. This also enabled in better understanding of the projects.
There were more meetings that one had to attend, which was time consuming.
The implementation also resulted in a marketable feature being comparatively less tested than used to happen in the waterfall model.
How did you cope with the change process:
This meant more work and ownership in my bucket. I had to own a product and see to it, that it was being delivered on time with quality and standards followed. I had to adapt to the new ways of documentation i.e working on creating features, maintaining backlogs, creating user stories, sprint planning, grooming sessions with team, sprint retrospective. It was a good change although it did increase my share of work from the previous model.
But it also enabled me to have frequent discussion with the business and all the stakeholders in the project, to be able to deliver the best to the customer.
The process in a nutshell:
Success story:
Our system had to be made compliant to be able to add these offers automatically to the existing customers who were willing to upgrade their devices. And with true collaboration and implementation of the Agile methodology, we could deliver the implementation in a time frame of less than 1 week.
As the requirements got clear, the scrum teams started work on it using automated methods of development and post that, the scrum tester tested the end to end functionality ensuring its correct implementation using automated testing. Once testing was certified, it was quickly deployed in our user acceptance test environments by the Infra folks – were it was client tested. Soon, the production support folks were involved to provide input towards the implementation and testing – once certified by them, it was finally pushed into production environments.
So there was a collaboration between development, testing, infra, support folks to bring out a satisfactory shippable product at the end.
This was also a preview of how we were progressively moving towards the devOps way of working. It got more maturity in the team’s way of working – makes their mindset customer centric.
This would have been a distant dream in the waterfall model.
Cheers to life!!
~Believe in yourself always!
© Please do not use the above content without my permission - it is part of my project work at IIMB.
Sources:
https://www.guru99.com/agile-scrum-extreme-testing.html
https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/
Comments
Post a Comment