.png)
Every team and organization dealing with technology and software development needs a methodology. Sometimes they are well defined and grow organically. They can all improve on their methodologies. Let’s piece together the agile methodology story.
The Origins of Agile
In 2001, the Agile Manifesto came with its 12 principles. The Agile methodology grew out of two main shortcomings of the dominant methodology before it (waterfall). In a waterfall method, you were not sure whether some project had succeeded or failed until a lot of time, effort, and money was already spent. Even then, it was not clear what needed to be done to make the project succeed. Agile will solve this problem in two ways. Firstly, agile tries to bring together the key stakeholders in a given project so that the right people who can make the change happen are present together. Secondly, it tightens the feedback loop by ensuring key assumptions and approaches are quickly put to the test and validated so that any loss of time, effort, and money is small.
The Agile Manifesto. Source: https://visual.ly/community/infographic/business/agile-marketing-manifesto
Various buzzwords, tools, and training grew around the methodology to achieve these goals. In the words of Mike Hadlow, it became more like a cult and a stick to beat developers with, not empower them.
What Went Wrong With Agile
In some way, Since the original agile manifesto, agile has come to imply ‘management agile. It’s been taken over by management consultants and reduced to a small set of non-technical practices that came out of the richer, larger, but often a profoundly technical set of agile methods.
Agile, stripped of software engineering methods and orchestrated by ‘agile practitioners’ with no comprehension of software engineering, becomes a set of useless rituals that are distractions and impediments to developing successful software.
Bringing Back Agile
The million dollar question then is how do you “become” Agile, as opposed to “doing” Agile. There are no simple direct answers.
The reality is that every organization has to find its path to become agile. Some things help along the way through. It helps to have a partnership between the technology and the business stakeholders for a system to be agile. A technology team that can understand and appreciate the complexity of the business alongside technology is crucial for such a partnership to work.
Another crucial ingredient is to have a team with a mix of skills and experience. A combination of technical and functional skills, knowledge of existing systems and processes, and what the rest of the industry has to offer. Finally, the attitude toward ownership.
Lastly, the difference between agile and the methods before it was the feedback loop. Being agile requires that blockers and changes are identified quickly and addressed to the satisfaction of everyone in the team. Clear and honest communication between all stakeholders frequently is necessary.
Final Word
At Wissen, our preferred way of working is in an agile team model. We put together the right mix of technical and functional skills who communicate and identify and fix blockers and issues in a rapidly iterative fashion alongside changing business needs. If you want to know more, you can reach us at contactus@wissen.com .
