Imagine Socrates, Plato, Confucius, Seneca, and Marcus Aurelius coming together and writing one single book that represents the combination of their philosophies. Now imagine a one-pager version of this book. How much of it could you comprehend, let alone practice? That’s the problem with Agile. The is way too concise. Agile manifesto No wonder we keep getting lost in the details, and two decades later, some of . the creators of Agile still continue to explain it to people, with varying degrees of success I’m not here to give you some magical formula that will suddenly make Agile comprehensible. This series is more about me trying to wrap my head around Agile, in public, and learning from you along the way. So please comment, reply, refute, and help me make sense of this apparent red pill of software engineering! When I started my career about 12 years ago, I got lucky. My first job as a QA engineer was with a San Francisco-based startup with an offshore office in Karachi, Pakistan. We never talked about Agile. We used spreadsheets to list down all the things to do, the assignee and the progress status, and skype calls to talk about it. I don’t remember having backlog refinement meetings, but we kept our backlog clean and plannings were always pretty fast. With every year that has passed since that start, it becomes irrefutably obvious to me that we were agile. Everyone in the team spoke with the customer success team pretty much every day, and every time we released a feature, the most available engineer (usually the QA engineer) would walk the customer success team through it. We got tons of feedback on a daily basis from the customers and the people closest to them, and we responded to change as if it were a walk in the park. We talked incessantly about upcoming features and improvements, and how they would be useful to our users, and released our latest work every two weeks. This experience gave me my functional definition of Agile: Get real, talk to each other, and remember that it’s a business, so get things done. In other words, no processes, agreements, and plans are too sacred to be touched or changed — no matter how difficult or far from our own initial understanding of the situation. We realised that, as a business, there’s a job to be done. And that there will always be constraints, so we must learn to negotiate with each other constantly, minimise waste, and ship fast with good enough quality. Moreover, doing our job in such a way that it helps another colleague to do their job better, was the best way to be happy while working hard in a VUCA world. Looking back, I feel that we were just agile, without overthinking it. We somehow managed to adhere to the Agile Manifesto in our actions, perhaps because we were a young team without much pre-existing baggage, or perhaps because no one told us how important, difficult, or complex it could be. My strong suspicion is that we managed to be agile, simply because we all agreed on one thing: , so we communicated as much as needed, documented only as much as needed, and adapted processes to help us collaborate better, and deliver working software. we were collaborating to make the product and the business a success Agile continues to be misunderstood and misrepresented, perhaps because the simple truths it shares are too concise for us to understand unless we’re the lucky beginners who are not held back by our past karma. And like most wisdom traditions, the more pre-existing knowledge you bring to the sages, the harder it is to accept and apply the simple ideas they share with us. We must go through a long process of unlearning our convoluted ideas of reality before we can appreciate the simplicity of wisdom. So instead of overthinking Agile, here is the lesson I draw from all my experiences since that first job: If you want to get Agile, start with mapping the Agile principles to the status quo, and ask two simple questions: Does X seem to conform to the Agile values and principles? What can we do to make it more Agile? The problem with Agile Manifesto being so concise really comes down to “well, it sounds good but how do we make it happen?”. Asking those two questions will get you started. Keep asking them and they’ll get you farther than most. Like every process, system, and person who wants to transform, it is easier said than done — including asking the two simple questions. That is why part 2 is going to be all about Agile Transformation. And part 3 will be all about Joy in Agile-Land.

Keep

How To Build Products Like a Scientist

What Is Your Leadership Style

Never lose sight of your goals!

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

The Problem With The Agile Manifesto

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

CARPA: How To Identify Fortune Cookie Advice, As An Entrepreneur

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

CARPA: How To Identify Fortune Cookie Advice, As An Entrepreneur

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps