The Agile Architect
Agile Through the Eyes of a Scientist
Agile is not a hard science like physics or chemistry. There is no fundamental theorem of agility. But practices in agile act along empirical scientific principles in that experimentation can lead to measurable results, reproducible across teams in similar conditions. So why does each agile team feel compelled to rediscover this again and again?
Here's the origin of this article: I've been working with several new teams recently, helping them go through the usual agile startup process of figuring out how they are going to work together as a team.
And I was frustrated. Not because their activities weren't important, but because the teams all felt compelled to start from scratch. When experienced members of the team would suggest more sophisticated techniques, the team collectively would dismiss the suggestion, wanting to feel the pain and discover the need before adopting a more complex process or tool. They believed their situation to be unique, with little or no existing foundation to start from. And, therefore, they saw little or no value in experience and past results.
I find this phenomenon personally strange. With my background in science, I experienced first-hand both in graduate school and working as a research scientist a constant need and personal desire to stay at the forefront of knowledge in my chosen discipline.
How Is Agile Similar to Science?
Scientists must constantly stay at the leading edge of their discipline. While it is true that science requires experiments to be independently reproduced in order to verify their results, once a scientific principle is established, most scientists will accept it unless they have an interesting approach to disproving it or new evidence contradicts it. If all scientists felt compelled to start all research from first principles, there would be very little time to discover anything new. Perhaps even more importantly, no new evidence could be found that might contradict existing theory.
Graduate students learn that they must quickly and thoroughly learn the fundamentals of their science, followed by the large body of current research. Only in this way can they get to the leading edge of science and start contributing new knowledge.
Agile is similar to science in that you have to know the body of work and know what's been done. It's good to question what has been, but it's not good simply to go through the same pains of discovery that others have gone through before. So when there's a new agile team, what's the right balance between educating them on what's known versus letting them discover it for themselves? If you get this balance wrong, they can waste a lot of time discovering well-known things.
How Is Agile Different from Science?
Agile is different from science in that it is both a technical experience and a social experiment. There is no fundamental truth. The "truth" changes based on the people involved, the project, and problem they are solving, among many factors.
In fact, the shared experience of the team solving even already-understood problems can help bond the team into a better-performing, more agile unit.
Furthermore, people working on agile projects usually see their primary focus as getting their project done. Learning more about agile, improving their agility and sharing their agile experiences, while important, are all secondary concerns. Agility is a means to an end. This is exactly the opposite for scientists, where knowledge is the end goal. Research, writing scientific papers and submitting for grants are a means to that end.
Finding the Balance
Obviously every team is different. But here is some general guidance:
Dedicate time to learning
- As an individual, dedicate a fraction of your time to learning new agile techniques
- As a team, dedicate time to sharing what you've learned.
- As a company, have agile coaches or others who are dedicated full or part time to education and the proliferation thereof, not just in agile basics but also in current state-of-the-art and bleeding edge.
Follow a scientific process for experimentation
- Choose a problem you want to solve.
- Using what you learned above start from a known best practice where possible. Listen to the experienced voices on your team. Sure, you can invent your own, but not yet.
- Measure a baseline.
- Conduct experiments deviating from these best practices and measure the impact.
- Accept or reject the change based on your quantitative and qualitative results.
- Repeat
Final Thoughts
In the scientific community, there is a culture of learning, debate, and constant questioning of the status quo with little tolerance for time spent on the mundane. This culture constantly reinforces our shared desire to spend our time pushing forward the boundaries of scientific knowledge, ensuring that we are all kept abreast of this progress as much as possible in order to be successful with our own research.
Perhaps the most important ingredient for success in a corporate environment, where agility takes a back seat to profit and product, is to hold each other accountable for staying on top of your agile game. The more learning activities available, the more discussion and debate around agility and improvement, the more that our teams will naturally think and act around increasing their own agility and agile knowledge. Fostered by this environment and armed with this knowledge, new teams and old can stand on the shoulders of their predecessors reaching ever higher achievements in agility.