The Agile Manifesto is for all of us–for social enterprises, non-profits, and organizational leaders everywhere who are in business to do good.
Years ago, I worked in a co-working space where lots of different people are doing lots of different things. While I am no extrovert, I love getting to know my co-workers. I always have plenty of questions to ask after that initial, “So what do you do?” Almost always.
Co-working pushed my people-skill limits because about every third person I asked the “what brings you here” question would reply, “I’m a developer.”
I would freeze.
Cool. Hmmm. Oh, like developing people, are you a teacher? You must be smart. So you like computers.
All real and awkward things I have uttered in a state of social paralysis to real live software developers.
One day, I saw the developer, looking like he wanted to strike up a chat while we were both waiting for the coffee. I quickly tried to prepare something less strange to say. In a heroic display of social skills, this person asked me the question first, “what do you do?” I gave my usual elevator pitch about organizational design and connecting strategy to action. I got a follow-up question, and another. In a few minutes I’d described the consulting I do with organizations.
And then he said it. “So that’s pretty much the same as agile,” were his exact words.
The same? He immediately got the connection between the organizational design work I do and his practice as a software developer. We had something to talk about? My heart rate slowed, my palms dried up. We sat for an hour talking about the Agile Manifesto. That was years ago, but it’s a conversation I will always be grateful for.
For years, software was developed by making detailed plans, spending lots of time and money developing those plans, then testing the final product to see if it worked.
It’s like writing up detailed plans for a raft, buying the finest quality materials, building the raft in a garage somewhere, and then taking it out for a test drive by sending it over Niagara Falls. If it works—great. If it crashes into smithereens—well that sucks.
This method of software development is aptly called Waterfall. It’s an expensive and old-fashioned way to design a product that assumes every single detail and variable can be known at the beginning and relies on one’s ability to predict the future in order to be successful. This way of working places value on process, pretty spreadsheets, and a “hope for the best” commitment to a plan.
Sound familiar to anyone out there whose eyes glaze over at the mention of strategic planning or who gets sweaty palms at the thought of kicking off a big project?
Oh friends, there is a better way—and not just for software developers.
Agile is an adaptive practice that has tech companies and startups all over the world creating innovative solutions with less money, more flexibility, and a better user experience. It’s a process that software teams use to try something and see if it works…while there is still plenty of time to make changes and the risks of those changes are relatively small. And it has nothing to do with actual coding. Well, some of it has to do with coding. Mostly it’s about a fierce commitment to learning and improving.
An agile manifesto for mission-driven leaders
1. Prioritize people over processes
People come up with the ideas. People do the work. People create change.
Agile leaders believe deep in their core that the best, most innovative ideas work when projects are built around motivated individuals instead of processes and tools. Agile teams make time to meet face to face to ask questions, reflect on their own team dynamics, and solve problems. These teams trust their people more than their processes.
If things aren’t working, agile leaders fire the process, rarely the person.
2. Collaborate with your stakeholders (rather than assuming you know what they want)
This was a game changer for the software industry. Software teams were not accustomed to listening and trusting that the customer might actually have valuable input into a development project.
Agile leaders take their cue from the social sector on this one–listening, trusting, collaborating are the anchors of real social change.
Entire organizations have been created and products developed to meet customer needs without ever asking the customer. And we’ve all been on the receiving end of those experiences. Healthcare.gov, anyone? Windows 8? Automated customer-service purgatory on the phone?
This one seems so obvious to you and me, yet we can probably all think of times when we skipped this step. How many times have you sat around a table talking with your co-workers about what a customer (or client, or participant, or stakeholder) needs, when someone lifts their head up and says, “Maybe we should ask?”
The smartest teams give a collective amen–what a great idea! The most arrogant teams bulldoze right over the suggestion with excuses–too expensive, not enough time. Or no excuses at all–we’ve worked with these people enough–we know what they need.
Assuming makes an ass out of u and me, right?
Collaborating with your stakeholders, along the way, and all the time lets you know when change is brewing and what is working.
3. Measure success by outcomes (instead of pretty plans)
In the world of agile development, there is only one metric that matters–does it work?
It’s not an unfamiliar question.
The real difference between the way agile-fanatics ask it and most of the rest of the world is this–usually we wait until the very end of whatever we are working on, and then we ask, did it work? The stakes are high at this point.
And if we are talking about something that took a big investment of money or time, there is really only one answer we want to hear–it has to work.
If we are still operating on old models of strategy and planning, it’s likely we spent a lot of time planning, writing the plan, researching the plan, executing the plan. But our all too often, plans doesn’t get airtime in the real world until the risk of failure is so scary that we lose sight of the actual good we are trying to do.
An agile developer tries something out, and immediately asks “does it work?” The question gets answered through that collaborative relationship with stakeholders.
If the answer is yes, fantastic, the team moves on to do more.
If the answer is no–hey, that’s cool too.
The team reflects, makes a plan to change, and sighs with relief that they figured out the disconnect early on.
Then they move on to try something new, always with a laser focus on the goal to create something that works for the constituent.
4. Love change (and if necessary, let go of your plan)
Loving change means responding and being prepared to pivot in order to achieve real impact. Agile leaders know that it’s possible to love planning and change at the same time.
In fact, they know that change is most often the love child of planning + the real world. Because it’s planning that helps us recognize when things are changing and what to do about it. People, needs, context all change fast. What made sense at the onset of a project might not make sense two months in.
Agile leaders know to expect these changes. And if you are in the business of making the world better, you probably expect change too.
But do you welcome it? I mean, really welcome it? Even if you’ve already got a shiny strategic plan or you are heavily invested in an idea?
Loving change is code for being ok when things don’t work as planned, aka failure to most of us. It’s one thing to talk about how we can always learn from our mistakes.
It’s an entirely different thing to mean it. But this is the heart of agile leadership.
For most of us, it’s hard to love a change in direction. It’s easier to love the vision of change we want to see in the world.
Loving change does not mean chasing every new idea or funding opportunity. But it might mean learning from your stakeholders, making meaning of your data, and scrapping a plan that is no longer relevant.
Because people change, needs evolve, opportunities shift, and the path to real impact requires a love affair with change, in all its forms.