Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Posted by Amr Elssamadisy on May 22, 2007 08:00 AM
The Agile Manifesto is six years old. Some have become disillusioned with Agile as it has spread and (inevitably?) been diluted. Post-agilism has been discussed even before Agile has become truly mainstream. Some have suggested that we have learned much over these years and the Agile Manifesto needs to be updated. Brian Marick, one of the authors of the Agile Manifesto, gave a keynote at XPDay Toronto entitled Six Years Later: What the Agile Manifesto Left Out and then blogged about it later with clarifications:
Despite coming out for customer collaboration over contract negotation, the Manifesto is something of a contract proposal: We promise to give you working software (at frequent intervals, no less), and we promise to stop whining when you change your mind late in the project. In return, you need to stop slowing us down with things like documents and tools and processes that are sometimes intended to be helpful (though not actually helpful) and sometime are ways to keep tabs on us because you don’t trust us. Instead of watching us indirectly, you need to come talk to us. A lot.
That was an appropriate and successful message for the time, but it’s now a different time. Now Agile is more respectable, a safer choice. The challenge isn’t so much getting a chance at Agile as it is executing once you’ve gotten the chance.
Marick then gave four missing ideas: skill, discipline, ease, and joy. This is similar to what we have previously reported on InfoQ that Kent Beck has been discussing how to have more ease at work and ways that people can bring a deeper sense of satisfaction at work.
Ron Jeffries and Chet Hendrickson have recently announced Five Days of Software Development with Style and Grace as a 5 day training course. When I asked Ron about why the community needs yet another agile class or TDD he responded:
This isn't "yet another Agile class". This is a workshop for people who have come to be interested in the particular way they have watched Chet and me work. We believe that while good software development involves skill and discipline, good software also requires working in a relaxed and mindful state we're calling "style and grace" in this offering. Our plan is to help people understand what we do and how we do it, and to experience it enough to decide how it fits into their own approach.
Simon Baker wrote about a conversation that took place at the previous Agile Practitioners Forum:
At the previous Agile Practitioners Forum, Colin MacAndrew asked the group "Does the Agile Manifesto need refactoring?" and it was encouraging to see quite a few people leap to its defence. Now, Colin simply asked a question about whether it could be improved, he didn't state that it needed to be re-written. And yet the defence of the Manifesto was so vehement it took me a little by surprise. There's a spark for an interesting debate here. I think it's one worth pursuing in a future meeting.
Baker suggested that the concepts in the Agile Manifesto aren't easily understood in the business community and that maybe some of the concepts of Lean, such as pursuing excellence, understanding waste and eliminating it, optimising the whole, and queuing theory, might help alleviate this issue.
Jason Yip, on the other hand, took a more light and humorous perspective on refactoring the Manifesto:
Should the Agile Manifesto itself be agile? Most would agree that it should, but modification of the Agile Manifesto makes sense if the core values of the community have changed. Have they?
Whether they have or not, many of the thought-leaders of the Agile community are moving forward from their experiences and looking to issues not currently addressed directly by the manifesto. Perhaps the Agile Manifesto should mirror the community's evolving understanding of how to build better software.
The Agile Business Analyst: Skills and Techniques needed for Agile
IBM Agile Development eKit: Free Articles, Expert Q&A, Educational Resources
Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Here's the right one.
At the first ADC conference in Salt Lake City I put to Allistair Cockburn the idea that the Agile Manifesto should be "refactored" ( "rewritten" to non techy, non agile types ). It was obvious that "Business Value" was more important than "Working Software" which was more important than "Extensive Documentation". It was obvious that "Good relationships" were more important than "effective communication". ( You may speak the same language as someone but if you have a bad relationship, well it ain't gonna work ). Point is, I had him on the ropes... So I thought. Alistair's response was that the Manifesto was a historical document. It had taken the days at Snowbird to agree the four principles, and then it several weeks of e:mail to agree the rest. This was with a small group of people, less than twenty. He was right. By the time of ADC v1, the Agile community had grown to a thousand or so people. How do we get them all in a room to agree the new Agile Manifesto. Was it possible? The Agile Manifesto is a historical document. The community has a choice. We either leave it as it is. An imperfect call to arms for a new generation of developer who believe in Winston Royce's original dream, or do we update it? Leaving it is easy. Updating it is hard. We have to find a PROCESS for coming up with Manifesto amendments (think constitutional amendments). We can leave it as a play thing of the Agile Alliance board, letting the 10 or so elected official decide, or we have a referendum. Chose your poison. I vote for leaving it alone. I don't need a written set of rules to tell me what Agile is. I'll make it up myself. I would rather do something useful... Like invent cool new tools and methodologies. Good night. I'm off to bed.
Thanks - fixed.
I don't need a written set of rules to tell me what Agile is. I'll make it up myself. I would rather do something useful... Like invent cool new tools and methodologies.
You have a point - but what about all of the new people adopting Agile? Shouldn't they have access to a concise document of our current best?
I also think of it as an historical document. However, if it is going to be refactored, I'd suggest a third strategy: put it on a wiki and see what happens. Those who care will show up to help reshape it... I have no idea where this would go. Personally, I'd rather spend my energy learning how to implement it in different contexts. :-)
The Agile Manifesto is not really meant as a starting point for Agile. They would be better off reading the White Book, and a Scrum Book, and "Lean Software Development", and "Agile Software Development"... and probably some more. Perhaps the AA could sponsor someone to write the "dummies guide to Agile". The Manifesto is really a simple statement of values and a yardstick to measure tools, processes and behaviours against. I like the idea of a wiki. It would be an interesting experiment. It is still a process mind. Another concern is that there are a lot of different view points in Agile. At the moment the community holds together because there is no precise definition of Agile. As we refactor and refine the Manifesto, there is a danger that we cause religious wars, division or fragmentation. The community benefits greatly from its current diversity. I suspect there are very few conferences that can pull together developers, testers, PMs, BAs, facilitators, Psychologists, Astronauts, Leaders and me.
Deborah Now that I've slept on it, i like your wiki idea more and more... However I would like to extend it to cover Amr's idea. A home for "a concise document of our current best". What better way than a wiki to make sure content is current. We should learn from wikipedia in determining the rules for content. As well as "facts", we could have "opinions". My opinion on BDD for example.
I've also been thinking some more about a wiki. I'm surprised that no wiki has surfaced as a central repository, as C2 was for so long for the patterns community. This would be a good thing for the Agile Alliance to support... but it takes more than a server and money. What does supporting a public wiki take? I think I'll ask Sunir over at Meatball Wiki. Luckily he's in Toronto, so I can actually invite him for coffee! :-) This is sort of segway-ing into the other news item on the Refocusing the Agile Alliance, isn't it?
mirc mırc eski mirc script indir irc komutları mirc indir kameralı mirc sohbet mirc indir mırc indir mirc mırc mirc yükle mirc download islami sohbet dini sohbet islami site islami chat kelebek kelebek script kelebekscript kelebek.gen.tr kelebek.com kameralı mirc indir kameralı mirc kameralı sohbet chat chat yap chat sohbet chatsohbet çet çet sohbet çet odası sohbet kanalları izmir sohbet kanalları sohbet odaları aşk sohbet odaları chat odaları soru cevap sevgili sevgili bul arkadaş arkadaş ara arkadaş bul arkadaşlık bedava sohbet arkadaşlık sitesi arkadaşlık siteleri partner erkek arkadaş bayan arkadaş oto araba mp3 astroloji zoydak nedir cep telefonları gazete marifetname bedava domain ücretsiz domain bayii parça kontör bayiliği bayii online kontör
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
9 comments
Reply