What is agility? When starting to think about writing this article, someone suggested that I provide a guide to which agile framework to use in different contexts. The more I thought about it however, the more realized that this would be an artificial guide, with few practical uses. Instead, I want to tell my story of discovering agility, from earlier experiments with eXtreme Programming, to learning about Scrum and Kanban, through to re-discovering my sense of purpose with agile.
Flirting with eXtreme Programming
My career started back in 2001 when I discovered Smalltalk, while working on an army research project. Smalltalk is an object-oriented programming environment that allowed us to develop elegantly using something very close to natural language. It was a time of discovery, passion for learning, methodologies and design patterns. Together with other researchers, we would read every single piece written by the pacesetters of the Smalltalk universe, like Kent Beck. That is how our love for Smalltalk led us to eXtreme Programming (XP).
Before starting with a new feature, we would get together to plan it and create a preliminary design using something similar to what XP describes as “class, responsibilities, and collaboration” cards, or more simply CRC cards. That gave those of us who were part of the team an idea of where we were going. Then, we would sit down and pair program. I remember that working in pairs resulted in greater speed and fewer errors: one person would see the whole forest while the other focused on the tree. And then we took turns.
We even paired up with people who did not program in Smalltalk but were acquainted with the topic of our project. That was extremely powerful. At one point, we discovered that it would be good to create a script describing how our system should behave once we implemented a feature, and then we would program until that script worked: it was a sort of emerging and very basic test-driven development (TDD). Our system was also very complex: a simulator that had to take information in and then process it and show it on a map taking into account a number of variables. Spike solutions had become the norm. What I loved about XP was that you had to make estimates in terms of ideal programming days. I found it a sensible approach, but I still wasn’t quite aware of why that was so relevant. I didn’t understand deadlines and the impact that those estimates had on our work.
If you had taken a look at the XP map, you would probably have realized that we actually didn’t apply XP that much. We applied some of its practices, which were incredibly useful, but now, looking back, I realize that there were some elements to the values and the essence of XP that we hadn’t been able to fully grasp.
Scrum looks nice on your resume
Scrum came into my career path in flashes: the power of daily meetings to synchronize our work with our remote team; the software that was growing in an iterative and incremental manner through a backlog of features and bugs; my role as a kind of facilitator while I also sorted out the backlog I was talking to clients about. I remember that back then a colleague recommended I add my role as a scrum master to my resume. They said it would “look nice” and that in any case “that was what I was doing even if people didn’t call me by that name.” We didn’t quite know what we were talking about.
My last big encounter with Scrum during this series of jobs was my participation as a functional analyst in a project for a software company that was building products for the US market. I ended up being a proxy for the product owner. I was invited to planning meetings and was asked questions whenever there were doubts. Everything else for me was nothing but a black box because there was no Scrum version of my role. I would tell myself that maybe my role didn’t exist in Scrum, but my skills definitely did, especially considering everything I contributed to the construction of the backlog and the development of the features. I was learning how multifunctional teams work without being aware of it.
Organic Agility: Love at first sight
In mid-2013, I was hired to coordinate the development area of a small software company. They hired me because that specific area was chaotic, and I was “good at sorting things out”. When I arrived, they were carrying out daily meetings, but the phone governed everything that happened there. Or ungoverned, actually. There was no focus.
After about a year of working to make sense of the chaos with the tools I had acquired until then, I understood that my education and experience as an engineer was not enough. This led me to the 2014 Argentine “Agility (Un)Conference”. There I heard Alan Cyment talk about organic agility and suddenly everything I had learned about agility began to fall into place in my mind like pieces of a puzzle: everything made sense if we placed a retrospective in the center, as a space for reflection that opens doors to improvement. Retrospective meetings help identify pains, find practices to deal with them, experiment, and iterate. No need to say I came back to the office and called a retrospective meeting immediately. That was a turning point in my life.
Photo credit: Ernesto Cárdenas
Once the blindfold comes off, there is no turning back. What do I mean by that? You begin to understand that there are things you don’t know. You realize that creating a board to manage your work does not make you even slightly a Kanban expert. Applying some technical practices does not necessarily mean you are using XP. Having Scrum roles and events is not by itself an indicator that you are developing a product or service in an agile manner.
Why did I choose to tell you a part of my agile story? Because I believe it shows that learning is a very personal journey. And agility is a path that has no finish line. You can always be a bit more agile than you were yesterday.
I am also sharing my story to let you know that I too have doubts and lose my sense of purpose sometimes. And when that happens, I always return to this compass I found a couple of years ago: the heart of agile. Agile values are what matter, regardless of practices and techniques. Sometimes techniques, roles and definitions end up complicating things and make us lose our way. Collaborate. Deliver. Reflect. Improve. Repeat.
A promise is a promise
As I mentioned at the beginning, the original idea for this article was to write about which framework we should use in each context. I guess you’ve already realized I am not much for following recipes. However, you have to start somewhere. You need to find the first breadcrumb in the trail towards agility. And, in the beginning, you have to strictly follow that trail (regardless of whether it is with the help of a more experienced facilitator) in order to be certain that, if things don’t work out, it is not because you employed the method poorly. It’s a bit like not blaming my dietician for not helping me lose weight if I didn’t follow their advice.
In this story, the first breadcrumb was XP. Here are some useful “breadcrumbs” for you:
- If you are working in a team and there are some issues you are not discussing, do it in a retrospective meeting. There are thousands of techniques and each of them requires different skills. For it to be easier to follow this breadcrumb in the trail, here’s a simple starting technique I really like: the W3 liberating structure.
- If you are just starting out with a team and you are going to develop a product or service from scratch, I recommend you apply Scrum.
- If you are developing software, adopting XP techniques will most likely help you enhance quality, time to market, and collaboration.
- If there are bottlenecks, the status of the project is unclear and there is no time-to-market visibility, embracing Kanban may work as the starting breadcrumb.
But, again, I cannot stress enough the fact that there are no recipes and that once you start following the trail of breadcrumbs, one thing leads to the other. You will end up combining Scrum with XP, Kanban, and other stuff until your blend no longer has a name: it’s simply agility.
I hope you write your own agile story and dare to share it with the world! I look forward to reading your stories!
