Organizational performance has been a hot topic for many years. There is no doubt that Agile practices result in better systems and teams that are more effective. But what is the cause of this success and how much does it have to do with Agile/Lean practices? Agile’s focus on iterative development resulting in faster to delivery to the customer is undeniably effective. But that’s not the whole story on why Agile works. This article takes a look at why Agile results in better performance and how you can use this information to achieve success in your own technology efforts.

Scrum as a Framework
Scrum, as evangelized by Ken Schwaber, has emerged as one of the most popular light weight frameworks intended to help guide teams in the effective implementation of Agile practices. The Scrum Master plays a leadership role in managing the performance of the development team. Part coach and part manager, the Scrum Master sees that barriers, to performance, are eliminated on a daily basis. The Product Owner focuses on managing the product backlog (containing the requirements for the system being developed). The performance of the team can be measured in the number of items completed from the backlog. There is a lot more to consider in evaluating the performance of the team.

Rapid Iterative Development
My own career has focused on process improvement including implementation of Configuration Management Best Practices. The key focus in Agile CM is to provide a fast and repeatable way to build, package and automatically deploy releases. Continuous Integration provides a structure for continuously building and deploying releases that make rapid iterative development fast and effective. Most Scrum teams rely upon these practices to help manage iterative development. These practices significantly help teams develop better software with fewer defects. .

Tracking Requirements
Agile focuses on taking a minimal approach to tracking requirements largely in response to the experience of many technology professionals who participated in fruitless efforts to track requirements that effectively changed before the development work could be completed. Agile focuses on working software over comprehensive documentation (as specified in the Agile manifesto). Obviously, there are times when requirements tracking is not optional and Test-Driven Development  can sometimes help to document the same information.

Test Driven Development (TDD)
Test Driven Development puts the right focus on using verification and validation to improve performance and deliver quality applications. Test cases can also be used to document requirements in a practical and reasonable way. Agile also puts the right focus on integrating testing into the automated build process. From automated unit testing in the continuous integration stream to automated functional and regression testing, test driven development helps improve the effectiveness of the development team. .

The Agile Release Train
Dean Leffingwell describes the Agile Release Train in his book Agile Software Requirements, 2011 Pearson Education. In this book, Leffingwell discusses Releasing as a continuous flow of releasing value to the users, in small, frequent, increments – a continuous build of value added to the marketplace. This means that you can release code often, with little fanfare.  Closely related is the concept of continuous deployment.

Continous Deployment
Jez Humble and David Farley discuss continuously deploying code in his book, Continuous Delivery, 2011 Pearson Education. This book puts the focus on implementing rapid build, test and deployment automation. This book describes the deployment pipeline as an automated manifestation of getting software from version control into the hands of the users. These practices enable the team to rapidly build, package, test and deploy applications in an iterative and effective way.

Lean Practices
There are many Lean practices that also help to improve the team’s performance. Mary and Tom Poppendieck discuss seven principles that improve the performance of the team. Briefly, they are: eliminating waste, building quality into the code from the start, creating knowledge in the form of requirements that are amenable to feedback from the stakeholders and customers, deferring commitment to the last responsible moment, delivering functionality to the customer on a rapid basis, respecting people and optimizing the whole value stream instead of focusing on just one part. The Poppendieck’s work was largely influenced by the early work done at Toyota and especially the work done by E. Edwards Demings, widely regarded as the father of Quality Management.

Just in Time Process
Agile focuses on Individuals and interactions over processes and tools (as described in the Agile Manifesto). But this does not mean that processes and tools are optional. We’ve discussed the importance of build, package, testing and deployment automation which is accomplished with the effective use of tools. Process maturity is also essential to consider when implementing Agile.

Agile Process Maturity
Scott Ambler has done an excellent job of defining the need to consider the maturity of Agile processes. Ambler defines the Agile Scaling Model (ASM) as a framework for the effective adoption and tailoring of Agile practices to meet the needs of an Agile team of any size. This is particularly important when Agile needs to scale to support larger development efforts. The ASM distinguishes between three scaling categories:

1. Core Agile development methods that optimized for small, collocated teams fairly straightforward teams.
2. Disciplined Agile delivery are self-organizing methods within an appropriate governance framework.
3. Agility at Scale focuses on disciplined Agile delivery where one or more scaling factors are applicable.

Agile at Scale.
Potential Agile scaling factors include team size, geographic distribution (of the team), regulatory compliance requirements, domain complexity, organizational distribution, technical complexity, organizational complexity and enterprise discipline.

Are You Really Agile?
Scott Ambler provides some realistic and very valid measures of whether or not a team is really Agile.

1. Value – Agile teams provide value to their stakeholders on a regular basis.
2. Validation – Agile teams do, at a minimum, continuous developer regression testing and many disciplined agile teams take a Test-Driven Development (TDD) approach.
3. Active stakeholder participation – Agile teams work closely with their stakeholders, ideally on a daily basis.
4. Self organization – Agile teams are self organizing and disciplined agile  teams work within an appropriate governance framework.
5. Improvement – Agile teams regularly reflect on, and disciplined teams also measure, how they work together, and then act to improve their findings in a timely manner.

(from an ebook by Scott Ambler, IBM Agility @scale : Become as Agile as You Can Be)

Conclusion
Organizational performance can be significantly improved by employing Agile/Lean practices. Rapid application development using iterative practices and automated build, packaging, testing and deployment result in better systems. Testing-Driven Development (TDD) and Lean practices also lead to better software. Implementing an appropriate Agile process at Scale helps to improve team performance resulting in better quality software, enhanced team performance and satisfied customers.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview