After completing my engineering degree, I stepped into the IT industry by joining a small startup company which used to work on web development. I was happy to get my first job so early but felt a difference between what we were taught in college and how we were following in the company. I had learned various SDLC methods in college but nothing was used here. Basically, there was no focus on project management at all. I ignored the fact and kept working there with all hard work which required for my position.

After one year I switched to another company and felt that they were at-least following something which helped assignment of tasks and tracking the tasks as per priority including close engagement with client but still far away from any proper SDLC. At this moment, I accepted the fact that working in a industry is entirely different from what theoretical concepts I learned in college. I ignored all project management related stuffs and focused on my programming skills and thought that as a most important thing.

Exposure to Kanban:

In my 3rd company, I saw they were following a very different approach. They used to create requirement documents with tasks divided in milestones. Milestones had various modules and tasks under each module. They used to post everything on basecamp where tasks were tracked with status like pending, in progress, testing, done. It also helped me to know the tasks assigned to me as in earlier company before starting the work it was upto developer which task he/she chooses. I liked the process and somewhere in my mind I knew we are following some sort of proper SDLC but was not sure which one. In a session of the company, it threw the term Kanban. I was told Toyoto used it to improve its manufacturing process. I spotted, we were using Kanban with our own touch to it

Moved to my current company and saw they were using similar method where we create possible tasks and divide in milestones and assign tasks and track with status. We worked on more documentation and clarity of requirements as some improvements but one thing kept derailing us. It was always a delay in project delivery of bigger projects as more focus was on just tasks and no real timelines were defined as projects were moving as per the skills and capability of resource. Though it was a successful for smaller projects as tasks were less and estimation and completion was easy.

Disadvantages felt for Kanban kind of approach:
1. Kanban is a natural process which we follow unknowingly but it does not work for bigger projects and projects kept in development stage forever.

2. Less human interaction like face to face meeting cause the disconnection between teams and people end up doing entirely different things as per their understanding

3. Lack of team roles made it difficult to set timeline for release and often release did not contain a useful version for the client

4. Tasks were assigned and left upto the developer’s capability to complete so a difference in completion of task and causing delay in release

5. Blockers were not always known and natural lack of communication in Kanban kept the blocker for long timeline

6. Tasks were adding more often in backlog which creates forever development without any timeline.

7. We tried to assign timelines for tasks but different capability or resources made it unachievable.

8. Projects were losing money for client and increased client complaints about delivery.

9. Lack of client involvement in the process blurred the transparency and most often client don’t have idea about the progress.

Experiment with Scrum:
We all were tired with the disadvantages of our current process and things got worse as our team strength and frequency of bigger project increased. We wanted something that works. We researched about different project development methods including Scrum and thought to give it a try. Coming from Kanban flavour, it was a bit familiar as both related to agile methodology. It also had backlog like Kanban but backlog had better explanation in the form of user stories with user story acceptance criteria. It made hell lot improvement in task understanding and decreased re-work.

Now, it was not just a statement with vague description but a practical story point with criteria defined to complete the task. By using Epic(a distant categorization of task), it further helped us to move towards modular approach of software development. We could define an Epic eg. User dashboard and add user stories related to all features required in dashboard. Sprints made easy planning by choosing the chunk of smaller tasks fulfilled with planning poker created better understanding of team capability resulted in better project estimation. The daily scrum(face to face) made easy to clear up any blocker and smooth development process.

There were defined role which had their responsibility like Scrum Master has responsibility to plan sprint, product owner or client representative’s responsibility was to clarify requirements, show vision and usability in the sprint further to avoid re-work. It also helps client to know the real-time status of project to aid in his/her launch and marketing related work. Team members work is to complete the sprint tasks withing set time.

Improved the BA and QA process to aid further:

We had a process of QA for bigger projects and BA responsibility was handles by project managers but we felt it needed a revamp as often project manager failed to pen down complete scope of project. We built the BA team who initially documented the vision of the project which also helped in project estimation and proceeding further in development with scrum. We expanded the QA team and now QA is a mandatory for all projects who approves the release. It ensures quality and also reduces headache for the client as they see better release and for us it reduces re-work.

Initial result of the new process:
After all these changes, it took sometime to streamline the process but end results were great. It enabled accurate forecasting of release date, more efficient overall development time, increased quality and client satisfaction. All in all, we are enjoying it and will keep this improving as we go further.

Some mixed setbacks but positive hopes:
Increased process increased the required heads for the project which resulted in a slightly increased overall budget and now I see clients questioning more about the slightly higher budget but luckily we can explain them the cause and process and they do understand it. Overall, it is not a big deal to pay slightly more for a better product.

This was my overall experience of different processes faced in companies I worked. In my case, scrum worked best for our situation and may be it is opposite for you. The intention of this article is not to praise scrum and reject Kanban but to show my journey towards Scrum.