In order to do that, there had to be a lot of adjustment. You can read the wonderful XP books (explained, installed, etc) from Addison Wesley, and you can follow a lot of the reasoning on the c2 wiki (you know where/what that is, right?)
They came up with a very simple system with almost no overhead compared to all the development "methods" or "methodologies" that preceded, and they delivered all the time.
Of course XP is offered for free with full disclosure (even caveats!) for anyone who wants it. No certification, no official certifying body, just solid results. Of course, it languished while other orgs who can afford more marketing and franchising opportunities went large, and now it is making a comeback.
XP practitioners were key signers of the Agile Manifesto, and I like to think that the manifesto values and principles are particularly descriptive of XP rules. I hope the comeback is big and noisy.
But as I look at the world, I see that there are a lot more ideas and practices that also contribute to simplicity and safety. Each of them requires a lot of change in how you think about the work you do, and how you arrange the practices and teams to support that work.
Continuous Deployment requires and provides a lot of safety, especially with all the work being done in devops and all the cool server tech and virtualization we have these days.
Lean Startup brought a lot of safety to the realm of product management. Suddenly it is possible to know more about market demand and fitness to need before you invest heavily in building a feature, and certainly along the path from MVP to fully-built-out features. All those options and pivots have helped many entrepreneurs launch successful businesses.
The beat goes on. The constants that predated Agile methods, that empowered and grew those methods, and which have gone well past their original moorings are safety and simplicity.
I think this is natural. I've noticed a path for technologies that goes something like this:
- Some activity X becomes possible which was unthinkable before.
- People rush to implement.
- People note the madness and competition, and try to build a solve-all comprehensive implementation.
- Sick of the complexity and learning curve of solve-all implementations, people rush to build a simple implementation that doesn't have all that "crap" in it.
- Sick of complexity and learning curve of the simple solution, people rush to build a simpler solution.
- Sick of the design flaws that make the simple implementation too slow to use, people rush to innovate even simpler and more performant implementations.
- GOTO 1.
Can we just cut to 6? Probably not. But most of us don't need to.
I wonder if maybe someday we'll be mature enough as a market to stop talking about waterfall, scrum, scrum-but, wagile, scrummerfall, scaling agile, etc. Maybe we can get to the point where we build our entire discipline on safely, simply, repeatedly delivering working stuff.
Safety and simplicity are hard. Simplicity requires more clear-thinking than most of us can afford, and safety requires us to admit that what we're doing is risky, and then requires that we make the effort to change our system.
Those who will bend themselves to the task, can get to steps 5 and 6. It's just work.
A future built on safety and simplicity holds a lot more promise than one filled merely with stand-ups, ideal day estimates, planning days, and hardening sprints.
This is why I say that the only "post-agile" or "beyond agile" I'm interested in is work that takes the safety and simplicity that XP brought to us and extends it well beyond it's known reach.
How do we get there? I'll try to let you know how I am trying, and how about you tell me what you have in mind?
No comments:
Post a Comment