Home » Agile » Being Agile Is About The Journey…

Being Agile Is About The Journey…

… Not The Destination

BeingAgileThis post first started as I was discussing my post “You Aren’t Doing Scrum If …” with a friend who had read the post and was worried that I might not fit in an organization that wasn’t doing all of Scrum.  I’ve since had other conversations and as I’ve reflected on the topic, I still stand by my original post, because there are some fundamental properties of Scrum that you have to implement in order to follow that methodology.  This is why I called the post “You Aren’t Doing Scrum If …” and not “You Aren’t Doing Agile If …”

Agile isn’t Scrum

But Agile is different.  Agile isn’t a process. Agile is a mindset.

So you can call yourself “Agile” without necessarily implementing any particular methodology because “Agile” isn’t about process.  Agile is about the collective state of mind of the team.  The organization as a whole.  Being Agile means that you are open to change.  That you embrace change.  Agile is about being flexible.  About knowing that you don’t know and that you don’t know what you don’t know.  Agile is about adapting.  Ultimately, it is about finding ways of being more productive.

In fact, you could implement scrum precisely, which I doubt anyone really does, and not be Agile.

Sacred Cows

In fact, my experience has been that as I try to move an organization along the sliding scale of  being more productive, I will, eventually, find a point of resistance.  The sacred cow of their process.  You can change whatever else you want, and yes, everything else you’ve suggested that we change has proven itself to be a better, more productive, less error prone way of doing what we do.  But, you can’t change our sacred cow. And so far every organization I’ve been in has some sacred cow that we either have to kill or we don’t progress further into being agile.

And so we end up hearing comments from people in the industry like, “I don’t think I’ve been in any organization that has been TOTALLY ‘Agile.’” because every organization eventually runs up against some sacred cow on their road toward being agile.

Leadership Needs To Be Agile

I know of another guy in the industry that postulates that the reason organizations fail as they try to implement agile is because agile is being forced on the organization.  That we need to create an environment where people have opted in to agile.  And to a certain extent, I think he’s right.  But, and I think this is a HUGE but, I think the larger problem is that the leadership has not embraced being agile and so you end up with developers trying to BE agile while the leadership is trying to be predictive.  Funny thing I’ve noticed about most employees, they’ll pretty much do whatever they think will keep the paychecks flowing.  So I don’t think we need opt-in at the worker bee level so much as we need opt-in at the leadership level.  Although I have seen resistance at both levels.

Individuals Need To Be Agile

Finally, while your organization may not be agile at all. It may not do Scrum, or Kanban.  It may resist all attempts to move in that direction.  This is not excuse for you to not be agile. You should ask yourself periodically, “What can I do that might be more productive than what I am currently doing?”  Because an organization can only be as agile as the people working in that organization and sometimes, all it really takes to move an organization closer to being agile is one individual who is willing to do what he or she does just a little more toward agile than they currently are.

What sacred cows have you run into?  What are you doing to be more agile as an individual?  Leave a comment below.

Links About Being Agile


Other post in Agile

Related Post

  • 3 Reasons Agile Will Not Succeed3 Reasons Agile Will Not Succeed I’ve written about Agile and Scrum before and most of my regular readers know that I am a huge fan.  But recently I am starting to believe the Agile movement is doomed.  In fact, the most […]
  • You Aren’t Doing Scrum If…You Aren’t Doing Scrum If… I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.  They’ve officially made it to the point of “buzzwords that mean nothing” that get slapped […]
  • Agile/Scrum Task Board for “Real Life”Agile/Scrum Task Board for “Real Life” The agile “Task Board,” also known as a “Scrum Board” has become a staple of the agile programming world.“Getting Things Done” (GTD) is a process for managing task in the business […]
  • Technical Debt Is InevitableTechnical Debt Is Inevitable loading... Whoa there Dave.  What are you talking about?  Have you given up the fight? You who have preached the TDD religion.  You who’ve struggled to get organizations to […]
  • How to be (Personally) AgileHow to be (Personally) Agile When I first wrote down the idea for this post, I was originally thinking about how we might use agile development practices in a work place that practices Water Fall or worse.  But since […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback

  • Pingback: Dew Drop – February 12, 2015 (#1953) | Morning Dew()

  • Good post, Dave. I’ve not seen the term “application lifecycle risk management” before. Well – I’ve seen related APLM (agile project lifecycle management). We have a long history of *process* orientation (SDLC) in our industry, but I’ve not considered the notion of butting up to the sacred cow. As I look back across my agile consulting career (~20 different companies), I recognize multiple sacred cows – not just one. They come from different directions, often at the same time. Could be management, architects, UX, PMO (common), a QA organization.

  • Application Lifecycle Risk Management. If you abbreviate it, it kind of spells ALARM (take out the A). Just another way of saying “productivity”

  • That post hits the bullseye. So true!
    In the sacred cows topic, i work in a big company, with more than 1000 developers, and we all work on a single branch in our VCS! I tried pointing this issue out, but everyone just screamed at me and told me that it is the only way to implement the CI in the product. I know this is not true, i worked in other places where CI worked perfectly well on branches, but seems like over here i am just a sad minority.

    • So sad. I’m in a similar situation. What I’ve done is implement GIT locally and I commit to the real system after I’ve merged to my local trunk. You can do this with either TFS or SVN. Of course, it depends on how much freedom you have to install stuff on your local computer.

      • I am planning on using gti-svn. It seems like the only way to stay sane 🙂