The “fun” part of being a consultant/contractor is when you get to attempt to answer seemingly arbitrary questions in a RFP. This is especially fun when it comes to the topic of agility.
Here is one such attempt from myself:
RFP Section 5 – Methodology : Refer your experience of an agile project setup within a rather waterfall shaped organisation. Please elaborate as well how you would incorporate the scrum principles into the agile framework and show how you would ramp up the project and foresee a team collaboration model.
Right… Here we go.
This is how we do Agility! (At least if you trust Google Image Search)
The short version of how to incorporate Scrum principles, or even Agile principles, in a Waterfall driven environment is impossible to answer. Every organization is unique; thus, no approach will be exactly like the other.
However, since we are talking about principles and to some extent values, we can exemplify how we live by them and use them to guide behavior and actions.
One of the most important aspects of agility, that a waterfall approach doesn’t provide, is that of changing direction. Going back on a decision and choosing a different route with little cost and no loss in delivered value. How this is done is through the concept of validating your assumptions. Every idea that makes it as far as to become a project plan is nothing more than a set of assumptions. This is something we understand and we make it our business to validate the most critical assumptions first. I.e. are we building the right thing? This is the essence of a Minimum Viable Product. The MVP is intended to answer this question.
Another topic touched on above is that of value. Or rather business value. In certain texts you can see claims such as “Scrum will help you deliver 300% more” or similar. Now this claim is to some extent true, but it is often misinterpreted as to referring to quantity. If we start using Scrum our teams will produce 3 times as much stuff. This is not the case. The true reference is to that of business value due to its increased collaboration. In order to quantify and define this business value, the relevant people need to be involved. We will make your business our business. By understanding your organization and the unique challenges you face we partner with the departments that are crucial to a successful delivery by actively making them our stakeholders and involving them in the delivery.
On the topic of collaboration and its effect on architecture, we feel the need to mention Conway’s law. In 1967 Melvin Conway introduced the following idea:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
This is not some cute idea, the reason it is called a law is that it has proven to be true. How the teams are organized will dictate the overall architecture. This makes it ever so important to promote and foster collaboration if a scalable and future proof architecture is desired.
I always feel like I’m providing an empty rambling of non-answers to questions like this… Monday thoughts over.