Jim Coplien on Scrum Architecture: Jim started by highlighting that use cases describe what a system does and architecture represents what that system is. A common problem on Agile projects is that a lot of teams become unstuck during the third sprint because there is no architecture. After all, architecture is what enables developers to work together. Jim therefore recommended we assert what we know on an architecture in order to provide a high level design, taking no more than three days, made up of abstract base classes and domain dictionaries (two sides of A4 per domain). Jim went on to say that TDD (Test-Driven Development) does not produce (good) architectures. That architectures cannot be derived from unit tests. That we should adopt architecture-driven design instead of unit-test-case-driven design. The session hit the sweet spot as a technical Agile session: suitably thought-provoking or controversial depending on how you interpreted his presentation.

A design that fulfills all functional requirements but fails to meet non-functional ones is not a valid design. Architecture-driven design offers a mature approach to design because it explicitly considers non-functional requirements from the beginning, and not just immediate requirements such as size and performance, but also easy of maintenance, accomodation of projected changes, understandability and so on.

Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (pdf). Computer36 (6): pp 47–56. doi:10.1109/MC.2003.1204375. http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf.

About Me

Software Developer with 17 years experience as senior developer and tech lead in many large and small agile teams. I enjoy consulting with teams to implement improvements in development, testing, and devops practices leading to higher-quality software. I've experienced many of the pros and cons of Agile/Scrum/XP/DevOps and I'm always looking for continuous improvement in both team efficiency and personal skill. I believe the world needs more well-rounded developers, capable of seeing themselves in the bigger picture, able to quickly spot bottlenecks in the delivery pipeline - whether it be in Dev, QA, or Ops - and work with a sense of urgency to fix them with cutting-edge technical ability while using well-honed interpersonal skills to help improve the culture around them. Passionate about giving back to the community, I co-organise the DevOps Brisbane Meetup group and help run study groups for professional software developers on topics such as AWS Solutions Architect Certification, Continuous Delivery, Functional Programming, NoSQL & Distributed Systems, and enjoy inspiring IT professionals to sharpen their craft through professional development and group learning.