The transition from waterfall to agile software development is often compared to the architectural aspects of constructing a building. Naturally changes to the existing edifice are only made after careful consideration of earth shaking decisions – like tearing down walls, adding new pipes, etc. Emphasis is put on: basically possible! Deciding to do it, however, is only done after the walls are up or have at least been started.
My father is an architect and I know from him that architects often must spend hours looking at blueprints with clients every time any type of change is made. Frequently you hear “I can not really imagine that, I need to see it first and walk through it.” Maybe that it why prefab houses continue to become more and more popular. I have never experienced that a client having a prefab house built really only sees it after the bathroom tiles have been installed or it is ready for occupancy. And even less everyone involved with the construction is freed from making changes while building even if there was detailed, collaborative planning before construction. Regardless of unforeseen problems that arise, customers changing their minds or new ideas being introduced by the architects.
The client is allowed to get on your nerves
What I really like about Scrum is that it does not have to deliver a ready for use product. Clients can admire the construction process with Scrum, celebrate raising the roof AND change their minds 10 times about which carpet to install. Although they do these things the architects will not lose their jobs or stop planning, just like the developers, software architects, testers or Product Owners will also not lose their jobs. On the contrary they will react positively to all these new demands for change. Sometimes they even become a little agitated that the clients did not think of this sooner. But they are the ones who have to live there not the architects. This is different with prefab houses. The client having a house built is usually the one who is agitated not the architects because in the end he is the one who has to pay twice for small changes. Whereas in software development we rarely have the opportunity to build something twice.
But still, what do we do if we can’t or do not want to implement prefab software? What if the user recognizes exactly what the value of individual changes and codecisions to software is? Let’s use the Willy Brandt Airport in Berlin as an example. Here the reliability and performance of the architecture, services and user interface are checked out before they are actually implemented by ever increasing sizes of groups. Tests started so soon that even major changes were still possible according to user-feedback. Test passengers are equipped with everything passengers need and act like a normal passenger. This includes complaints, stress, carrying forbidden items, pushing and being lost. Complaints are welcome!
I nervously wait for my first flight from the new airport in Berlin and surely I will have a few ideas about what could be improved: If only they would have asked me! And although I know that it is nerve-wracking, I will never choose a prefab house.
Kristina Klessmann, Scrum Consultant