Transitioning from Waterfall to Agile Scrum

These days we started to hear agile and scrum terms a lot. Reading papers and watching videos about them give us some ideas what are they. If you are coming from telecommunications industry, you may have experienced that waterfall is a primitive project management methodology.

Project management has boundaries: Time, Scope, and Budget. If any of these boundaries expands, it affects the subjects. If you can’t determine the scope well, your project may take longer to be completed. If your project is completed after the final date, you don’t have budget to complete project. It means that you have also limited time. If organizations stick into the project phases strictly, it doesn’t allow changes.

I have never experienced a project which is managed by waterfall methodology completed exactly on agreed time, with exact scope, and with exact budget. Because people aren’t great. People aren’t able to work together for a long duration on a critical path. They fail. It doesn’t matter who fail. All may fail from analysts to developers, from QA to site engineers.

Why?

It’s a serious question. Boundaries make pressure on the people. If you love traveling and if you stuck in your home country, you feel the pressure. It’s a similar experience. Waterfall starts with analysis, and continues development, development, testing, deployment, and finally going live. Let’s assume the efforts for teams. 10 days analysis, 20 days development, 10 days testing and 5 days going live. It’s already 45 business days. You are not allowed to make changes on any boundary. Project must be completed within this time period.

To answer change requests faster, people are in scrum teams. Scrum teams consist of up to 9 people. But scrum isn’t just limited to teams. Organization should be managed with this mindset for greater success.

What?

Each project should be assessed independently to choose a methodology. If your company sells on premise solutions to the enterprise customers and you rarely make changes on these software while delivering it to your customer, you know how to proceed. Waterfall is the best if you are not going to rebuild all the software from scratch. Scrum is the best if you would like to launch something from inception to completion or continue to improve your software with a roadmap. You can simply build a working prototype and it’s going to be ready to use as a service in couple of weeks. Let’s go from an example. Television was a minimum viable product aka MVP. It was running with black and white colors years ago. It was sold to a lot of people. Then televisions started to have colorful displays. People were amazed. Now television is quite thin and display resolutions are reached up to 8K. Recently LG reported that they have prepared the first roll-able television. This product is still amazing. We hold our breathes and wait for the next actions.

Requirements change a lot while building something and requirements may need a prioritized list to do. If you would wait for the perfect television in the history, you may be already kicked out from the competitive market. If you have an idea, launch it with the minimum features and you are ready to find customers.

Please also note that a roadmap for at least 3 months may give you spectacular insights. While someone manages the sprints, someone should see the bigger picture for 3 months, one another should see the bigger picture for 1 year, and finally CEO sees the future on this software.

Who?

Any organization can start to change the mindset of project management. People do the same things with a different name in Scrum. We can say that Project manager is the Scrum master. Simply; Scrum master controls the scrum team, Product owner manages the backlog, its prioritization, and releases, Product manager feeds the backlog, UI developers develop the front-end, Back-end developers develop the architectural design to expand in future, QA specialists test the UI and back-end services, and finally feature goes live. This cycle happens either every week or every two weeks. On the other side, these people try to do the same for waterfall for a longer duration. Responsibilities don’t differ a lot in both methodologies but management is quite different.

How?

Main difference between Waterfall and Scrum is the plan. Instead of planning a fully large cycle, you plan a cycle which is very small in comparison to waterfall. This small cycle is known as sprint which is started by Product owner. Product owner leads the project and prioritize product backlog items (PBIs). Each PBI should be as small as possible. So someone can do it alone and maybe in hours. If your PBI isn’t small, it converges to waterfall methodology. If to-do-list is large, what’s the difference from waterfall? Thus, PBI should be a small independent request from a customer perspective. So developers can handle it in the sprint quickly and it can be released.

Agile Scrum methodology requires fast actions not only in the scrum team, also in the organization. All members of the organizations should be able to work independently on simple tasks quickly and deliver values. If any part of the organization isn’t fast enough to answer requests or deals with bureaucratic process, it diverges from agile scrum.

A product has many stakeholders involving users, customers, governance, and organizational leadership. Product owners works with all these people to effectively ensure that development team is delivering value.

Prioritization

Prioritization of the tasks changes, always. If you have successfully launched MVP, you are ready to go now. In general, scrum teams spend their 70% of time to build new features, 15% for bug fixes, and 15% for technical debts. If ratios change, prioritization change. Let’s dig into it a little to express more.

A software is as strong as its architecture. If you are not able to scale it either horizontally or vertically, you are in trouble. If one of your app hangs, and all your software goes down, you are in trouble. If you have memory leakage in your software, your infrastructure can’t handle more and software goes down, you are in trouble. It’s time to prioritize technical debts.

A software is as strong as its bug free. Spend time to think where customers can fail during their customer journey. If you have started to receive a lot of complaints, customers aren’t able to do anything by themselves, it’s time to fix bugs and improve user experience.

A software is as strong as its competitive in the market. If you keep improving user experience, minimalist user interface, back-end services, and features with A/B testings, for sure you will stay in the market and get more share. To keep the market leadership, you have to go for minor upgrades every month, and major upgrades every year to your software.

If you don’t prioritize tasks, you are ready to fail soon. That’s why this is Agile Scrum, not waterfall. Agile Scrum gives you a chance to stop the team and direct the team on a new task, Waterfall doesn’t. If you are waterfall minded, you may see the results every two months and it might be too late in competitive market.

If your software starts losing the share and nobody knows why, fire all your scrum team, seriously! Sometimes employees who you think good should be fired to get better somewhere else.

Stay tuned for the next episodes!

Leave a Comment

Your email address will not be published. Required fields are marked *