From Months to Minutes - Upping the Stakes
Dan North reviews many Agile practices and concepts, mentioning what has really made the difference over the years and what has not, outlining what helps high performing teams to do their job.
Dan North reviews many Agile practices and concepts, mentioning what has really made the difference over the years and what has not, outlining what helps high performing teams to do their job.

Organizations often introduce Best Practices as part of a change program or quality initiative. These can take a number of forms, from cheat sheets to full-blown consultant-led methodologies, complete with the requisite auditing and accreditation. In this article, Dan North shows how best practices can not only fail to help, but even have a severe negative impact on your top performers.
Dan North considers that ignorance is the major roadblock on the way to success, presenting strategies and techniques for reducing it, delivering software in a more deterministic and less riskier way.
Dan North argues that Agile best practices can help an organization only to a point, and continuing to rigidly apply them after that will stifle innovation and drive people away. Organizations need to continue to innovate, finding new ways and practices to develop software by looking at the motivations behind Agile practices and not just implementing them.
Dan North talks about the tendency developers-becoming-architects have to create bigger and more complex systems. Without trying to be simplistic, North argues for simplicity, offering strategies to extract the simple essence from complex situations.
Dan North advices programmers on how to advance from beginner to expert: practice the basics, learn from others, understand trends, share knowledge, maintain the toolbox, learn how to learn, and start all over again.

Domain Driven Design (DDD) is about evolving a shared model of the domain letting the domain model drive the design. BDD is about establishing a shared understanding of “done” working from the outside in until you get there. DDD enables the use of BDD effectively creating software and BDD helps structure the conversations for DDD.

Dan North discusses an example of rearchitecting an application without rewriting it from scratch, and explains general strategies for a holistic rearchitecture such as changing the team culture, removing obsolete technologies, allowing mistakes to be made (and learned from), transitional architectures, introducing bounded contexts, refactoring and emergent simplicity, and rotating through roles.

Dan North discusses the roots of BDD and what it is today. Dan reviews the early history of BDD and then dives into the details of BDD; what it is, how it relates to teamwork, functional and non-functional requirements, and legacy code.