Feb 13 2017
For all of us “mature” folk working hard to create value with technology, it is important to remember that the “A” word (agile) is nothing to be afraid of. You don’t have to unlearn everything you know, find brain space for a whole new lexicon, or grow your hair long enough to make a sterling silver topknot.
Recently, I completed a mentoring session with a young entrepreneur in my homeland of Australia. She was having difficulty translating market opportunity into product plans against the very real constraints of a small development team. Earlier in the week saw me in sales, planning, and retrospective meetings with an interesting mix of clients:
Having talked in depth, over such a short period of time, about a wide range of products, business problems, industries, tech and stage/size of companies, I reflected on the impact the agile movement (not a methodology) has had on business, technology, SDLC, and of course on me, over the course of my career.
I blew the dust off my PRINCE2 and PMBOK books, and re-read the Agile Manifesto and the 12 Principles of Agile Software Development to try and find out. I actually chuckled when I realized a couple of things about the 30-year-old me vs. the current (no need for a number here) me.
The 90s me pushed back hard against dividing lines between Product Marketing, Program Management, Development, and QA:
“I can’t wait 6 weeks to see a feature only to find out that it is not what I want!”
“What do you mean the marketing team can’t talk to the engineers?”
“The daily build is only checking to see if the code compiles — and I can’t see it!”
The current me is always pushing clients to think and go fast:
“Why do you think your current user base, of nobody, can’t live without gamification?”
“Let’s see if there is an existing solution we can use before building a custom analytics dashboard.”
“Hmmm, three more engineers building the wrong thing will get you there faster, but…”
When you sort through the pages, charts, graphs, and lists, evaluate the curricula, certifications and bad acronyms, and set aside the roles, themes, flows, and ceremonies, you are left with the simple fact that if you are not:
Then you are likely on the way to failing, are currently failing, or have already failed and haven’t told anyone. This applies to most business problems, and certainly in the case of using technology to solve them.
It really doesn’t matter if you are “agile” trained, aware or adjacent. When it comes to building software — use these as your core tenets:
That last bullet is last on purpose, too — being agile, following a framework or process should always be in service of the goals and team, not the other way around.
So to all my fellow business, product, and tech peers: fear not the age of ageism, fear not the “A” word. Instead, relish in your wisdom and experience and put it to good use.
P.S. Do read the Agile Manifesto so you never get hoodwinked.