A Nod to a Solid Team

In this blog I've often lamented the lack of capabilities or understanding of agile practices and how few people understand what it is or what it's benefits are. There is a dilution of agile taking place that is undermining the industry.
I'm fortunate to be currently working on an agile project, and I thought that I would articulate why I am comfortable to call it an agile project.

Firstly, we are using Scrum:
2-week sprints, scrum masters, product owners and teams.
Product Backlog, Sprint Backlog, EPICs, User Stories.
Sprint Planning, Scrums, Sprint Reviews and Retrospectives.
There are a number of additional indicators that for me help to separate the wheat from the chaff:

• A Business Driven Backlog with Integrated Teams
• Clearly Defined, Understood and Adopted Definition of Done
• The Project's Development Practices
• Test Automation at Unit, Integration & Acceptance Level
• Impediment Tracking & Removal

A Business-Driven Backlog with Integrated Teams

Annette Warbrick is the Product Owner for this project. Everyone on the project knows who she is, understands her role and there is a very clear prioritisation of stories. Beyond this, the project has an 'ideal-team' structure that we constantly aim to maintain. 4 x developers, 1 x technical analyst, 1 business user and 1 x proxy-product owner.

The Proxy-Product owners are responsible for ensuring the user stories are well structured and understood with acceptance criteria prescribed for each story. That is to say they do not necessarily write them all, but work with the business users, the team and various business stakeholders to ensure they understand the acceptance level for a story.

An EPIC for this "phase" of the project has been written with clear acceptance criteria, and all stories created can be traced back to the EPIC's overall objectives and acceptance criteria. Sprint zero for this EPIC was a collaborative effort with all project team members contributing to the creation, articulation and definition of acceptance criteria.

All the identified stories were story-pointed and a sampling took place to provide an indicative estimate of time. By applying this sample data to the entire EPIC backlog we created an "Agile Roadmap" for use as a communication tool beyond the programme. The roadmap is updated regularly based on releases into production every 4 weeks.

We used index cards for visibility, prioritisation and transparency of progress toward the EPIC backed up with the use of JIRA.

We've moved from an infrequent, ad-hoc deployment process to delivering new functionality into the production environment every 4 weeks. The impact of this is the rapid and constant "pruning" of the Product Backlog on an almost daily basis.
Roll Call: Laurie Brown, David Singleton, Jonathan Walters, Annette Warbrick (Prod Owner), Ben Williams. Business Users: James Curtis, Graham Baughan, Gus Croudace.

Definition of Done
Critical to the successful continuous improvement of a team is a constant assessment and revision of the definition of done from retrospectives and review throughout the project.
There are 5 elements to this team's definition of done:

1. Covered Functional, Performance and DR Criteria
- Acceptance tests run and passed to satisfaction of all acceptance criteria (with any outstanding defects accepted as not locking release and raised as story on product backlog).
- Includes acceptance of all functional and non-functional criteria.

2. Unit Tests
- Are automated (not 100% coverage but to include full automation of unit tests and to ensure maximum coverage that is reasonably possible).
- Are part of the Continuous Integration Build
- Continuous Integration build compiles successfully and 100% tests pass

3. FitNesse Tests
- Are automated in FitNesse
- Are in the Feature Sets hierarchy in FitNesse
- Contain detailed acceptance criteria and documented to describe what is being tested, how, and the expected behaviour
- Final acceptance test results have been stored in relevant sprint SharePoint folder
- Continuous Integration build compiles successfully and 100% tests pass
Impacted Regression Tests/Suites:
- Updated and /or extended as necessary
- Executed and passed in Acceptance Test environment (no blocking defects outstanding and remainder as stories)

4. Acceptance Environment
- Acceptance is performed in an Acceptance Test Environment using appropriate code, configuration levels and data

5. Configuration Version Control
- Automated where possible (using Configurator or other mechanism).
- Release Run Book and associated documentation complete
- Final release candidate regression iteration involves refresh from PROD and full runbook as pre-requisite

Any deviation from the definition of done is not acceptable as normal working process. However, there are times when either business drivers or technical impediments may prevent completing a story to the full definiton of done. The team discusses each situation and if this occurs, a new story is written to ensure the debt is re-paid in a following sprint.

Development Practices
The project is using most if not all of the Extreme Programming practices. Simon Ashdown has led the recruitment of a strong team of Java XP developers. The developers use pair programming as part of the recruitment process to try to establish candidate's real capabilities. A blend of product knowledge, business knowledge and XP knowledge has been achieved.

