Designing and Developing Cross-Cutting Features
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
Article
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Agile at 10 – A State of Contradiction
Posted by Mike Beedle on May 03, 2011
This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
RelatedVendorContent
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Agile is in a true state of contradiction. In some ways Agile as defined 10 years ago is dead or at least passé - the best practitioners have taken what we defined as "agile" 10 years ago - which was a reflection of what the best practitioners had done for 40 years, into something different, but this new state of the art has not been documented to date. Also, as Agile as defined becomes mainstream, it will simply be called "software development".
My guess is that this has already started to happen: there are some companies that were medium or small 10 years ago that have grown with Agile embedded into their DNA - they don’t know any other way to develop software.
On the other hand, Agile is as alive as it ever was, because there is more lip service paid to it, and there are more true efforts and budget allocation to implement it as defined 10 years ago everywhere: every industry in just about every country has Agile implementations. Yet, there is danger in such a wide range of "we are Agile because we implement L with X, Y, Z". We need to worry about how diluted the meaning of agile is becoming, and focus on real quality.
We need to raise the quality of Agile implementations and we also need to document the state of the art as it is today, to make it easier for practitioners to envision the future.
In regards to quality, at the 10-year Agile Manifesto Workshop (see this link) we came out with four statements that we thought were possible to implement:
- demand technical excellence,
- promote culture change,
- maximize business value,
- organize knowledge.
These four statements convey a powerful, relevant and accurate mission as to what Agile as defined 10 years ago needs to do to survive with a clean name. Otherwise it runs the real risk of getting diluted, badmouthed, and thus enlarge the backlash it already has with every Agile implementation gone bad.
What Agile as defined 10 years ago needs is an action plan to put these four statements to work in organisations today.
In regards to the future and current state of Agile, the true state of the art as of today remains undocumented in the Agile Manifesto or elsewhere.
Among other things the state of the art includes these days are the many advances that have been made by practitioners over the last 10 years in many interesting directions:
- Agile for business, implementing Agile in other processes other than software
- enterprise implementations
- value-driven techniques
- organisational patterns
- scaling
- distribution
- swarming
- culture change
- layered testing
- continuous integration
- user involvement
- agile metrics
- agile architecture
- mixing Agile with other useful things like Lean/Kanban, etc.
So as a community looking into the future we need to revisit what is "current state of the art" and possibly come up with an Agile Manifesto 2.0.
I’ll share with you what I do in one of my standard presentations - I play with the class or with the audience a game called "Re-write the Agile Manifesto with your thoughts and feelings now".
Here is one of the outcomes:
Beyond Individuals and interactions to hyper-productive Swarming jelled teams and communities of practice
Beyond working software to high-quality, well architected and well-tested user-centered software services
Beyond customer collaboration to user collaboration and user involvement
Beyond responding to change to prioritizing and optimizing for change
Beyond single Agile teams to Agile Enterprises
Anyone can do this and I think is great to see what people can write or expand on the original ideas of the Agile Manifesto based on advancements in the state of the art over the last 10 years.
Good luck in all your Agile Transformations!
Please add you contribution to the manifesto 2.0 in comments below.
About the Author
Mike Beedle is one of the first Scrum adopters with experience practicing Scrum since 1996 in a variety of business environments. Mike and his companies have introduced Scrum to thousands of people and hundreds of companies, providing training, consulting, mentoring, coaching and hands-on consultants, developers and Scrum Masters to the industry
Mike Beedle is the co-author of the first Scrum book, the co-author of the first Scrum paper published in a book, a co-author of the Agile Manifesto, the author of the upcoming Enterprise Scrum book and one of the co-authors of the upcoming Scrum Pattern Language book. (See this link)
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
Organizational Patterns
by
Jens Meydam
Posted
What makes Agile agile?
by
Udayan Banerjee
Posted
Agile contradiction - also in the article
by
Adam Nemeth
Posted
-
Hi Mike,
Could you expand a little on the role of organizational patterns - the role they actually play today and the role they potentially could play?
Are there books on patterns that you recommend to your clients?
Thanks,
Jens -
Two interesting statement here:
- Agile as defined becomes mainstream, it will simply be called "software development"
- There is danger in such a wide range of "we are Agile because we implement L with X, Y, Z"
So, how do we answer the question "Are we agile?" or "How agile are we?". For that matter, how can we say that "agile has become mainstream?"
Is there are objective measure? Is asking for such measure blasphemous?
setandbma.wordpress.com/2011/01/24/what-makes-a... -
Just two sentences:
becomes mainstream, it will simply be called "software development".
promote culture change
Of course, this may be intentional.
I came into a world where sometimes the cultural change was about to drop agile: sometimes dropping daily standups as devs don't speak to each other, but also, sometimes to introduce old-style concepts, like, "think before you code" or "don't write the whole system before you're sure that you understand each other with the customer well enough"
Agile was about to separate a little group and set them free from some of the corporate rules: this was what made IBM PC possible, this was where people felt they're set free.
I totally understand the situation where you came into an enterprise, and you felt that nothing gets done, and you deemed progress, and you set up a team, and there was success, and you were happy, and wanted to expand it to others.
Now, the situation is similar to me, when teams don't understand each other, and I ask for certain UML docs to be used between teams aside f2f meetings, when I ask to send around meeting notes - because these are also solutions for problems, these aren't the problems themselves.
I don't think we could ever expect people to be able to recognize problems en mass.
I don't think that RUP or Agile are only about mistakes, or are totally free on it.
I don't believe people en large scale are able to always choose the right tools.
3 comments
Watch Thread Reply