This past week we’ve celebrated an agile milestone: 10 years since the signing of the Agile Manifesto. This event seems to have spawned a lot of interest and questions around agile, including a question someone ask on one of the LinkedIn groups I monitor. Nokia Demise: Is Agile to Blame?
I’ve fallen for the bait and decided to bite with this blog entry.
Sometimes failure is a good thing, especially if it’s fast failure and allows the organization to save money and regroup or refocus on their more core business (Google Phone, for example). Properly executed, agile and Scrum support this. My insight into Nokia is limited, but as someone watching from the outside, I see little agile about the company. Conversely some of the companies that aren’t tightly aligned with a specific agile methodology (Google and Apple, as specific examples) are very agile in their actions.
Agile is something we are (or are not), it’s not something we do (i.e. it is not a methodology, or a framework).
Methodologies and frameworks can support an effective agile organization, but ‘doing’ a methodology or dogmatically following a framework or process steps certainly does’t make an organization or an individual agile.
Being agile represents great value for the organizations that are really able to embrace it, but as commented on during the recent 10 Year Anniversary event (10 years with the agile manifesto (search twitter: #10yrsagile) there are still many people who have no concept about the Agile Manifesto. As a CST I work with teams all the time who benefit from Scrum and agile and I also work with a lot more who are simply looking for a ‘silver bullet’. No CST (or other qualified/renowned agilist) that I know of promotes agile or Scrum as a silver bullet; and all of them that I know stress the need for a fundamental shift in the way organizations think and act, not just what they say they are doing. And none that I know would promote that the idea of being agile is easy.
Lazy agile — ‘doing’ agile instead of being agile — will continue to fail. And it will continue to result in questioning whether agile fails: whether agile is viable and valuable.
I have drank the agile kool-aid and I continue to believe that agile, in a pure sense, never fails, even if the product or project we are delivering using an agile approach do. Failure isn’t a bad thing, it’s how we learn. Agile can help us learn fasterand if we don’t the problem is with our not being agile, not with agile itself.
Organizations, individual products, projects fail. Agile doesn’t.
Nicely said Vernon. I’ve been focused on leading a team to Agile more so by doing agile. You’ve inspired me to refocus and be Agile. A new iteration starts tomorrow – back to basics and the Agile spirit!
Great points Vernon! I concur with the importance of the distinction between “being” and “doing” agile. I offer a hypothesis – that the “doing” can be a catalyst for the “being”. Adoption of agile practices, in a non-agile environment, can be a driver for the evolution of organizational agility. Ideally, the “being” and “doing” become a virtuous, self-reinforcing cycle.
The desirable outcome of a self-reinforcing pattern of increasing agility won’t happen by fiat, of course. It can only happen in the presence of other conditions that favor organizational evolution. The best of seeds won’t flourish or even grow in bad soil. What are the critical factors that are needed to precipitate a virtuous cycle of “being” agile, triggered from the bottom (“doing”) up? How might those factors be cultivated, where absent?
P.S. I drank the agile Kool Aid too, and am offering this on the premise that agile is good, and more agile is better.