At the March SQuAD conference, presenters put forward some fairly stringent expectations for teams to meet before claiming they were truly “agile”. While approximately 50% of the attendees claimed to have implemented agile practices within their organization, only a handful could say they were actually creating production-ready software every two weeks. This got me thinking, with all the hype about agile today and the efficiencies it creates, are we doing ourselves more harm than good by only going half way? Why is “Agile But” more common than agile proper and what should we do about it?
My thought is that “going agile” is typically thought of as something the software development team does to become more efficient. In reality, the software development team is merely one prong in a larger change effort. “Agile but” happens because as technology leaders, we give the teams the liberty to do two week sprints, but we pull all the test resources to regression test a release for a different project. Or we demand the two week sprints but fail to find a business resource for the full-time product owner role or allow the BAs to continue communicating requirements in use cases. Or we ask for the output of agile without fully comprehending or applying updated development practices required. Or we simply compromise on what “done” means within a sprint. This list could go on and on. Many agile practices are hard to implement and require alignment outside the collection of “pigs” doing the actual development work.
As I consider these thoughts and the number of hands raised at that conference, I recall moments when I was director within a technology group and essentially the key stakeholder when it came to our software development process. At that time, I had thoughts (and often said things) like “Agile seems really interesting, but I doubt we’ll be successful without some outside help. And we don’t have the money (or the commitment) to do that right now.” Having seen the number of hands raised in those meetings I cannot believe that I was wrong, but I do wonder how other managers are still expecting fantastic results without significant investments: in time, short-term productivity loss, and old-fashioned money to train and coach your teams.
If you are a leader in an organization that’s doing “agile but” it’s time for you to make some tough decisions. What is the constraining factor for your team? What agile assumptions have you decided don’t work for your organization? Can these really stand up to scrutiny from an outsider who knows agile in and out? Take a hard look at what you are demanding from your teams and what you are investing in them. It may be that your expectations are out of sync.
And after being hard on yourself for a few minutes (or a few hours). Take a deep breath, relax, and ask yourself (or better yet your team) one question: what’s the one thing we can do to be more agile in the next week. Then do it. Repeat.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 2 comments… read them below or add one }
Hi Laura,
Just before I read this, I happend across a blog that used the term “Post-Agilism” http://www.kohl.ca/blog/archives/000184.html .
He and a couple of linked blogs made a very good case for adopting Agile to the extent it works for the project, and not getting too wrapped up in the “religious” tenets of the Agile proponents. A linked article by Alistair Cockburn listed his top-10 attributes of an Agile project, and highlighted his sellf-adaptive Crystal methodology in a way that was not previously all that clear (no pun — on Crystal Clear — intended) to me. I think post-agile might be a synonym for your”agile but”. Check it out.
Great post, most of what I read on failed adoptions all come down to the same thing. Fear, un-certainty and doubt (FUD) usually lead to ‘agile-but’ or ‘scrum-but’ as a result of mangement perceiving a loss of control. I find executives love the end result of ‘being agile’ but usually don’t participate in and support the reality that surfaces during adoption.