Moving on from Scrum – Disciplined Agile Delivery
I recently picked up a copy of Disciplined Agile Delivery (DAD). DAD is a hybrid approach that extends Scrum with proven strategies from Agile Modeling (AM). Anyone who has used Scrum on large enterprise projects will know what Scrum/XP doesn’t assist in the modeling, documentation and governance arena. Page 4 offers a simple diagram showing the differences of Agile Development, Agile Delivery and Agility@Scale.
Over the years I’ve heard various debates about how much intellectual work can be done in a working day. Page 31 offers a view that 5-6hrs a day is the norm for achieving high-quality intellectual work. Often overlooked, “Visualize Workflow” often aids teams in understanding blockers, and utilization.
Chapter 4 provide insight into roles, rights and responsibilities which marries back to the Terminology Tar Pit on page 43. Roles and responsibilities are often overlooked on the forming of a new team, with the implicit expectation that people will know what role they need to fill based on history. Architecture Owner, page 76, should provide some clarity in an often contentious title.
If you happen to be on a a graphically split team, then DAD may not be the best approach to follow – page 4/87. Page 99 offers some further thoughts to geographically distributed/dispersed teams.
Funding, always and interesting project area, is discussed on page 126, coupled with some views on estimating.
Have to agree with the “Just do it” comment on page 133 – Jumping into Construction. A classic anti-pattern which is sure to guarantee the wrong architecture, poor quality of code, amongst other issues.
Choosing the right type of model is often not thought though on a new project. Specifically because old patterns and methods and followed without new thinking. Page 155 compares a number of modeling options. UI specifications have become almost a norm in recent years with the influence of User Experience though process on projects, however UML and flow charts still have their place.
An often debated subject is choosing a strategy for Non-functional Requirements (NFRs). Page 170 offers three basic strategies. I agree with the advice on page 171, acceptance criteria.
Good list of architectural modeling views in table 9.2, page 184. Hopefully, the project you are on doesn’t follow the no modelling view (page 180)
Often debated by the stakeholders funding of a project, estimation is unfortunately contentious. Hopefully page 218 can provide some assistance.
Construction phase and iteration overview diagram on page 281 offers a great view of what should be done, and also what is often missed 😦 Patterns and anti-patterns offer a great read as well (284). How many times have you see people spread over more than one project in a week – “task-switching between projects takes time and is a huge source of waste” (page 285)
Page 310 should hopefully offer the construction crew ideas around leveraging their working day. Of particular note is the “stabilize build” – how many times have you see the build broken as people leave the office at the end of the day? 😦
Transition anti-patterns (page 429). How many times have you started a project, and even after 3+mths, you still don’t have a production like environment for integration, acceptance and deployment testing (anti-pattern 101)
Potential metrics for agile projects (page 469) includes the usual suspects, but also offers a few that are often not captured – e.g. agile of work item.
Great to see Continuous Delivery (CD), BDD, TDD and ATDD mentioned throughout the book.
Final food for thought:
- Stop the rush into construction. Model
- Prove the architecture early
- Read the book 🙂
Tales from a Trading Desk 
Do you mean to say a _geographically_ split team? (I imagine that a _graphically_ split team would be a very interesting phenomenon, at least to look at).