I’ll be attending my second formal training this year, getting my Certified Scrum Master certification to match the Certified Product Manager certification that I picked up earlier this year. After 15 years in the business, you might wonder why I’m just now getting around to being “certified”, and I hate to say it but the real reason is simple — the company I work for is paying for it. Otherwise, I’d happily chug away for another 15 years without any form of certification, because I firmly believe that the experience that I have in transforming companies into agile engines is far more valuable in the abstract than any specific certification that I might collect along the way. But, there are a few times when and where a certification might be worth pursuing…let’s talk about those today.
“Agile” is More Than a Buzzword: Continuous Improvement
There’s more to being Agile than just blindly following the rules and processes of any specific methodology. One of the core components of effective Agile practice is internalizing the concept of continuous improvement. As I’ve touched on in other articles, Agile is a direct descendant of the concepts originating in the lean manufacturing movements of the late 1940s and early 1950s. And the single most important part of this ancestry is the focus on empowering and entrusting the people who do the work with setting their own destiny and with challenging each other to improve their practices on a regular basis.
Accepting Uncertainty is the Key to Agility
I’m often asked what the key to being “agile” really is, and over the years I’ve managed to come up with a clear and concise answer: accepting uncertainty is the key to agility. It is perhaps the single most fundamental culture change that companies must go through when making a true transition to Agile development, and it’s often the biggest stumbling block that prevents them from fully becoming agile. You can see this in so many anti-patterns of Agile development: long-term, specific roadmaps; set dates and forced marches; iterations that are dictated, not created by and for the teams; and so many others. All of these behaviors stem from an organizational inability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along.
“Agile” is More Than a Buzzword: Three Truths Behind the Manifesto
It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…
User Stories Aren’t Enough
It’s commonly accepted nowadays that we use user stories or some variation on them to communicate our “product requirements” to development teams (job stories, jobs to be done, scenarios, etc). And while this is certainly an improvement over some of the bad, old Big Up-Front Requirements (BUFR) methods that were used many moons ago, they’re still not perfect, for a wide variety of reasons. All too often, they assume that certain considerations have already been made, that certain work has already been done — when in fact it often hasn’t. Not every development team has a UX and UI member dedicated to help them achieve a story; not every product can afford to have user-story level architecture decisions being made — and every User Story has to be the result of some amount of planning and forethought, both from a business and a technical perspective. While user stories are a great tool, they’re far from the only tool that we need in our drawer to be effective. Here are some things to consider when you’re relying on User Stories as your primary method of relaying work to be done to your development teams.
- 1
- 2
- 3
- …
- 6
- Next Page »