Agile Transformation
Dutch translation for the Agile Manifesto 
Geert Bossuyt 20 Apr, 2010
Share 
In some (if not most) of the transitions to an agile way of building software, the awareness of the manifesto happens after having started on the journey. The trigger to adopt agile probably varies in any given situation.
While some take a structured approach to adopt one of the agile software development frameworks, there are many who are looking to find a solution for a specific situation bothering them for a (maybe relatively) long time already.
In cases where the start is a specific situation either “taming the backlog of work” or “incremental software development” or any similar situations, the idea about existence of the manifesto and/or the values it promotes is more a matter of discovery than probably a master plan.
Aah, there you go.
In the field of Software development there is always some parameter which limits you from re-using an existing piece of software and being able to make a predictable plan of the re-use scenario.
Barring few instances, most cases involve researching, adapting to a certain degree and dealing with certain unknowns. Making a comprehensive plan in such situation(s) asks for (some) room to maneuver.
To relate, let me know share two cases to illustrate the point.
Case 1: A software development organization having experienced success with a set of components that worked in tandem wanted to weave them into an integrated system. The idea was to deliver enhanced business value in a seamless manner. This grand ambition off-course lead to meticulous planning and drained all the available capacity to execute and deliver on this multi-year plan. Apart from the delays and impact due to the re-work of the design and re-planning, as more and more resources got absorbed into the plan, work started piling-up, concerning the support of in-production versions of the components and a huge technical debt. Without an end in sight, something needed to change to get things back in control.
Case 2: A software development organization set off to build a completely new product as a stand-in replacement for the existing product. The idea was to use the latest and emerging technologies of the day to stay current with the times. This new product was en-visioned to be a very flexible, and a highly configurable product. In dealing with a product of such complexity, years went by, the team size grew from a select few engineers to almost everyone (barring few entrusted to maintain the existing product). At the end of this period, there was nothing tangible to show to the customer. A different approach was needed to get the development to move further on building value for the customers apart from making a robust software.
As evident in both the above cases, these ambitious endeavors shared space with the other regular bits of work related to maintaining the existing product(s) and component(s). Building these new software in silos and attempting to build them in a start-to-finish manner was apparently not working in the expected way and probably caused frustration across the organization.
These situations lead to looking for a different approach that can help piece the half-baked portions together in a time bound manner. This was off-course “Responding to change over following a plan” in action.
The choice was to adopt Scrum.
As a first step, instead of “start-to-finish” approach, step-by-step approach was adopted to incrementally get the half-baked portions to shape up into a working software that delivers value to the customer.
Rather than focusing on detailing all the steps into a plan or finalizing the complete software architecture, it was a brush with working software over detailing.
The new approach did not promise a quick turnaround for all the problems. It helped prioritize the issues and deal with them in an iterative manner. To ensure we stay on course, it was decided to work with the potential users of the software.
This lead to earlier feedback and to keep the software fit for business use rather than having to defend the quality of the software using the contractual clauses.
Customer Collaboration over Contract Negotiation kicked off and “Responding to change over following a plan” was happening.
A start-to-finish plan and a completely detailed architecture enforced rigidity into the approach.
All the internal learning while building the software could not get the required attention due to the rigidity in the plan and not enough scope to re-work and improve.
With the move to Scrum, there was more room to process the internal feedback as much as the external inputs. This helped create an environment of collaboration within the teams. Building the software right took as much precedence as building the right software. There was increased involvement from all the stakeholders as the software started to shape-up.
Eventually, Individuals & Interaction over Process & Tools became the order.
This was a process of discovery of better ways of developing software. This was a multi-year period of learning the nuances of Scrum and improving upon the way software could be built better.
The tenets of the manifesto, kind of naturally comes as you start to thing outside of the fixed paths to solve some of the issues.
The paradigm from Manifesto as a goal to Manifesto as a result becomes interesting as it actually matches the whole notion of Agile and the Manifesto itself i.e. change over plan and learn as you go along.
Accepting the change is more important than just sticking to a plan. The world of tomorrow will be different from the world today and hence the plan most likely less relevant. Plan sets a direction and is not set in stone. It needs to be adopted as the execution proceeds further.
When the complexity levels are high, tackling change becomes difficult as all the consequences may not be seen through. Responding to change in such situations might even blur the sense of direction. As you make further steps in this journey, you will come to realize the benefits of working software over detailing. DO over THINK, SHOW over WRITE.
While there was a promise of certain value in the existing practices, there was more value in the tenets of the manifesto and the principles behind it.
References:
1.)http://agilemanifesto.org
2.)http://agilemanifesto.org/principles.html
Error: Contact form not found.
Software engineer at coMakeIT