Implementing an effective software development process: Agile, Scrum, CMMI and where to startHet implementeren van een effectief softwareontwikkelingsproces: Agile, Scrum, CMMI en waar te beginnenImplementing an effective software development process: Agile, Scrum, CMMI and where to start Implementierung eines effektiven Softwareprozesses: Agile, Scrum, CMMI und wo man anfängt
Even after several decades of software development, we still frequently read about high failure rates in IT projects. The last few years, the industry experts are getting on stage to propagate Agile and Scrum as the Holy Grail in software development. The question is where to start when changing your software development process.
The first problem when reading through the literature about agile and scrum: it seems overwhelming. Reading about CMMI sends you even further into the bush. The large IT providers easily assign some people to study, master and implement such complex processes. But the biggest part of the software industry consists of small and medium sized firms. In Europe, the biggest part of the software firms have somewhere between 10 and 50 employees. If you work at such firm, you probably want to get going, produce and get your projects ready. The thing on your mind is to get that new product release out on the market, to speed up your project to make a deadline. You don’t have the time to learn a new process, think everything through, document it and implement the change.
Zelfs na enkele decennia van softwareontwikkeling horen we nog vaak dat er veel fout gaat bij IT projecten. De laatste jaren propageren de experts van de industrie dat Agile and Scrum de ‘heilige graal’ zijn in softwareontwikkeling. De vraag is waar te beginnen met het veranderen van uw softwareontwikkelingsprocessen.
Even after several decades of software development, we still frequently read about high failure rates in IT projects. The last few years, the industry experts are getting on stage to propagate Agile and Scrum as the Holy Grail in software development. The question is where to start when changing your software development process.
The first problem when reading through the literature about agile and scrum: it seems overwhelming. Reading about CMMI sends you even further into the bush. The large IT providers easily assign some people to study, master and implement such complex processes. But the biggest part of the software industry consists of small and medium sized firms. In Europe, the biggest part of the software firms have somewhere between 10 and 50 employees. If you work at such firm, you probably want to get going, produce and get your projects ready. The thing on your mind is to get that new product release out on the market, to speed up your project to make a deadline. You don’t have the time to learn a new process, think everything through, document it and implement the change.
Selbst nach mehreren Jahrzehnten der Softwareentwicklung, lesen wir immer wieder von hohen Fehlerquoten bei IT Projekten. In den letzten Jahren preisen die Industrieexperten Agile und Scrum als den heiligen Gral der Softwareentwicklung an. Die Frage ist, wo man anfangen soll, wenn man seinen Softwareentwicklungsprozess verändern will.
Das erste Problem taucht auf, wenn man die Literatur über Agile und Scrum liest: sie scheint einen zu überwältigen. Etwas über CMMI zu lesen, bringt einen noch weiter ins Straucheln. Die großen IT Anbieter ordnen einfach einige Leute dazu ab, solch komplexe Prozesse zu studieren, zu bewältigen und zu implementieren. Der größte Teil der Softwareindustrie besteht jedoch aus kleinen und mittelgroßen Firmen. In Europa hat der größte Teil der Softwarefirmen zwischen 10 und 50 Angestellten. Wenn man in einer solchen Firma arbeitet, will man wahrscheinlich einfach nur in die Gänge kommen, produzieren und das Projekte fertigstellen. Was dabei zählt ist, das neue Produkt auf den Markt zu bringen, das Projekt zu beschleunigen, um die Frist einzuhalten. Man hat nicht die Zeit, einen neuen Prozess zu erlernen, alles zu überdenken, es zu dokumentieren und die Veränderung zu implementieren.
The common way of organizing software projects in most software firms is (or was) the waterfall method. Most firms don’t choose this process deliberately, but grow into it, because it’s a natural human way to get organized. It has its parallel to the construction world: you have an idea of your dream house; you hire an architect who captures all your ideas and puts it into a drawing; the drawing gives a very clear picture of the house and matches with the picture in your mind; you accept the drawing; the drawing goes to the construction firm who tells you what it’ll cost to build the house; and so the project starts. In most cases, the construction firm gets it right: the house is like the picture. What they frequently don’t get right is the timing, but as we’ve grown accustomed to that, we accept the delay and we’re happy to move into the new house.
I think there are 2 crucial differences between construction and software development, which agile and scrum address:
- It is very hard (maybe even impossible) to clearly picture the software application before it exists
- It is much harder to organize, because the thought process and the execution don’t follow linear patterns
Whatever process you want to implement, however you call it, there are two things that can improve a software development process drastically (those two are also central parts of scrum and agile):
- 1. Create the picture in steps instead of upfront.
For smaller projects, this might be over-organization, because the picture can be made clear upfront. For bigger projects, it brings substantial improvement. Define the high level requirements of the project (create a rough picture), then cut out a part that can be completed within two weeks. Divide that part into clearly defined tasks and start building. Anything that has been built in those two weeks has to be tested and reviewed thoroughly and based on the results, the part and tasks for the next two weeks are defined. This gives a more flexible approach to building the picture and gives an opportunity to ‘steer’ the project in the right direction.
- 2. Organize communication
In the waterfall method (and the natural human organization method), the requirements are supposed to be clear, so we let the programmers do their work and expect to see the result when the deadline is due. Whatever happens in between, we expect them to fix. The problem in this organization is communication or the lack of it. Scrum and Agile have daily meetings as its cornerstone. Every day at a fixed location, with fixed people on a fixed time, the team discusses three questions: 1. What have you done yesterday?; 2. What will you do today?; 3. Where are you stuck?. Especially this last question is what brings a leap in productivity. Programmers often bang with their heads against a closed door. If you don’t hear them banging, they sometimes keep doing it for a week, believing that they’ll catch up the time they lose later on, trusting that they’ll get through that door. Daily meetings ensure that everyone hears the banging and puts the brains of the team into opening the door.
From these two, the second has the biggest impact and is the simplest to implement. If you are not ready to implement a whole new process, start with organizing communication. While building a house, the supervisor walks around daily and will see it when someone can’t get the door in place. He will walk to the person and ask what’s happening and will organize help to fix the door naturally. In software development, the door is invisible, the solution to fix the door is not straightforward and programmers find pride in solving complex problems and will try anything (for days in a row) to solve it. Communicate, ask the three questions every day and your projects will start moving faster and more fluid.
Het eerste probleem bij het lezen over agile en scrum: het lijkt overweldigend. Lezen over CMMI is nog complexer. De grote IT aanbieders geven mensen de opdracht om de complexe processen te bestuderen, eigen te maken en te implementeren. Maar het grootste deel van de software industrie bestaat uit kleine en middelgrote bedrijven. In Europa hebben de meeste software bedrijven tussen de 10 en 50 werknemers. Als je bij een MKB bedrijf werkt wil je graag ‘aan de slag’, produceren en nieuwe projecten klaar krijgen. Je denkt alleen aan het op de markt brengen van een product, snel een deadline halen. Je hebt geen tijd om een nieuw proces te leren, over alles na te denken, te documenteren en de verandering te implementeren.
De meest voorkomende manier van het organiseren van softwareprojecten is (of was) de waterval methode. De meeste bedrijven kiezen hun processen niet specifiek uit, maar groeien er naar toe, omdat het de ‘menselijke manier’ is om dingen te organiseren. Er is een parallel met de bouw: als je een idee hebt voor je droomhuis, huur je een architect in die van de ideeën een tekening maakt, de tekening geeft een duidelijk beeld van het huis en dat past bij wat je in je hoofd had, de tekening wordt geaccepteerd en gaat naar het bouwbedrijf dat aangeeft hoe veel de bouw zal kosten, en het project gaat van start. In de meeste gevallen doet het bouwbedrijf het goed, het huis lijkt op de tekening. Wat vaak niet goed gaat is de timing, maar daar zijn we gewend aan geraakt en we accepteren dat omdat we blij zijn dat we in ons nieuwe huis kunnen gaan wonen.
Ik denk dat er 2 belangrijke verschillen zijn tussen de bouw en softwareontwikkeling, die agile en scrum behandelen:
1. Het is heel moeilijk (zelfs onmogelijk misschien) om een volledig duidelijk beeld te vormen van een software applicatie voordat deze bestaat.
2. Het is veel moeilijker te organiseren, omdat de denkprocessen en uitvoering geen lineaire patronen volgen.
Welk proces je ook wilt implementeren, hoe je het ook noemt, er zijn twee dingen die een softwareontwikkelingsproces drastisch kunnen verbeteren (die twee zijn ook onderdeel van scrum en agile):
1. Creëer het beeld in stappen in plaats van vooraf.
Voor kleinere projecten is dit misschien te veel organisatie, omdat het beeld van te voren grotendeels duidelijk gemaakt kan worden. Voor grotere projecten is het een hele verbetering. Definieer de eisen en randvoorwaarden voor het project (maak een ruwe schets), en kies dan een deel dat binnen twee weken klaar kan zijn. Deel dit op in duidelijk gedefinieerde taken en begin met bouwen. Alles dat binnen die twee weken gebouwd is, moet grondig getest en herzien worden en gebaseerd op de resultaten die daaruit komen, worden de taken voor de volgende twee weken gedefinieerd. Hierdoor wordt het maken van een beeld flexibeler en is het mogelijk om het project in de goede richting te ‘sturen’.
2. Organiseer communicatie.
In de waterval methode (en de menselijke organisatie methode) moeten de eisen duidelijk zijn, dus we laten de programmeurs hun werk doen en verwachten de resultaten te zien bij de deadline. Wat er in de tussentijd gebeurt, is aan de ontwikkelaars. Het probleem bij deze organisatie is communicatie, of het ontbreken daarvan. Dagelijkse meetings zijn belangrijk volgens Scrum en Agile. Elke dag op een vaste locatie, met vaste mensen op een vaste tijd, bespreekt het team drie vragen: 1. Wat heb je gisteren gedaan? 2. Wat ga je vandaag doen? 3. Waar zit je vast? Vooral de laatste vraag zorgt voor meer productiviteit. Programmeurs bonken vaak met hun hoofd tegen een gesloten deur. Als je hen niet hoort bonken, doen ze het soms een hele week, terwijl ze denken dat ze het op tijd in kunnen halen, erop vertrouwend dat ze door die deur komen. Dagelijkse meetings zorgen ervoor dat iedereen het bonken hoort en gebruik maakt van de hersenen van het team om de deur te openen.
Van deze twee heeft de tweede de meeste impact en deze verbetering is ook het gemakkelijkst te implementeren. Als u niet klaar bent om een nieuw proces te implementeren, begin dan met het organiseren van communicatie. Als er een huis gebouwd wordt, loopt de opzichter dagelijks rond en zal hij het zien als het iemand niet lukt een deur te plaatsen. Hij zal aan deze persoon vragen wat er aan de hand is en zal helpen de deur te plaatsen. Bij softwareontwikkeling is de deur onzichtbaar, de oplossing om de deur te maken is niet zo simpel. Programmeurs zijn trots als ze de oplossing voor een complex probleem vinden en zullen alles proberen (dagenlang) om de oplossing te vinden.
Communiceer, stel de drie vragen elke dag en uw projecten zullen sneller en soepeler verlopen.
The common way of organizing software projects in most software firms is (or was) the waterfall method. Most firms don’t choose this process deliberately, but grow into it, because it’s a natural human way to get organized. It has its parallel to the construction world: you have an idea of your dream house; you hire an architect who captures all your ideas and puts it into a drawing; the drawing gives a very clear picture of the house and matches with the picture in your mind; you accept the drawing; the drawing goes to the construction firm who tells you what it’ll cost to build the house; and so the project starts. In most cases, the construction firm gets it right: the house is like the picture. What they frequently don’t get right is the timing, but as we’ve grown accustomed to that, we accept the delay and we’re happy to move into the new house.
I think there are 2 crucial differences between construction and software development, which agile and scrum address:
- It is very hard (maybe even impossible) to clearly picture the software application before it exists
- It is much harder to organize, because the thought process and the execution don’t follow linear patterns
Whatever process you want to implement, however you call it, there are two things that can improve a software development process drastically (those two are also central parts of scrum and agile):
- 1. Create the picture in steps instead of upfront.
For smaller projects, this might be over-organization, because the picture can be made clear upfront. For bigger projects, it brings substantial improvement. Define the high level requirements of the project (create a rough picture), then cut out a part that can be completed within two weeks. Divide that part into clearly defined tasks and start building. Anything that has been built in those two weeks has to be tested and reviewed thoroughly and based on the results, the part and tasks for the next two weeks are defined. This gives a more flexible approach to building the picture and gives an opportunity to ‘steer’ the project in the right direction.
- 2. Organize communication
In the waterfall method (and the natural human organization method), the requirements are supposed to be clear, so we let the programmers do their work and expect to see the result when the deadline is due. Whatever happens in between, we expect them to fix. The problem in this organization is communication or the lack of it. Scrum and Agile have daily meetings as its cornerstone. Every day at a fixed location, with fixed people on a fixed time, the team discusses three questions: 1. What have you done yesterday?; 2. What will you do today?; 3. Where are you stuck?. Especially this last question is what brings a leap in productivity. Programmers often bang with their heads against a closed door. If you don’t hear them banging, they sometimes keep doing it for a week, believing that they’ll catch up the time they lose later on, trusting that they’ll get through that door. Daily meetings ensure that everyone hears the banging and puts the brains of the team into opening the door.
From these two, the second has the biggest impact and is the simplest to implement. If you are not ready to implement a whole new process, start with organizing communication. While building a house, the supervisor walks around daily and will see it when someone can’t get the door in place. He will walk to the person and ask what’s happening and will organize help to fix the door naturally. In software development, the door is invisible, the solution to fix the door is not straightforward and programmers find pride in solving complex problems and will try anything (for days in a row) to solve it. Communicate, ask the three questions every day and your projects will start moving faster and more fluid.
Die gebräuchliche Art ein Softwareprojekt zu organisieren, ist (oder war) bei den meisten Softwarefirmen die Wasserfallmethode. Dabei suchen sich viele Firmen diesen Prozess nicht wissentlich aus, sondern wachsen in ihn hinein; denn dieser ist ein natürlicher, menschlicher Vorgang, um sich zu organisieren. Man findet dabei Parallelen zu der Welt der Konstruktion: Sie haben eine Idee von Ihrem Traumhaus; Sie stellen einen Architekten an, der all Ihre Ideen in einer Zeichnung einfängt; die Zeichnung gibt Ihnen einen klaren Eindruck von dem Haus und stimmt mit dem Bild in Ihrem Kopf überein; Sie akzeptieren die Zeichnung; die Zeichnung geht zur Konstruktionsfirma, die Ihnen sagt, was es kostet das Haus zu bauen; und so beginnt das Projekt. In den meisten Fällen arbeitet die Konstruktionsfirma nach Ihrer Zufriedenheit: das Haus sieht aus, wie auf dem Bild. An was es oft hapert, ist die Zeitplanung. Wenn wir uns jedoch einmal daran gewöhnt haben, akzeptieren wir die Verzögerung und sind glücklich darüber, in das neue Haus einzuziehen.
Ich denke, es gibt 2 entscheidende Unterschiede zwischen Konstruktion und Softwareentwicklung, welche von Agile und Scrum berücksichtigt werden:
Es ist sehr schwierig (vielleicht sogar unmöglich) sich ein klares Bild der Software-Anwendung zu machen, bevor sie existiert.
Es ist viel schwieriger zu organisieren, da der Gedankenprozess und die Ausführung keinem linearen Mustern folgen.
Egal welchen Prozess Sie implementieren möchten, wie auch immer Sie ihn nennen, es gibt zwei Dinge, welche Ihren Softwareentwicklungsprozess drastisch verbessern können (dies sind auch zwei zentrale Aspekte von Scrum und Agile):
1. Erstellen Sie ein Bild schrittweise anstatt im Vorhinein.
Für kleinere Projekte ist dies vielleicht zu viel Organisationsaufwand, da man sich von Anfang an ein klares Bild machen kann. In Bezug auf größere Projekte bewirkt es eine wesentliche Verbesserung. Definieren Sie die übergeordneten Anforderungen des Projektes (erstellen Sie ein grobes Bild), dann extrahieren sie daraus einen Teil, der innerhalb von zwei Wochen fertiggestellt werden kann. Teilen Sie diesen Teil in klar definierte Aufgaben auf und beginnen Sie zu bauen. Alles, was in diesen zwei Wochen gebaut wurde, muss getestet und überprüft werden und, basierend auf den Ergebnissen werden die Aufgaben für die nächsten zwei Wochen definiert. Dies gibt Ihnen die Möglichkeit einer flexibleren Herangehensweise um das grobe Bild zu gestalten und das Projekt in die richtige Richtung zu „steuern“.
2. Organisieren Sie die Kommunikation
Bei der Wasserfallmethode (und der natürlichen, menschlichen Organisationsmethode) gehen wir davon aus, dass die Anforderungen klar sind, so dass wir die Programmierer ihre Arbeit machen lassen und erwarten, die Ergebnisse zu sehen, wenn die Frist abgelaufen ist. Was auch immer dazwischen passiert, wir erwarten, dass sie es bewältigen. Das Problem bei dieser Art der Organisation ist die Kommunikation oder besser der Mangel an Kommunikation. Scrum und Agile haben tägliche Meetings als ihren Grundstein. Jeden Tag diskutiert das Team, zu einer festen Zeit, mit immer denselben Leuten, an einem festen Ort, drei Fragen: 1. Was habt ihr gestern gemacht?, 2. Was macht ihr heute?, 3. Wo seid ihr hängengeblieben?. Besonders die letzte Frage verschafft einen großen Produktivitätsgewinn. Programmierer laufen oft mit ihren Köpfen gegen verschlossene Türen. Wenn Sie sie nicht vor die Tür laufen hören, machen Sie dies manchmal eine ganze Woche lang, in dem Glauben, dass sie die verloren gegangene Zeit später wieder gut machen können; darauf vertrauend, dass sie durch die Tür kommen werden. Tägliche Meetings stellen sicher, dass jeder das laute Klopfen hört und dafür sorgt, dass das Team durch das Öffnen der Türen vorrankommt.
Von diesen beiden, hat der zweite Aspekt den größten Einfluss und ist am einfachsten zu implementieren. Wenn Sie nicht bereit sind, einen ganz neuen Prozess zu implementieren, beginnen Sie damit die Kommunikation zu organisieren. Während das Haus gebaut wird, geht der Bauleiter jeden Tag um das Haus herum und sieht, wenn jemand die Tür nicht an den richtigen Platz bekommt. Er wird zu der Person hingehen und fragen, was los ist und wird Hilfe organisieren, um die Tür einzubauen. Bei der Softwareentwicklung ist die Tür unsichtbar, die Lösung, um die Tür einzubauen, ist nicht so einfach und Programmierer sind stolz darauf, komplexe Probleme zu lösen und werden alles (tagelang) versuchen, um das auch zu schaffen. Kommunizieren Sie, stellen Sie jeden Tag die drei Fragen und Ihr Projekt wird sich schneller und reibungsloser voran bewegen.
About Hugo Messer
Hugo Messer is a Dutch entrepreneur, distributed agile team specialist, and author. He is the founder and owner of Bridge Global, a software services provider, and ekipa.co., an agile coaching agency. He has been building and managing teams around the world for the past several years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make global cooperation work.
View all posts by Hugo Messer →
Hugo,
A simple and clear article. I like it. I agree with you. The sense of urgency the daily meeting will bring from the start is really valuable.
I do like to caution though that – if we didn’t bring the other Agile values such as self organizing teams and servant leadership, to the team, this could back fire in the sense that this could become a micro management tool. It might end up as a Project Manager is trying to figure out what the status is every morning – which is not the intend of the daily stand up meetings. Speaking of standing up – if we didn’t have a good facilitator for the meeting, the daily meeting could end up 30+ minutes meetings and that will quickly add up.
Those are some pitfalls we got to watch out for. Do that make sense?
Manoj
Pingback: If offshoring doesn’t provide the desired results, what do you focus on? | Bridge-Blog