Agile

Scott Ambler and Damon Poole discuss how IBM scales Agile across large teams ( sometimes in excess of 500 people ), in an article Agile development: It isn't just for small projects

While a brief article it does touch on one or two of the really key problems facing agile scaling; how to size and split teams into management units. As Ambler says "The architecture should be a system of subsystems." and therefore according to Ambler "the structure of the teams should be aligned with the architecture, and ideally the sub-team members should be co-located."

I have to admit that I always saw greater perceived value in creating teams that attack vertical slices through the architecture, ultimately these teams deliver end to end stories, and this worked extremely well on a major project I did for AOL. However at one of my current clients, this is just not feasible at this stage, the political makeup of the organisation and the inherent compartmentalization of existing teams, mean that its has been a major ( and ultimately impossible ) struggle to get a manager ( who once controlled his whole team ) to seed various functional teams with one or 2 of his assigned developers. We have therefore grown into a suite of teams split by architecture. Time will tell if this will actually work

Time and time again I come across the question and related issues of how does Agile deal with NFR's ( or Non Functional Requirements ). Those requirements which are often impossible to capture as stories. I have seen some teams ( and even tried my self early on ) to write stories such as As a <> I want all data stored in an Oracle Database, or As a business owner, I want the system to support 10,000 current users. While these capture the intent, because they cannot be assigned to a single iteration they can easily become forgotten about, or just overlooked in the white heat of iterative development.

I've become increasingly in favour of the use of architecture governance where by there is a specific role defined within the team who owns NFRs, and is responsible to ensure that they are adhered to within each story. The best solution I've found is that the Architect responsible for NFRs have an responsibility to ensure that each story is reviewed at some point with a view of the NFRs and the specific requirements are then capture as Acceptance tests on the story. Any story with data can state a critieria demanding Oracle, any story with UI can refer to usability tests

Issues with this approach

1) Large agile teams may require more than one named architecture resource
2) Small agile teams may have this as a part time basis
3) Inexperienced architects may apply all NFRs to all Stories to "cover their backs"

Roger Leaton, an Agile Advocate at BT has written an article How BT learnt to be Agile about how over the past 3 years BT has been agilising 14,000 IT staff, impacting over 80,000 people. Proof, if needed, that Agile can and does scale and the benefits realised.

Through one of my clients, I have been invovled in some of the work at BT and I can tell from first hand experience that Agile adoption within has not been easy, with many obstacles invovled, but many have been overcome little by little and the frustrations of the early adoptors is now turning to real enjoyment and improvement. Well done to all involved.

VersionOne have just publisshed the 3rd Annual "State of Agile Development" Survey, key highlights

Teams practicing Agile Development are getting larger and more distributed.

o 32% of respondents are from development groups with over 250 people
o 76% of respondents are from development groups with over 20 people

Agile development is delivering meaningful and measurable business results.
Respondents reporting specific improvements greater than 10% include:

o Increased Productivity – 89% of respondents
o Reduced Software Defects – 84% of respondents
o Accelerated Time-to-Market – 82% of respondents
o Reduced Cost – 66% of respondents

If you involved in Agile, specifically trying to sell Agile to customers who need hard facts then this is an excellent start