Agile has been called many things – a methodology, a process. But I strongly believe it’s more of an attitude, a culture, an understanding, and a philosophy. Bottom line, agile is a mindset change.
It is not about the processes. People tend to struggle with that by immersing themselves into processes but lose sight of the bigger picture.
Being a scrum master doesn’t make the project successful. The cultural shift is what makes agile successful. Raising the bar for developers where their responsibility doesn’t begin and end with code but truly understanding and embracing the purpose of the project.
There has been a significant change in processes from the Waterfall model, which is often used in software development processes. The waterfall model is a sequential design process, derived from manufacturing processes in which progress is seen as flowing steadily downwards – from conception to design to testing to production. In the past, the waterfall model has been more popular. The software industry is no longer a place where things move cleanly from one stage to another.
The waterfall model is an old school model – with some fundamental flaws. Companies have tried to fix this by adding demos and shortening release cycles. While that might fix the symptoms of the waterfall model’s problem, it does not address the root cause which is collaboration between the team and business user. A requirements document moving between an internal team to a business user or between a vendor and a customer causes a vicious cycle that delivers only according the deliverables on the document.
How do we change the mindset?
1. Promote collaboration:
Collaboration is essential to every single component of agile. The industry is fast paced and requirements change with the markets and competition. It is imperative to communicate with the stakeholders as often as possible. The end business user of any IT product or solution should be involved through every step of the project so they can help refine ideas, discuss potential changes and make sure the users’ best interests are kept at the forefront.
2. Build iterations:
It is hard to imagine or visualize what software will look like at the end of production. The trouble with a signed off set of deliverables is that we will not question the plan, challenge the assumptions or revisit the logic.
3. Focus on outcome:
We have to make sure the process gets as much clarity as possible in getting to the final outcome of the project. Typically, a team works on a requirements document. But the success of the project is dependent on meeting the constantly evolving business outcome as opposed to the initial requirements.
How we can help our customers?
We have worked with numerous customers and this is a typical problem we see with most of them. Their teams are suffering, taking 20-24 weeks to deliver a business outcome. These inefficiencies exist based on how they are structured in a waterfall model and we see many examples of how IT teams struggle to deliver business requirements. The agile philosophy changes the way these projects are structured and takes them to successful outcomes. We are in the business of changing the business, which means we are completely focused on the outcome of the project and clear alignment to business goals.