Posted in Scrum on December 10, 2009 by Andreas Wintersteiger
I've had a talk about evolving architecture and Scrum two weeks ago for the Jahooda Platform and we really had some interesting discussion points. My presentation (slides here) besides Scrum in a Nutshell was about how architecture is handled in Scrum - a typical FAQ.
In my point of view, architectural granularity is a spectrum starting with Architectural Styles, defining the overall style of an application architecture, such as layered/n-tier, message passing, store & forward, pipes & filters, finite state machine, peer to peer, service oriented, etc. They comprise a set of ground-breaking decisions, in many cases to be done by management, product management or CTO-level. On the other side of the spectrum there is the fine grained design of objects and their interactions. In the mid we often find Enterprise Design Patterns and a bit towards this end the GOF design patterns.
Functional requirements have impact on architectural decissions on a high level, so top-level requirements should be known upfront while detailed requirements drive more the detailed design. Non-functional requirements may have an impact on high level design (such as performance, extensibility, availability). They also imply risks - that's why we want to know them early (agile principle: fail fast). Architecture represents an asset value for the company with a focus on the long term (stability of the system, extensibility) and has two major implications: User Interface (Raskin) and Organization (Conway) - both known well to Scrum trained people. The architect in many companies is a stakeholder, not seldomly sitting in the ivory tower - but without power ... both is wrong in my opinion.
Evolution is the best Architect. Evolutionary design is the kind of design that survived (evolutionary) ... Think of nature, plants, animals, the human body... with some (for agilists well known) principles: early and continuous feedback, allowance for failure, inspection and adaption (well this is the hard part in mother nature, survival of the fittest). Back to software, when was the last time you did see an architecture (in very detail) drawn on the board by an architect, that actually came into being as orignally designed? Reconsider the principles above...
The fear of not knowing enough is an omnipresent pattern in all kind of organizations. The host of this particular workshop, where I gave this talk was a company best known for it's 40 year history of building microprocessor controlled concrete mixers for the construction industry. I was fascinated by viewing a rack of about 42U high, full of hand-wired electronic boards from the 70's - and asked, what if the company founder did not have the courage of releasing this by-then-high-tech-wonderthing despite not knowing what the future will bring... Maybe as Jim Coplien has put it "Architecture is not living in a document - it is living in code otherwise it would be a beautiful piece of fiction." - as he says, architecture embodies the critical design decissions that typify a system, the significance of decissions needs to be understood and assessed. In his QCon talk he points out the real thing about architecture and agile: "The significance of decisions need to be reduced, the key decissions reduce significance of other decisions. Doing the hard ones first make the easier ones easier, doing the easy ones first make the hard ones harder." - that's exactly what we need to understand.
What about the finer grained architecture? How do we cope with this? In my view it's incremental design, which is so often misunderstood. In an agile manner we focus on the right level of detail in the right time: Architectural Styles and Design Patterns set the frame for the most. We use architectural spikes to do r&d work on really unknown topics and we develop the architecture incrementally with short feedback cycles to see what works and what not.
The key is to accomplish this is to keep the code easily changeable, that is Clean Code. Btw., there's a really nice book on this by Uncle Bob Robert C. Martin. We need code that is easily readable and easy to understand, has no redundancies and is loosely coupled. Code that is easily testable and secured by a fine mesh of automated tests. We stop anticipating future unknown requirements, we start with a rough design and refine further on and we maintain a changeable, clean code. And we use test driven design to focus on the details.
Ah, finally - what I wanted to say: Architects do code and are part of the daily game - in Scrum: team members!
Inhaltlich lagen wir da mit unserem Training “Agile Development Practices 101”, das wir seit mehr als drei Jahren anbieten genau richtig - es geht um die Praktiken in der agilen Softwareentwicklung, wie Test-Driven Development, Continuous Integration etc.
Posted in Misc on January 17, 2010 by Andreas Wintersteiger
The teams I work with claim to do Scrum, but they do not practice solid software engineering based on by now 10+ year old best practices. Are you still wondering, why DONE is such a hard thing when you even don't know. Although Scrum does not impose any development practices there is a strong claim, you all know: Potentially shippable - that is working - software in highest possible quality at the end of the sprint! There is a direct relationship between teams that are potentially shippable at the end of a sprint and their engineering practices in place.