Pairing is the default start point for every piece of development effort. Test Driven Development is used by all developers obviously with Continuous Integration and Refactoring. The results of this approach have been good. Noting that the creation of business functionality has been the priority, not 'tidying-up' code, within a few months the following outputs have resulted as a direct consequence of extreme programming practices.

Code coverage has increased from 2.7% to 22.5%. (much of the code base was inherited from a development team who didn't write tests)
Complexity/Class has decreased by 70% across the entire code base.
Duplication of lines has decreased by 35% across the entire code base.
Rules violations have decreased by 30% across the entire code base.

The guys have been working under the informal rule of "always leave the code in a better state" and I can categorically state that the priority has been on delivery of functionality rather than fixing or improving the code. Yet they have accomplished the above through the adoption of XP practices whilst maintaining the fastest velocity of any project at this company.

Roll Call: Jason Annadani, Doug Carolan, Gareth Chapman, David De Florinier, Gijsbert Deelder, David Dunwoody, Andrew Gray, Patrice Guerreschi, Ka Fi Kan, Paul Keeble, Simon Maxen, Pawel Pabis, John Pither, Alex Powell, John Rae, and James Shiell. Analysts: Robin Roos, Julian Smith.

Test Automation
Gojko Adzic and Tom Roden have been at the centre of the project's acceptance test process. Evangelising, coaching and implementing the use of FitNesse as the automated acceptance test suite, it has become central to everything the team does.

As stories come into team sprints the product owners, business users and rest of the team assess the acceptance criteria and create automated tests in FitNesse upon initiation of the work, this provides developers with immediate acceptance results to any code they create using TDD.

Developers create their unit and integration tests as the software is written and then the FitNesse tests are ready to help the developers understand when the acceptance criteria has been met.

Most of the entire application's business functionality is automatically acceptance tested on a daily basis. The effect of automated acceptance testing using FitNesse is a dramatic reduction in man-days to complete the job of regression testing a release, as the graph below articulates.

This strategy has been key in the reduction of time to market for development and allowing the team to confidently deploy software to the business every 4 weeks. The yellow line on the graph below shows that a full regression test of the solution used to take 100 man days of effort, whereas now, due to automated acceptance test suites, it takes 3 days of effort. The graph also shows an estimated projection of what the actual number of days would have been by the end of the project in the dotted line of 500+ man days of effort.

Impediments
I guess this is the crucial element in any agile implementation. The ability of an organisation to remove impediments. The removal of impediments increases the velocity of software production, improves the quality of software production, and increases the morale of team members as their environment and their problems are being removed, and work is made easier.

At the Scrum of Scrum level, we have been tracking impediments through every sprint. We have been using an agile balanced scorecard to help inform our conversations around progress on backlog burndown, technical debt, continuous improvement & impediments and waste. Rather than nail people to changes in metrics, we use the trends to inform us of areas to improve and the impact of impediments.




The developers instigated the idea of the use of the waste snake and the scrum masters regularly reviewed the type of waste being created and the means to remove it.

In spite of all of these practices, I personally feel that we haven't really faced into the key issues in the business. The Scrum Masters, (myself included) have been proficient at removing impediments at the programme level i.e. direct area of control and influence, but wider ranging impediments that require action from departments beyond the programme area have not been successfully removed e.g. Environments, PC performance, Executive mindset and portfolio management.

I think that within this organisation, the most effective way to remove these impediments would be through executive sponsorship. As although at a programme level agile practices are understood and endorsed, beyond this level there is little understanding of how the executive role needs to evolve to correctly support agile adoption. - My experience tells me that this is not uncommon.
Roll Call: Simon Ashdown, Steve Garnett, Nik Patel, Tom Roden, Ian Shimmings.

The Future for the Team
Over the last few months, the team - from ad-hoc feedback - has become an example within the business of how to conduct software development. I am sure there are many executives reading this that would like to have a large team of strong XP developers, with business domain knowledge, automated acceptance test suites, teams integrated with business users, strong product owners and a 4-week delivery cycle from story to production.

Well, unfortunately the portfolio has changed based on valid business priorities, but rather than move this team toward the next strategic priority, the team is being dismantled. I certainly understand the need to shift portfolio priorities, but surely the learning, processes and rhythms of this team could be utilised elsewhere within the business, rather than losing the people and have them take their knowledge to the competition?

Regardless of this, I think all members of the team will have learnt a great deal from this project to take on into their future roles. I for one have enjoyed the experience, and hope my next project is as rewarding.