There are many sides to agile development, but it is all too common to focus on only one or two, depending on personal interests, job role, background, etc. A manager may focus on organizational and process aspects to the exclusion of technical ones, whereas a developer may have a complementary view. Different developers may focus on different details to the exclusion of others: one developer may value emphasis on a loosely coupled architecture but be less concerned by testing, whereas another may view agility solely in terms of unit tests and task automation. Each perspective is valid, but missing the other perspectives means missing the whole picture.
This talk focuses on six sides of agility, which notionally form the faces of a cube, and how they trade off against one another in different situations. Practices, organisation, architecture, tools, skills and attitude: each of these has different consequences and different
applicability depending on the context. For example, if a skilled team of developers wishes to adopt a more agile approach in a legacy project without tests, they are better off in the short term avoiding TDD and unit test coverage, and instead focusing on other matters of practice, tooling and architecture. By contrast, an unskilled team on a new
project are often well served by adopting a TDD approach early and forming a clear understanding of the architecture they are working in and on.
Kevlin Henney is an independent consultant and trainer based in the UK. He specializes in programming languages and techniques, OO design, patterns, software architecture and agile development. Kevlin has been a columnist and contributor for various magazines, including Application Development Advisor, Java Report and JavaSpektrum, and is currently columnist for Reg Developer, the developer channel of The Register. He is also coauthor of two forthcoming volumes in the Pattern-Oriented Software Architecture series.
The Software Factory— The term software factory is controversial. But think about it... No industry has experienced more innovation than the factory industries. On the contrary, the key to meeting demand is to stop wasting talents of skilled developers on rote and menial tasks...
Evolving Agile— We are now facing critical issues which until now many within the agile community have preferred to avoid talking about. Activities such as modeling, documentation, exploratory testing, and database development must become more explicit within our methodologies. We need to find ways to fit into IT governance frameworks, process maturity frameworks, and regulatory guidelines.
SOA methodolology— A major complaint in IT and business organizations is that they don't have a common basis from which to have discussions. One talks technology and the other talks financials and goals, in between lies a lot of confusion. In 2005, Capgemini contributed a business centric SOA methodology to OASIS in the hope of fostering a movement away from technical SOA towards business centric SOA, and it remains the only publicly available SOA methodology in that space. This presentation covers that methodology, how to apply it to businesses, how to use it to better understand where technology investment should be made, but most importantly to understand how the business operates and IT's role in helping the business achieve its goals.
Enough Process, let's do some practices— The world of software development is constantly changing and evolving. New ideas arise all the time and existing ideas go in and out of fashion. Software development processes find it very hard to keep up with this rapid rate of change, especially as they find themselves quickly going of fashion or becoming bloated as they bolt on more and more information. Teams find themselves struggling as they try to mix-and-match practices from various sources into a coherent way-of-working or work out where to start their improvements.
The Truck Driving Problem— Imagine that you are responsible for driving a truck across America, along highways, through cities and around detours, dealing with whatever idiosyncrasies that weather and traffic might throw at you. Now imagine that your job is not to drive the truck, but program a computer to drive the truck for you. How would you go about turning over everything you know about driving to computer?
