"Should we adopt agile?"
"Are we doing agile well?"
Two of the most common questions I hear when working with customers, and that couldn't be more frustrating. Simply put, they are the wrong damn questions.
I don't care whether or not your process is "real" agile, and you shouldn't either.
We also don't need to debate whether agile or waterfall is better, if Scrum or Kanban is the best way to go, or how many story points can dance on the head of a pin.
Methodology wars are a waste of time and put our focus exactly where it shouldn't be -- on ourselves. Instead, we need to focus on our customers.
This means we have to do three things, and three things only:
- Ship product to actual customers,
- Pay attention to how they use it, and
- Do better next time we ship.
We need to continually get better at providing value. That's it.
By the way, if you're still debating the above three steps, and thinking they may not be correct, I have very little hope for your business. I'd rather put my money under my mattress than buy your product or invest in your company.
Some very smart people over at a (former?) Silicon Valley darling called Theranos are learning this now. It turns out a decade of operating in "stealth mode" can threaten billions in market cap.
What is Agile?
If you're not clear on what agile is, here's everything you need to know in a three-minute read:
In February of 2001, seventeen smart people got together in Snowbird, Utah. I suspect part of the reason for the timing was so they could write off a ski vacation; however, I have no evidence to back this up.
They managed to co-author a document together: the Manifesto for Agile Software Development. It is some smart stuff, you should read it.
But let's be clear: it says nothing about standup meetings or scrum masters.
What it does say is:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The authors augmented the above with 12 principles that provide tips on how to put the values into action. They are super smart as well, and you should read them too.
But don't get worked up over whether your agile is "real."
Instead, get worked up over whether individuals are having interactions that enable them to regularly deliver working software. And whether your team is in the habit of changing plans as a result of interactions with actual customers.
If your organization's structures and processes support this, you're golden. If not, you're in trouble.
You'll need to document enough to create a consistent flow of quality software and keep your contracts lightweight enough that they don't get in the way of actually doing stuff.
Two rules of thumb for documentation practices are:
- YAGNI (You Ain't Gonna Need It): Don't think too much about requirements you're not working on now, or in the next few weeks. Elaborate as you go because things are sure to change.
- TAGRI (They Ain't Gonna Read It): Don't count on writing to communicate all the details. Instead, talk to each other and schedule regular check-ins.
After the Agile Manifesto became deservedly popular, a lot of people developed processes and tools (you remember what the manifesto says about those, right?) and put them under the capital-A-Agile umbrella. Some also retroactively added existing processes and tools "Agile" whether they deserved the moniker or not.
This activity gave birth to for-profit businesses and nonprofit governing bodies. Many of these so-called "agile" organizations became profoundly dysfunctional themselves, as the war for what was "real" agile raged on.
Following one or more of these "agile" brands -- Extreme Programming, Kanban, Scrum, Pair Programming, Test Driven Development, Scaled Agile Framework, and many, many others -- may help you create better products, or they may not.
That's up to you to figure out. Instead of getting religious about an agile brand, you should experiment, pause regularly to ask where you're falling short, and make some changes, hopefully for the better.
Try new things, get engaged, and most importantly, never lose sight of your customer.
There is some really smart work in these processes and tools, but what's most important is that you experiment and create your own way of doing things and that the people you work with feel ownership of the process and empowered to change what's not working.
Don't "adopt agile" instead build your own way of doing things that allows you to ship early and often, learn from your success or failure, and do better the next time.
A myopic focus on any one brand of agile will steer your thinking away from your customer and on to yourself.
That is the beginning of the agile end.
-- This feed and its contents are the property of The Huffington Post, and use is subject to our terms. It may be used for personal consumption, but may not be distributed on a website.
