Every team, every organisation dealing with technology and software development needs a methodology. Sometimes they are well defined, sometimes they 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 with its 12 principles came into being. The Agile methodology grew out of two main shortcomings of the dominant methodology before it (waterfall). In a waterfall method, you were not sure some project had succeeded or failed until a lot of time and effort and money was already spent and even then it was not clear what can be changed so that the project can succeed. Agile tries to 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 making sure key assumptions and approaches are quickly put to the test and validated so that any loss of time, effort and money is small.
To achieve these goals, various buzzwords and tools and of course training grew around the methodology. 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, over the decade or so since the original agile manifesto, agile has come to imply ‘management agile’. It’s been taken over by management consultants and reduced down to a small set of non-technical practices that came out from the much richer, larger, but often profoundly technical set of agile methods.
Agile, when stripped of real software engineering methods and orchestrated by ‘agile practitioners’ with no comprehension of software engineering, it simply becomes a set of useless rituals that are mostly 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 organisation has to find its own path to become agile. There are some common things that 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 as well as what the rest of the industry has to offer and finally the attitude of taking ownership.
Lastly, the key 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 on a frequent basis is necessary.
At Wissen, our preferred way of working is in an agile team model. We put together teams that are 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 email@example.com
In the initial days of software development, programmers did not have the extravagance of sophisticated version control systems. Instead, they relied on labor-intensive, expensive, and inefficient processes to keep a…
With the rise of cloud computing, it is no surprise to find organizations building processes around microservices and continuous delivery. In a cloud-based environment, the "traditional" code-first approach toward application…