There are many Internet debates about what agile software development really is. Unfortunately, the term “agile” is misleading. The dictionary lets us down with definitions like “move quickly” or “think quickly”. Synonyms for agile lead us to fleet, graceful, nimble, spry or supple. Do any of those terms describe how your development team operates?
Agile development teams shouldn’t focus on being quick or nimble. They should focus on building great software. There’s a big difference between: 1) getting an entire software system completed quickly; and 2) delivering great software on a frequent, incremental basis.
Number 1 is about getting the software out the door as soon as possible with whatever compromises need to be made. Number 2 is about building what the customer wants in a high-quality fashion.
Every situation is unique.
There are circumstances where #1 is the right approach. For example, your company may desperately need to respond to a competitive threat. The company may need to demonstrate a new capability right now or risk losing market share. Forget the rules. Just get it done or jobs will be lost.
If we are doing our jobs well, situations like the above will be rare — not non-existent, but rare. More commonly, software developers will have a set of goals and a workable timeframe. I define “workable timeframe” as one with enough duration to accomplish a lot of great work but not necessarily enough time to achieve all of the desired goals. Compromise is always needed.
Making matters more confusing, agile is an umbrella term covering multiple development approaches including Scrum, Kanban, Lean, XP and others. Agile software development is a set of beliefs that influence and guide specific approaches like Scrum and Kanban. It is not a prescribed methodology.
Being agile is harder than it looks.
Enterprise software development is a complex and labor-intensive effort requiring many skills and multiple teams. Let’s agree that no single word can capture the essence of what we want enterprise software development to be. It’s just too complicated.
So, if the word agile doesn’t adequately describe what we want software development to be, what does?
We must recognize that developing software with agility is an enterprise-wide endeavor. Software developers cannot be agile if the corporate environment is rigid and prescriptive. With that in mind, I believe there are several key words and phrases that distinguish agile organizations:
- They are highly cohesive, loosely coupled and decentralized.
- They implement constant feedback cycles and continuous improvement.
- They are known for rapid responsiveness and swarming behavior.
- They have diverse skill sets and share a common vision.
I also like what Anders said yesterday, “…the ability and willingness to learn by experience and failure is the most important item on the path to becoming agile.” I’ll address learning by discussing actions organizations can take to facilitate learning.
It takes all of the above to fully-practice agile software development. Simply having daily standup meetings does not mean you are practicing Scrum. Simply using sticky notes on a wall to track tasks does not mean you are practicing Kanban. Simply testing the software iteratively rather than waiting until the final project phase does not make you agile.
It’s time for a more rigorous and structured definition of enterprise agile software development. Over the next several posts on this blog, I’ll offer my ideas and opinions. I hope others will join in whether they agree or not.
[The next post in this series is here.]
Re-reading the Agile manifesto : ‘Responding to change over following a plan’ is listed as one of the core values. Under principles it continues:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Building a set of delivery practices both in the way we engage with our clients and the quality of the software we produce that allows us to absorb changing requirements with near-to-zero impact is I believe that’s actually what’s commonly understood to be the core measure of agility.
The agile manifesto makes it sound simple and in small teams within small organizations, it is. In large enterprises, the rules change. There are many different types of “customers”. Requirements surface from every direction. Delivering software into a complex hierarchy of interconnected systems is a big deal. It’s hard for the team to maintain focus and get stuff done. The current agile manifesto is too narrow. There needs to be an “Enterprise-Agile” manifesto in my view.
I wouldn’t define agile software development based on what is written in a dictionary for the word ‘Agile’ itself, but what the framework really is (which can be basically taken from the manifesto).
I agree that the manifesto is a good place to start. It is a set of principles or beliefs that drive agile teams. I’d like us to go deeper and define a set of behaviors that exemplify the beliefs.
Here are some qualities that come firstinto my mind:
– open and willing to change
– admit mistakes and want to become better
– flexible and creative in thinking
– more result oriented than process oriented
I’m prettysure that there are lots of othequalities that should describe agile engineers (not developers, since the teams are cross functional). BTW, we can even share ideas and vote for top ten