Gastbeitrag von Arie van Bennekum: From Doing to Being Agile

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Wir freuen uns, einen Gastbeitrag von Arie van Bennekum präsentieren zu können. Arie ist einer der Autoren des agilen Manifests. Seine Firma Wemanity ist ein Kooperationspartner von oose. Unter anderem hält Arie für uns das Agile Foundation Training und tritt als Speaker in unserem Track auf der solutions.hamburg auf. Dafür haben wir übrigens noch ein paar limitierte günstige Tagestickets abzugeben.

Aber jetzt zum Gastbeitrag von Arie:

January 2nd, 1987, I started my career in IT. At the time I had a lot of fun. In hindsight a lot of pairing at the time and maximum user communication. After a while, I joined one of the leading IT-consultancy companies and I got into the rhythm of traditional work. Always a little part of the total delivery flow. In the beginning as a developer and later as a technical designer, etc. Looking back the development part was the fun part. Make something, see it work, doing what is requested, a great experience every time you delivered.

Being promoted (yes, you read it well, getting out of development was a promotion), I got into design stuff. The type of design in the middle of the delivery sequence. Client interaction zero, no purpose identified what's or ever and it crept in, the feeling of “not feeling happy”. Since you put a lot of free time in work, it should better be fun and valuable, especially for the one doing it, in this case, me...

Mid-1994 I was again on a multi-year project, delivering with 2 others 6 months of technical design. In this case more or less translating a document into another document and handing it over to someone (a programmer) who was very able to read the first document in the first place and this way degrading the added value of my work at the time to approximately zero...

I took a decision, I explained my management I did not want to do this kind of work anymore. A few weeks later I was asked to participate in a Rapid Application Development (RAD) project, I am still thankful to Willem, my manager at that time. Getting into this project, a pilot with the Dutch Royal Navy, felt awesome. The natural way of working, the interaction, the iterations, the prototyping, it all made sense. Because RAD also had a lot of things still to find out and to improve, the time of experimenting began. I remember evening after evening sitting on the coach, figuring out, or sitting in pizza-sessions to identify lessons learned. Always common sense (Agile is for me structured common sense) on top and having a focus in the interaction were (and still are) essentials.

This is where I am today. Agile is structured common sense. Complexity is failed simplicity as one of our senior coaches likes to say. Having a focus on the interaction rituals is the fundament for success, a technique can, once you have the rituals in place, make you excel. The success in Agile comes with the quality and discipline you apply when you actually do the Agile rituals. The Agile rituals like dailies, heart beats, retros, dams, etc. are all very simple to do.

Bringing this into the client organization is what I did for the first time in 1998. I noticed people often do it half, have a motivation not to show up, stick to old ways of working very often and management maintains old processes for decision making, evaluation, delivery, acceptance, etc. So how come transforming to Agile often is so difficult.

After a while, I noticed that individual and organizations tend to step back into old patterns. We can talk about change management forever, you have to identify the cause of this first and then act accordingly. I identified that paradigms (= a view or a perception) are not changed by learning Agile rituals. When you don’t change the paradigms in the organization (and therefore the people), bit by bit people and organizations downgrade to traditional ways. This is because the traditional ways embed the old paradigms. You can find them in hierarchies, decision-making processes, standards such as for documentation and bureaucracy. Transforming an organization into an Agile organization means changing the paradigms. Focus on the organization itself. We can not change individuals. Individuals can be forced to do different things but the moment the outside pressure is gone they will step back into the old routine. You can only change the people, and people are the ones who deliver when you change their habitat, their environment. And this is where I focus on with the Integrated Agile (TM) Transformation Model (IATM).

IATM has a strong focus on the environment from a very holistic point of view, so both in the vertical, the horizontal and also including all supporting entities in the organization such as HR, marketing, legal, etc. The flow of IATM is the environment first, taking people into the change process actually doing Agile. Then going into learning this with high quality and discipline as a team, followed by individual refinement so everyone can find his own ambition and fun. This way the transformation will be sustainable.

Don’t forget to be Agile as a whole is essential to make an organization future proof. Agile working makes an organization ready to work highly responsive in an ever-changing digital world, either to do a digital transformation or to maintain the capability of high responsiveness in the digital world.