【A Brief History of Agile】Arie van Bennekum - Agile is Human Nature (Part 1)
Original

Jing
2022-02-23 09:40:53
1300
Summary : Faced with agility, Arie van Bennekum concluded that agility is human nature, something innate. Learning agile will never work just by learning rigid frameworks, practices, processes, or techniques for those who want to learn agile. Likewise, only organizations that embrace an agile mindset and culture will become more agile and innovative. And Arie is also promoting agile transformation.
ZenTao: 15 years of dedication to building open source project management software
Download Now


Faced with agility, Arie van Bennekum concluded that agility is human nature, something innate.


But that doesn't mean that people can only acquire agile through talent. Learning agile will never work just by learning rigid frameworks, practices, processes, or techniques for those who want to learn agile. Likewise, only organizations that embrace an agile mindset and culture will become more agile and innovative. And Arie is also promoting agile transformation. 

Working Traditionally

In 1983, Arie completed his Bachelor of Hygiene as a midwife. After receiving the diploma, he made his career plan: to pursue a career in women's health care. Even in what was then a female-dominated industry, where he didn't have the advantage as a man, he was sure he could do well. He did very well.


Two years later, Arie began his military service. During his conscription, Arie's instructors cautioned him that he wouldn't be successful if he didn't follow the rules. But before the end of his service, the unfavorable instructor appointed him as a platoon leader and won the respect of the team and commanders. This experience taught him that following established old-fashioned systems is not a requirement for success in any field of work.

Platoon Commander Military(Source: ArievanBennekum

In 1987, Arie began a new chapter in his career when working in IT as a COBOL developer. Arie spent most of his time in pair programming at this company, making short-cycle, time-bound deliveries. After resigning from this company, Arie joined an IT consulting firm with a traditional work rhythm, worked on a project for a primary government agency, and began the journey of the traditional development model.


As a result of his excellent work, he was soon promoted from developer to technical design, which was the most outstanding recognition of his ability. But as he entered the design field, Arie gradually realized that he was getting farther and farther away from his clients, "This can't make me happy." This sentiment haunted him until mid-1994 when the fuse appeared. At the time, Arie was working on a multi-year project that would be delivered alongside two other six-month technical designs. During the design process, he found himself doing one thing repeatedly: translating one document into another and giving it to a programmer who can read the first one. This rigid approach brought him a great sense of frustration. "This approach removes almost all the added value of my work and is a waste of time and money." He realized that the traditional way of working was hindering the optimization of the team's management.


Arie van Bennekum on 20 Years of Agile Manifesto (Source: ArievanBennekum)

After this incident, Arie took the risk of being fired and decided: he went to explain to management that he didn't want to do this kind of work anymore. "But what kind of work do you want to do?" He has been thinking about it. It wasn't until a few weeks later that the answer came. Arie was invited to work on a Rapid Application Development (RAD) project. The agile elements of interaction, iteration, and prototyping of this project opened up a whole new world to him. Unfortunately, this new world was not perfect: RAD enables developers to quickly demonstrate possible solutions to users and customers by simply building prototypes. But this approach is often unstructured, which leads to RAD teams being isolated and fragmented. Arie was well aware that the RAD approach still needs a lot of growing up.

Getting to know DSDM for the first time

To improve the RAD method, in 1994, the DSDM (Dynamic Systems Development Methodology) was established with the goal of "co-developing and promoting an independent RAD framework."

At this time, Arie was still looking for a complete method. Three years later, he joined a small company with self-organizing teams, highly empowered members, and a culture of innovation environment. It was also during this time that Arie came into contact with DSDM.


DSDM is a software development method based on user feedback and prioritizing rapid prototyping and iteration. Arie believes that DSDM can deliver customers what they need to work for the end-user. Therefore, since 1997, Arie van Bennekum has been regularly involved in various DSDM projects as a coach and actively participates in the DSDM League. Currently, he is a board member of the Benelux (Netherlands) DSDM and holds several DSDM certifications.


Arie has learned a lot from DSDM, and for him, the methodologies in the development process are based on different paradigms. Successful implementation is derived from the various standard conventions within those methodologies. If everyone on a team is used to working in different ways, the first step for the team is to make sure that everyone is working in the same way. But how to revolutionize the way of teams work is another big question.


In 1998, when Arie first introduced RAD to a client's team, he discovered a similar problem. Whether or not the team decides to change the way they worked, and no matter how they did it, there will always be resistance from an unknown source: management is still stuck with the old way of working, including the processes of decision-making, evaluation, delivery, and acceptance. But as it turned out, he introduced RAD into the team, and after implementing it within the team for a while, the overall work effect was still poor. The individuals and the teams preferred to fall back to the old ways of working.


In Arie's view, everyone's view or perception does not change immediately by learning various practices of Agile. Without changing the team's environment and the individual's perception, changing working in a high-pressure will bring an intense backlash. Once the external pressure is gone, they will return to their old ways of working. Therefore, the team's transformation means that the first thing to do is to start with a change of perspective and perspective.

Write a Comment
Comment will be posted after it is reviewed.