Working with agile teams I see a common underlying issue emerge time and again: Keeping the big picture in mind. Here are some examples:
- Agile looks to emergent architecture – its illogical to define architectural design at the beginning of a project if you accept that the requirements (business and technical) cannot be determined reliably up front. Attempts to do this usually lead to over-specification – to avoid any constraints emerging due to the architecture we tend to engineer a highly complex solution to cater for all eventualities. Agile has a notion of emergent design – because software is ‘ soft’ we can change it (eg refactoring) – we don’t have to get it ‘ right first time’ like in the construction industry where the architecture metaphor came from. Although there is a cost in reworking architecture as we go along, there is also a saving in getting it right, in not over-specifying it, etc. But agile doesn’t call for no architectural design (as Christopher Alexander – creator of the design pattern concept, puts it: “good design requires keeping the big picture in mind”). Instead, agile looks to late elaboration, keeping our options open as long as possible, and allowing us learn as the project progresses. Remember, we know least about the project at the beginning – so why lock in our architecture prematurely? Perhaps the term ‘ architecture’ has outlived its usefulness….
- Agile expresses requirements as small fragments – user stories are the common basis for expressing requirements in agile projects. But user stories are explicitly independant, small, specific (see Bill Wakes INVEST criteria for effective user stories). Other approaches to Agile/Lean requirements are Minimum Marketable Features (MMFs), Minimum Valuable Features (MVFs) and Business Value Increment (BVI). All these are attempts to delineate a “manageable” slice of functionality to be delivered in a short cycle time which will deliver value to the customer. But how these small units of functionality link to the bigger picture can get lost. How does my story contribute to this epic, or theme, or goal? Jeff Patton proposes the User Story Map as a mechanism to tie stories to the bigger picture. Another approach is to ensure stories are derived from the bigger picture – epics, themes – rather than being defined first and then grouped into larger areas of functionality.
- Agile doesn’t make it easy to scale to big projects – methods like Scrum and XP are specified at the small team level – its hard to scale to big enterprise projects (though there are more and more success stories emerging). Small teams working on a sub-set of a big project can lose sight of the big picture. Whats often forgotten here is that scaling problems are not specific to agile – no method makes it easy to scale system development. While traditional methods address scaling by freezing design early and relying on documents to communicate details between teams (both techniques rife with problems), agile relies on face to face communication (eg in a scrum of scrums) and continuous integration/automated test (where the code for the entire system is built, deployed and tested many times a day). From my experience, the agile approach holds far more promise, especially where the extent and rate of churn is increasing, and the ability to rapidly deliver of software is becoming a strategic capability.
In summary, focusing on the small bits (as agile does) does not mean losing sight of the big picture. This is not an either/or situation. We can work incrementally while keeping an eye on the big picture.