Showing posts with label challenge. Show all posts

Design sessions: why and how?

A design session is used to focus on one or more design items to achieve business objectives with a group of designers. This technique could radically improve the dynamic of your team and the outcome of your project. The technique is best used when you have a three or more talented developers. 




10 reasons to conduct design sessions 


 1. Keep the team engaged and motivated
 2. Tap into the creative potential of the team
 3. Bring the team together on a decision with a common understanding
 4. Separate the designer from the design. You are not your design
 5. See with new eyes
 6. Learn from each other
 7. Close gaps (reduce distance between team members)
 8. Keep it simple
 9. Improve and simplify your process
 10. You think that you know it all


How to conduct and structure effective design sessions?














Here is an effective way to conduct and structure design sessions for your team.

How to Conduct a Design Session
A design session usually consists of two to three design items to help reduce time and consolidate our moves. A design item typically takes about 15 - 20 minutes. A design session should separate the “what we want” from the “how we want to do it.” It provides a venue to consider alternative solutions that could be simpler, clearer, easier, more secure, and more extensible.

Session Goals
The goals for the design sessions are to be…

    Healthy
        Encourage and allow others to contribute

        Be respectful

        Make your point

    Efficient
        We need to quickly understand, justify, and agree on an approach (the how)

    Interesting (not boring)
        Innovative solutions are a side-effect

What’s in it for you?

    Your idea gets used in an area that makes a difference

    Learn from others

    Gain a common understanding

    Have fun 

Attendance
Attendance is optional. There are probably a few different reasons to join a particular design session:
  
    You are passionate about it

    It directly impacts your work

    You are interesting in learning more about a particular area


Design Item Template


 Description: {Describe the problem statement}
 Alternatives: {List out alternatives provided by team with pros and cons}
 The Action, Next Steps (such as a spike solution), or Decision
 Rationale:  (A is important, so we chose B, accepting downside C): {There is always a downside; no decision is perfect}


Challenge Questions



Can this be deferred?

Is this the right item to consider?

Is there a way to simplify the problem/solution?

Does the item imply the what we want to do?

Does this help us deliver on-time?

This same format can also be used for process items.

Closing


The results of these sessions should be kept in a journal. The journal can be quite helpful to review decisions and to stop history from being rewritten. I have used this technique with bigger teams  including the redesign of www.bmwusa.com. The journal should be comprised of notes for each design item (design item template) and the overall structure described above.

Often, you will still need to make a decision to resolve a team deadlock, but by using the design session technique, there will be fewer deadlocks and members will be able to accept and follow the direction.

These sessions can be fun and effective. Team members want more of them. One key to success is to have the following team values: respect, collaboration, communication, and simplicity.

I would like to know what works for you. Is your team engaged or zoned out?

Enjoy.

The most difficult problem in software development


Is design the most difficult problem in software development? Writing code?

Not really. Designing and writing code can be the easiest part of software development—assuming you are (or hire) a competent developer.

The real challenge of software development is integration. That is, integrating services, interfaces, and components. It involves communication, collaboration, coordination, and continuous effort.

When an integration problem is discovered, it can create doubt, undermine confidence, divide the team, and halt progress.

Integration problems are a like a cancer to a project. And like a cancer, waiting too long to discover the problem can be detrimental.

There are so many different kinds of integration problems. The simplest type of integration problem is a compilation error whether due to a change to the dependent or using assembly. Other types include a change to an interface, simple refactoring, or semantic misunderstanding. There are so many other types, but perhaps the worst type of all is the total misunderstanding of need or responsibility. "I thought you were doing it. No, I thought that was going to be done in version 2.1."

Even if we dismiss the fact that integration problems can undermine confidence, divide the team, and create gaps, the unavoidable impact is that it halts progress. The development velocity of a team can go to zero until the problem is resolved. This can involve stepping back through commits to code to find who, when, and where the problem was introduced. Even understanding the "what" of an problem can be difficult.  It sucks. It is painful. And can take a very long time.

Next, I will provide you with a few tips to avoid integration problems. In the meantime, let me know what you think. I also need help making a list of integration problem types.