Overcoming Impediments to Test-Driven Development

Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis.

This is the first of several posts about how a team can be Agile while using Visual Studio Team System to manage their project and process.

This blog is somewhat of a response to a comment on my JIT posting.

I really like The Goal and think the Theory of Constraints (TOC) is brilliant.   I believe it can be applied to software development in two ways.  One is very valuable and the other must be dealt with with great care.  First, the one to be careful.

I have been involved in several threads on more than one user group in trying to differentiate between what I view as Agile practices without the benefit of understanding Lean and what we do at Net Objectives where Lean both creates the context for and provides guidance to our Scrum practices. For some reason, these “conversations” have typically stirred heated debate, sometimes even personal attacks and once culminated in my getting thrown off a popular discussion group.  I thought I’d try to discuss why I talk about what we do the way I do.

This blog entry describes how a solid understanding of Just-In-Time (JIT) can give great insights into the differences between Waterfall and Agile methods.  I want to acknowledge the Poppendieck’s work for giving me the insights I am sharing today. Any failings, are mine, however. I highly recommend their latest Implementing Lean Software Development: From Concept to Cash.  It incorporates not only their earlier Lean Software Development Principles, but also the thoughts of Taichi Ohno and Womack and Jones – two consistent, but different ways of looking at what Lean is. 

Hi all.  I’m on “vacation” in San Diego this week.  I’m kind of splitting time between vacation, reflecting on business and writing my Lean-Agile Anti-Patterns book. Today,  I wanted to discuss the difference between what I think are normal Scrum practices and what could be called “Lean-Scrum”, or what we, at Net Objectives, call Lean-Agile. I hope to write a blog entry each day of this week, so please stay tuned.

Post-Agile Scrum (audio of the webinar)

The Agile Manifesto and the Agile movement have ushered in a new way of developing software. Today, many practitioners are discovering limitations to the usual approach to Agile which focuses mostly on local teams and projects. This limited focus developed as a reaction to heavy processes and teams' inability to make their own commitments. This resulted in many leading Agile practitioners to advocate an approach to "let the team figure it out," going so far as to state that the beauty of the Agile approach (such as Scrum) is that it avoids any kind of prescriptive formula. Yes, prescriptive formulas can be dangerous; however, having a set of principles to guide Agile practices can be extremely useful. Moreover, incorporating Lean management practices are critical for extending the capabilities of an organization using Agile methods.

Today, what is required is helping the entire enterprise become Agile. What is an Agile enterprise? An enterprise that can respond quickly to customer, environment and internal changes to create a competitive advantage. This requires much more than merely trying to apply practices that work for local teams to the entire enterprise - that approach is too simplistic. This Agile Enterprise-perspective is one of the biggest differences between current Agile practitioners and those going beyond Scrum.

These and other questions are pondered by Alan Shalloway in a webinar on Post-Agile Scrum, presented January 24, 2008. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However,  read more »

I recently completed the process of getting a book published ("Emergent Design"). It was my first time doing this, and I thought it might be valuable to some of you if I shared some of the things I learned about writing a book, and about the publishing world.

 Scrum and Management: Planning and Focusing

Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face.

There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve.

This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development.

In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus.  read more »

Emergent Design (audio of the webinar)

What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development.