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.

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.

What is design? When do you do it? How much to you do? And how do you begin?  

As teachers of Design Patterns and TDD, David Bernstein and I are often asking these questions. Invariably, we include the notion that one engages in "design" (not necessarily up front design, mind you) as a way to mitigate risk, among other things.

But which risks? Can you mitigate all risks? Do you even know all the risks that you might need to address in design? In most cases, the answer is almost certainly "No."

In my earlier post I mentioned these. OK, I know it was a tease, but now that someone has asked for what they are I figured I’d better fess up.

Alan Shalloway has started a regular series of webinars on Lean and Agile topics. The recordings of these webinars are available to registered users of the www.netobjectives.com website in the Resources Page for 30-days and to students and customers after that.

Here are some webinar recordings on these topics:

I have been doing Scrum for well over 7 years. I like Scrum, I am one of its strongest proponents. In fact, my company, Net Objectives, is one of the largest Scrum companies in the country in terms of the number of people we have trained and coached in Scrum-related activities. Yet, I am amazed at how many Scrum trainers/coaches/practitioners continue to miss the point of leadership and management in software development.

Patterns give devs a language for collaboration

Lean-Agile puts a premium on collaboration. We always talk about increasing the bandwidth of communication: between customer and developer, between members of a development team, between your team and other teams, and, indeed, between various generations of a team (why did they do it that way?) Gone are the day of a programmer sitting alone in cubicle; most developers find themselves as part of a team.  read more »

Embrace Change through Patterns

Perhaps one of the benefits of Agile is that you can get frequent, almost constant validation of what we are doing. In waterfall approaches, it too often happens that after a Plan-Do-Review cycle, the review results in bad news: something is wrong. Now, we have to go back and re-work a bunch of stuff. That is wasted effort.  read more »

Patterns and Lean-Agile

In other podcasts, we have talked about the “Three Legs of Software Development”: management processes, developer processes, and technical skills. “Technical skills” involves both Design Patterns and Test-Driven Development.

But are design patterns still relevant? Or is that so 1990’s?

The answer is “Patterns are more relevant now than they ever have been… and especially for Lean-Agile software development." Why?  read more »

The Product Development Team and the Voice of the Customer

If there is one thing that was drilled into my head in my Lean Six Sigma training, it was the ultimate importance of the Voice of the Customer. If this was important for manufacturing and service efforts, it is even more so for software development. We cannot provide good value to customers without knowing what it is that customers want or need. And if we aren’t providing good value, why do the work?  read more »