Set-Based Design and Effective Risk Management

Set-based design is an empirical approach where a problem space is explored simultaneously through the investigation of various solutions so that the most optimal solution can be chosen at the last moment that the decision needs to be made.

There are a few benefits to this:

1. The longer that you can put off make a decision, the more informed the decision will be. Of course, you cannot procrastinate. It is important to first decide when you must absolutely make the decision.
2. You generate a better understanding of the problem space by tackling it from different angles.
3. By investigating multiple solutions to a problem in parallel, you are more likely to have something functional and ready to deliver in the end. This is effective risk management.

When is it appropriate to exercise set-based design? When you have an irreversible decision to make or when you are facing a deadline which cannot be missed.

Some may consider this as a wasteful practice. Why invest so many resources in solving a particularly problem. However, in most cases the cost of missing a deadline or making an ill-informed decision is significantly higher. Even then, this may be difficult for some people to grasp when they are deep into the task at hand. When this happens, step back and consider the long term goals of the company and the product being development. I bet you will find the investment will be worth it.

You may come across customers who are hesitant to compromise on scope even when a deadline is set in stone and it is pretty clear to you that the current scope is not achievable by that deadline. Instead of running for the hills as some have suggested, consider set-based design. More often than not, the budget is there for it since the organization is more than willing to bring in as many people as it takes to get the job done. It could just be what is needed to get the customer to identify what feature-set is absolutely required to get the product to market.

To learn more about set-based design, have a look at the following resources:

• Bill Wake's Xploration on Set-Based Concurrent Engineering.
• Implementing Lean Software Development, From Concept To Cash by Mary and Tom Poppendieck.

Mylar...Why should you get it?

The Mylar plug-in allows you to associate a context of work with a particular eclipse task. What does this mean? Well, after 'activating' a task for the first time, you are provided with a clean slate view in terms of classes, configuration files, etc... in your project. As you begin to navigate the code-base while working the task, the classes and methods you interact with become part of the task's context. The benefit of this is that it reduces 'conceptual overload', therefore, making you more productive. The best way to understand this is to see it in action. On top of that, this 'external navigational memory' is constantly changing based on your code interactions. The context adapts to your current code usage pattern as you are working the task.

The task context can even be shared between developers on the team and associated with various issue tracking solutions (Bugzilla, Trac, Jira). I have yet to try this since my current project does not use the supported issue tracking implementations, but it seems very cool.

I have to admit it, I have been putting off installing this plug-in for some time and I regret that. I think it is one of those things that you need to experience to fully appreciate. If you do any development with Eclipse, get Mylar now!

I just wanted to let folks now that I will be blogging all future XNA-related content to my new blog XNA Zen Garden. Pop on over and you'll find it's inaugural post on C# partial classes.


I moved my previous XNA-related posts to the new blog as well.

But it works...Isn't that good enough?

Well, it depends. However, more often than not the answer is no, it is not good enough.

Imagine your working on implementing a 'fix' for a 'show stopper' issue under an 'aggressive' dead line. I bet this does not sound too far fetched?

I would bet that you are not particularly comfortable cranking out a quick work around solution, yet I am sure that you find the quick fix so damn tempting.

Why is that? For one thing, the client probably wants this issue fixed yesterday! Deep down, they may not care how it is done. The bottom line is the sooner the better. Of course, doing it right is implicitly assumed but, this is usually sacrificed in the spirit of the Now. In fact, we are often rewarded for getting things out fast. Perhaps there are financial incentives for getting things done on schedule? In my opinion any sort of incentive tied to a schedule is a smell indicating that the schedule is just not right.

My colleague Dmitri Dolguikh recently pointed me to a great article concerning how costly quick fixes can be. I found the last two paragraphs particularly interesting:

It comes down to a matter of professional ethics. Software developers are often disparaged for being sloppy, slow, and unreliable. Whole IT departments and product develoment teams carry the weight of appearing incompetent and moribund. Why? Because they succumbed to the seductive idea that quick and dirty solutions are faster in the short term.

True professionals don't work that way. True professionals keep their code clean at all times. True professionals write unit tests that cover close to 100% of their code. True professionals know their code works, and know it can be maintained. True professionals are quick and clean.

I whole-heartedly agree with this, however, the reality is that being a true professional is not easy and, depending on the environment, may not be realistic 100% of the time. There are too many opportunities lying in wait to distract us from this ideal. In my view, a true professional is analogous to the notion of a responsible developer. To quote a recent post by Kent Beck on the XP mailing list:

