Our Post-Agile World

It’s been a looooong time since I’ve posted anything about Agile, and today I sat down to try and figure out why. It’s not that I don’t care about the values in the Agile Manifesto, nor that I’ve gone completely over to Zed Shaw’s manifesto.

It’s not that I’ve found Lean/Kanban to be the end-all be-all, although I really love the simplicity in the approach (with a lot of back-end difficulties around being forced to ask tough questions).

You can code really well, but produce software that no one uses. You can produce really crappy software that a lot of people use, but then is hard to change in the areas the business desperately needs it to.

Instead, it seems that our company these days has focused on a couple things that tend to make some of the other ideas, just not as important. Or not TOO important. What we’ve settled on as our overriding philosophy of what our goal is are two-fold:

  • Deliver released value early and often
  • Don’t surprise the users or the clients

Releasing early and often forces a lot of other practices in place, with a specific goal in mind (deliver value).

No surprises is around setting expectations, having the conversations to figure out WHAT should be built.

No surprises = figure out WHAT to build, WHEN it will be delivered, and actually deliver it. Commit to what you can, set expectations on what needs further refinement before commitment.

Deliver early and often = Mitigate risks by making sure working software is actually in production as quickly as possible. Long release cycles are hugely risky, and have a greater chance to screw up, therefore negatively surprising the client.

Good surprises are a risk too! That “surprise” feature is good for new users, but the business owners shouldn’t be surprised by the feature you decided to also include.

With these two guiding principles in place, all of the practices around XP, Scrum etc. sort of become tools in the toolbelt that can be used, sometimes, when they help with delivering without surprises. Otherwise, they can be a waste.

Looking back again on why I’m just not interested in Agile any more – it’s not that I don’t find value in these tools, but I get tired of discussions that don’t involve context of WHEN these practices are useful. Too often it’s black and white (i.e. the term ScrumBut) and not a real look on whether these practices ACTUALLY add value.

Because it comes back to just one thing: Are you consistently delivering value to production without surprises?

Extra credit: Go read The Goal, right now, if you haven’t already.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://benlakey.com/ Ben Lakey

    Thanks for the post Jimmy. 

    Do you think your lack of posting about agile may be representative of the industry in general, and perhaps we’re starting to close in on some accepted and proven methodologies? 

    Joel Spolsky actually just posted something yesterday about this stuff, but a lot more granular. He’s basically done a bit of a deep dive on the 2 simple ideas you’ve mentioned, and framed it in the context of Fog Creek’s ‘Trello’ software. Check it out if you haven’t already read it:

    http://www.joelonsoftware.com/items/2012/07/09.html

    I recently took some of these ideas and tried to apply them to a less software-specific idea about general productivity. The result was a simple system using notecards:

    http://benlakey.com/2012/05/27/a-system-for-getting-things-done/

    In the context of software, I think limiting work in progress is something our industry in general is getting pretty good at, but delivering early/often is still lacking in a lot of organizations. Sometimes it’s infrastructure that becomes a limitation for often delivery, but more often it’s just breaking old habits.

  • Eric Hexter

    well said

  • http://twitter.com/postAgilist Post-agile Architect
  • James Howell

    Insightful post. Thanks. 

    • http://twitter.com/postAgilist Post-agile Architect

      Perhaps we need to get a post-agile mailing list going… I know several people who are interested in post agilism. I think it’s going to be an important topic in the coming years as people realize that Scrum etc, do have serious downsides and opportunity costs and need to move on.

      Jordan

  • Codingjacket32

    How about a NSFW warning on the Zed Shaw manifesto?

  • Pingback: Top Picks: Miscellaneous | Peter-John R. Lightfoot

  • Pingback: Peter-John R. Lightfoot | Top Picks: Miscellaneous