Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Mishkin Berteig on May 16, 2006
Agile is a set of practices and principles that help teams and organizations work more effectively by empowering teams, amplifying learning and eliminating waste.In one organization, an agile team discovered two weeks into a 5-month project that the work they had planned out would be wasted effort. Why? In collaborating with their customer they determined that working on something else could actually provide 80% of the project's value. Their plan was irrelevant to delivering that value. The team recommended to management that the existing plan be discarded. Management accepted and the team halted, replanned and ran a single four-week iteration, in which they delivered a working system that provided the expected 80% value. The remaining 20% of the project's value was deemed insufficient to justify the cost of the team, but they had wasted only two weeks on the original, now-obsolete plan, and could quickly move on to more valuable projects. Management and customers were ecstatic, and team members were happy with the results: unexpectedly, they had make a much larger contribution to the bottom line of their organization than originally planned.
Technical Debt and Design Death
Agile Development: A Manager's Roadmap for Success
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Another organization's very first Agile pilot project was able to deliver working software in only two weeks. This project had been stalled for two and a half years due to an inability to finalize requirements (a condition known as "analysis paralysis"). The customer for the project loved the initial, albeit imperfect, results. Several stakeholders attended the team's demo of the working software, and valuable feedback was gathered for a new version with more functionality, to be delivered in another week. The development team was proud of their accomplishment, and thrilled with the real feedback they received. Every week the team delivered a working version of the system with more and more functionality, and with adaptations to the previously built functionality to make it better. The customer said he liked the process so much that he would never work on a non-Agile project again, if he had his way.
The Benefits of AgileThe benefits of an Agile approach for the business person or end user of software systems are clear: Agile methods allow teams to build higher-quality systems, with faster return on investment. Customers can learn as they build instead of having to "get it all right" at the start. The short, built-in feedback cycle rapidly provides features that satisfy customers' real needs. Agile methods also provide more options for managing change and risk than traditional project management techniques. Furthermore, they allow teams to show off their creativity and problem-solving abilities, in ways that the organization - customers, users, other departments - can actually see, value and use.
What's the Down Side?Agile methods are hard to do right! There is no simple checklist guaranteeing success. Agile adoption takes high levels of discipline, tolerance for failure, trust, truthfulness, visibility, sincerity, patience, striving for excellence, and just plain hard work. In some workplaces, the fruit of all this effort and good intention would be rapidly dissipated by chaos or bureaucracy in the organization. But Agile methods channel this effort into a learning cycle that actually makes a difference incrementally over time.
So, What is Agile?Agile is an umbrella term that encompasses a spectrum of methodologies, ranging from purely management-focused to purely technically-focused. Some well-known examples include Extreme Programming, or XP, Scrum, Dynamic Systems Development Method, Feature-Driven Development, and Lean Software Development. There are others as well, often the result of an organization adapting one or two well-known agile methods to their own circumstances.
XP is infamous for its unusual "pair programming" practice, requiring that all production code be written by two people sitting at a single workstation. However XP has also popularized the use of the XUnit testing frameworks, including JUnit, NUnit, and HTMLUnit, all of which are used in the Agile practice called test-driven development (TDD). This practice is recognized as a key tool for creating software with excellent design quality and extremely low defect rates.
Several agile methods including Scrum and XP feature a very short iterative cycle whereby working software is delivered and then plans are adapted based on feedback from stakeholders. This adaptive planning gives the customer/user of the software two huge advantages compared to a traditional phased development lifecycle: first, the customer can request adjustments to the actual working software based on what they learn as the project progresses, and second, the customer has the option at the end of each iteration to actually use the software in its current state, and start reaping its benefits. Since these iterations are never longer than 30 days in length, any mistakes made along the way are detected and mitigated quickly instead of provoking a crisis near the end of months or years of development.
How Agile Must We Be?There are many other agile practices ranging from continuous integration, task boards and user stories to financial modeling and appropriate metrics. Each agile method defines its own clear set of practices and rules as a starting point. However, choosing a specific method to start with is not the critical decision. Rather, the key success factor is the open and honest communication that supports the learning process. Once a team gets used to regularly and transparently discussing their work, they will see that each practice has its own place, its own benefits and challenges – and each can be implemented in response to a real need, not according to some cookbook plan. Agility resides in the team's ability to modify its own working process, always with a view to providing more value to the enterprise while reducing waste. In this way, the Agile enterprise continues delivering real value in the face of uncertainty and even adversity.
Further ReadingAgile Software Development is based on values and principles, rather than lists and prescriptions. The following web pages lay out the foundations upon which the this movement has grown:
Mishkin Berteig is an agile methods coach and trainer based in Toronto. Mr. Berteig has extensive experience coaching teams and organizations in adopting Extreme Programming, Lean Software Development and the Scrum methodology and is developing an agile method to apply to non-software environments. He writes about the human and organizational aspects of agile methods on Agile Advice.
Alright, that's all very plausible: TDD, shorter iterations, more customer involvement, quickly adapting plans to feedback, etc. But there are two elephants in the room that need to be talked about: Contracts and coordination between multiple projects/parties. Both have a tendency to contradict agile principles because they are simpler to do when things are cast in stone at a particular time. Re-negotiating contracts, interfaces and schedules takes time too. I would be very interested to hear about agile contracts and agile multi-party coordination.
Multi-party coordination is fairly simple: just follow the same basic principles and discipline including self-managing teams, amplifying learning and eliminating waste. In practice this means that as much as possible, you want to:
- avoid long approval processes that require chains of management in separate organizations
- put people in the same room together even if it means flying people around the world (that's inexpensive compared to the cost of mistakes due to mis-communication)
- use the "Scrum-of-Scrums" status reporting method where representatives of each team involved regularly share status
These techniques are not easy. They often take considerable management support to put into place. Even more important though is that they require TRUST among the parties involved. This is the underlying foundation for agile methods. It is relatively easy to establish a workable amount of trust in a small team in a single organization. It is much harder to do this in a multi-team, multi-organization environment. Nevertheless, in order to use an agile method, one must be able to establish trust.
If you are unable to establish "agile contracts" with your clients/suppliers, it is likely because of a lack of trust. I'm not an expert on agile contracting (I've focused more on single-organization agile implementations), but I do know that Mary Poppendieck has a lot to say on this topic (www.poppendieck.com) and that Toyota and their relationship with their suppliers is often held up as a good example of trust-based inter-organizational relationships.
Our company is embarking to be certified for CMMi Level5. During initial briefings, we're seeing a lot of additional documentation activities for tracking, metrics, etc. I'm just curious how would an agile process and CMM fit together?
CMM and agile can fit, but most approaches to CMM are very document heavy and _not_ compatible. CMM is usually used as a prescription to improve the maturity of a software development/IT organization. However, CMM is meant to be a descriptive model. The additional activities that you are seeing are only useful if they don't become barriers to your primary goal: organizational success. In software development/IT, your contribution to organizational success is primarily dependent on being able to deliver working systems in a timely manner that actually satisfy customer/stakeholder needs... as they pertain to organizatonal success. If CMM is adding a lot of documentation, it is likely going to end up hindering your ability to deliver working systems in a timely manner. Check out my article The Art of Obstacle Removal and my whitepaper (pdf) about the relationship between lean and agile methods.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
4 comments
Watch Thread Reply