“Be the change that you wish to see in the world.”
- Mahatma Gandhi
Are you confused yet?
Are you struggling to guess what the connection between being Agile and a quote by Mahatmi Gandhi could possibly be?
Let me explain.
Bear with me as I go through a brief background of how Agile became an evolving part of my life and a framework which I hope will become a defining characteristic of my career.
(And for those of you who have no interest in any of this, my apologies in advance. Truth is, this stuff excites me – nerd alert! – so be prepared for more to come!)
The word Agile is so heavily loaded with preconceptions of what it is or isn’t that I find it necessary to clarify what it means to me, and how I relate to it as a concept.
These days, Agile is used in many instances as a branded, highly marketed way of communicating that you (and/or your organization) follows one of the many Agile methodologies/processes for executing projects.
It’s typically used in the context of software development projects, although as a concept it is really a set of values (guided by a number of principles) that, when translated into a way of being, determine how an organization gets things done.
A number of different methodologies (most famously Scrum, eXtreme Programming, and Lean, although there are so many others) advocate certain practices that result in agility, but being agile is so much more than simply following the guidelines of one or the other of these methodologies.
(More detail regarding Agile’s set of values and principles can be found at agilemanifesto.org.)
People will argue about the pros and cons of any one particular Agile methodology, but what matters most is realizing that it doesn’t have to be the same for everyone.
To me, the most important result that comes out of adopting agility as a concept is learning the best ways to achieve effectiveness, adaptability, and how to respond to change.
If you read that again you’ll notice that I said Effectiveness.
This is a big shift in mindset for those of us that have had to deal with processes whose main objective has been to ensure that we achieve a predefined result (one that usually ends up not being what the customer needs or wants by the end of the project), by some predefined deadline, in the most efficient way possible.
Learning how to get results in the best way possible (effectiveness) has, over time, trumped my natural tendencies to want to blaze forward and just get things done as fast as possible and with as little overhead as possible (efficiency).
Now, I believe that if I’m going to get things done, they better be done right.
For years I thought that one of the most important (and marketable) skills I had to advertise to any employer was my perceived ability to multi-task.
Like, seriously, multi-task. I thought I was so clever to be able to follow 6 instant messaging discussions at the same time as taking notes on a conference call that I was leading/facilitating, while maybe shopping for shoes online in the background.
(Ok, maybe that’s a bit of an exaggeration. I obviously would NEVER shop for shoes while on the job, and it may have been more like 9 instant messaging discussions but who’s counting.)
The problem: Which one of those things was I doing really well, to the best of my ability, resulting in a better end-result for myself as well as those I was working with?
Honest answer: None.
(Ok maybe the shoe-shopping one because seriously I could do that well even in my sleep. Just sayin’.)
If you haven’t heard about or read the latest studies that indicate that actually, we’re not so good at multitasking, then let me be the first to tell you:
Actually, we’re not so good at multitasking.
I am certain that I could have gotten more high-quality work done by focusing on one task, even one project, at a time instead of agreeing to take on as many projects as my bosses would throw my way in an attempt to appear to be a high-output project management machine.
I know better now.
Multitasking just meant I was switching between too many things way too quickly, and not giving any one of those things enough focus and attention to really be executed properly. The overhead of having to context switch (a fancy way of saying switching between tasks, but taking into account the need to save into memory the information/thoughts/state of being of the current task and preparing yourself mentally to enter a new task) was not worth the gains in getting more than one thing done at once.
Realizing this led me to investigate the idea of focusing on one thing at a time, which led to reading more about mindfulness, and subsequently setting the intention to be more mindful in every aspect of my life, including but not limited to the way I work.
So I started working on myself and changing the way I approached and did things, until I had a major realization.
I could set my intentions on being effective, focusing on one thing at a time, and managing projects in an agile way until I was blue in the face, but it didn’t matter one bit the second I went back to working on 3 projects at the same time, while also cranking out side pet projects for the bosses in my ‘spare time’, and adopting the expected status reporting/push-people-to-get-things-done type relationship with the software development teams in the organization.
Agility, focus, and effectiveness just flew out the window, and I have just failed at living and promoting these values and finding better ways of doing what we’re doing.
Unless I actually live by my beliefs and do something about it.
Enter Mahatma Gandhi’s quote.
I had to come to the belief that actually, I am not powerless in the face of corporate culture. I can make a difference by standing for what I believe in and by demonstrating how to live by those values, thereby teaching others how to do so as well.
The best way to create change is to live that change.
By doing so, you give people permission to be different, to go against the grain, and to have the courage to be authentic.
So nowadays, I say ‘No’ more.
I am more willing to turn down (or at least resist) requests (of myself as well as the teams with which I work) to do 30 things at once by explaining the tradeoffs in the quality of the outputs and the resulting risks.
I am more committed to convincing an end user tester that yes, they DO want to test multiple times in the lifecycle of the development of their product and its features, in order to ensure that they get what they truly want in the end-product, and to give them a chance to evolve their own ideas of what it is they really want and need.
I am more willing to state my discomfort with a pre-determined deadline of non-negotiable feature sets, and promote the empowerment of teams to determine what can be delivered when.
In related news, in a couple of days I am going to attend a Certified Scrum Master training course offered by CollabNet. I met the instructor at an event held by our local PMI chapter last year, and found him to be an inspiration in his personal commitment to the message of Agile.
I am so excited to brush up on my Scrum knowledge and skills, and hopefully continue on the path towards being an agent of change for organizations and teams that have the desire to develop and evolve their practices.