I try to do an excellent technical job but I also work to make sure that what I am doing fits into the larger business...If the technical concerns and the business concerns appear to conflict, I work to find a mutually beneficial solution but finally I follow business imperatives over technical ones.

We work within the constraints of our current environment. Although the true professional definition as put forth by Bob should be an ideal that we continuously strive for, it may not always be achievable. In those cases, does that make you less responsible or professional? I don't think so.

We cannot solve all the problems of an organization, but we can do our best to help steer them in the right direction. Sometimes this requires a compromise.

Rules of Engagement

Effective communication is not spontaneous in nature, it takes commitment from all contributors.

So, you have set aside time for reflection. Now what? How do you proceed? To a degree this depends on the situation, however there are some general principles that can prove beneficial. The key is to explicitly establish rules of engagement that maintain trust across all contributors so that they can add effectively to the pool of shared meaning while maintaining focus on the overall goal in order to generate actionable results.

Goal

Before beginning any dialogue, it is important that a goal is put forth that is accepted by all contributors. This formally establishes the problem space that people will be thinking within. It also helps the group maintain focus.

For example, If one of your teams main problems is quality, start the discussion by stating that the purpose of the dialogue is to discuss the quality issue and how quality can be improved. In this particular case, blame has no place in the discussion and this should be made explicitly clear when the goal is communicated.

Safety and the Pool of Shared Meaning

During the discussion it is critical to maintain safety within the group. If people do not feel safe, they will not contribute effectively to the conversation which means the pool of shared meaning will not be as full as it could be. There are a couple of implications of this. Firstly, detail is lost because the entire group is not sharing their opinions. Secondly, and more importantly, Those who do not contribute because of safety issues are less likely to be bought in to any decisions that come out of the discussion. This could lead to the second-guessing of decisions and become an obstacle to improvement.

When is safety likely to be an issue? Any dialogue that can be classified as a crucial conversation where stakes are high, there is a difference of opinion and emotions are involved. The safety issue can be further exacerbated when one of the contributors has a strong, aggressive personality.

Actionable Results

Finally, we want to come out of the discussion with actionable items. If not, any feedback that led to the discussion is not feedback but noise. This is a critical concept that has been stated before:

Feedback without action = noise.

In the end, if the purpose of the discussion is to institute change that will hopefully lead to improvements, then action must be taken. Talking about it is only half the work.

In Conclusion

As I stated at the beginning of this post, effective communication is hard and takes work. I have been reminded of this many times over throughout my career and I have found these principles to be effective. In a future post, I will bring up some of the practices that can be used to support these principles.

If you are interested in becoming a more effective communicator, I highly recommend the book Crucial Conversations. I have found it to be an invaluable resource and it was a major influence of this post.

The Importance of Reflection

Agile, iterative development. It is a mixture of planning, pragmatism and a healthy dose of common-sense. Simple! Or so it seems...

One important aspect that seems to be ignored all too often is the importance of reflection.

Unfortunately, looming deadlines always seem to distract us from this important activity. Paradoxically, this is the time I have found we need it the most. Heads-down programming with little communication is unproductive and a sure sign of an inexperienced team.

Where do you start? How do you do it? In my opinion, the beginning of the iteration, during an iteration, and at the end of an iteration. Each point requires a different focus and level of formalism, however, the end goal is the same: we want a small set of actionable items to come out of the discussion.

A small investment of time prior to iteration planning goes a long way towards making significant progress. Look at the release plan and see what stories are coming up. Discuss these stories briefly with a teammate. Come to the planning meeting prepared. All too often this does not happen, usually due to the 'lack of time'. This is unfortunate because nothing makes team members more frustrated than a poor iteration transition.

Frequent informal discussions concerning the state of the story board allows team members to assess the health of the iteration. Use the story board as a conversation starter with your teammates. Ask them how their work is going, what they think of story X not being started at this point of the iteration. Sometimes, emergency action is required... Better to find out sooner rather than later.

Well planned and facilitated end-of-iteration retrospectives go a long way towards discovering the tweaks that need to be made to allow the team to work more effectively together. The key is to identify a small number of 'improvement opportunities' that can be addressed during the next iteration. The results of these tweaks are analyzed in the following retrospective in order to assess their impact.

It is clear to me that small investments of time reflecting on feedback throughout product development go a long way towards delivering a product that meets expectations. The first step is to realize this as a collective team so that the time can be made to do it.

Under construction. Please excuse my humble beginnings... Come back soon!