Edge of Chaos

2 weeks ago we made a large roadmap poster out of four A2 sheets of paper and put it up on the wall in a highly popular place, that is kitchen. The poster shows 2 years in a row:

You can see  initiatives (or epics) rows. Red line is for an epic start date, green line marks release date. Yellow lines show previous and future expectations about releases, but since we are not estimating stories, these are just expectations. Blue line indicates beta-release. Stories and features are represented by yellow sticky notes inside each initiative. The current day is marked by a thread with a marker attached (yes, we utilize gravity force). Future initiatives are marked with large orange sticky notes.

Here is a quick overview of 2010. We completed only 2 major epics and started 3 more that are still in progress.

Currently we are working on Plugins (this epic  has been in production for almost 9 months already) and new Views (the current “in progress” time is 6 months). As you see, we expected to release new Views in April initially, but full JS architecture redesign changed the plans. Quick Add UX activities will be started soon.

Finally, an overview photo:

Mastery by George Leonard is one of my most-cherished-books-of-all-times. I’ve seen this book mentioned on a tennis web-site, and not even once, as I’ve been digging the web for some nuggets of information on what in the world do people do to make their game perfect and enjoy it. Ironically, now I can see that these 2 searches are absolutely irrelevant.

I wouldn’t say that this book has unveiled some unknown truths. It gently reminds of the basics for any learning making readers aware that the mass culture quest for scoring, quick wins and quick fixes at any rate proves wrong in the long run and brings along the consequences more grave than one can imagine.

Calm face and full concentration. Check large size

There’re some important conclusions I have made for myself out of this book, to name a few:

Mastery is Enjoying

The first and most prerequisite for practicing any art or hobby or job is that you got to enjoy it. Love doing it. Not reading about it, not writing about, not showing off before others, not thinking about the competition. George Leonard cites various examples of this sustained desire to just enjoy it, for example: Aikido black belts are never bored to practice simple moves finding newer and newer shades in what they do, going into focused trance, whereas boredom and hasty search for more tips and tricks are characteristic of shallow students looking to feed their vanity on the rich texture of any given sport or art.

Craftsmanship movement in software development tries to apply similar practices via coding dojo and katas. It is not clear whether this direct transition is good enough, but it definitely looks interesting.

Mastery is Unrewarding

Mastery is an unrewarding process. It’s not about getting 100% results.  It’s about following this path. Master is the one who deliberately takes on the fool’s mask, like court jesters. The point is that if you think of yourself as an expert in any given field — you’re full. There’s no more room for novelty. So, you’ve got to pour out of this glass of attained expertise to keep fit as an agile apprentice. The luggage of expertise steals the ability to enjoy your path of mastery.

Have you met agile experts that know everything and have confident answer to every question? Have you met agile experts that deny new things and believe in a defined set of principles? Beginner’s Mind is a great way to keep learning.

I’ve mused quite a lot on the Mastery book. I do have several hobbies -arts or sports- that I feel like I should practice, because I got talent for them — and I’ve actually practiced them for quite a long time — and I should definitely keep up with them. At some point I just got stuck. I couldn’t figure for myself how one can fit several hobbies and sports, and their diligent practice to a busy schedule — after all, there’s a job that I also love doing! How do I fit all these loves into a limited time?

I also noticed that in the process of getting stuck with this dilemma I seemed to stop actually enjoying those masteries. I would spend countless hours on the web, reading everything I could find on getting things done, finding focus, feeling superior to bloggers describing things that I know very well how to do.

GTD

The problem of choice has been chasing me all the time. Finally, it all came out simple. I also noticed that even if you read countless how-to’s, countless blogs, no matter of how many of those how-to’s you read, and how well laid out they are — it inevitably takes time for things to go home. Reading about something and understanding something from within are two different things. That’s why all the “getting things done” blogs and books are nothing more than someone else’s experience reports. Reading someone’s blogs will not solve your problems of gaining focus and concentration. It’s a substitute for what it’s all about — for practicing. I’ve seen people making a big deal out of GTD. All these GTD software, gadgets, hacks to block interruptions, you name it. Making a religion of GTD gives no more time to practice your mastery, that’s the point.

You’ve got to sit down and decide for yourself: what is it that you actually love doing? Once you listen to your inner voice — it all gets in place, like in a puzzle. There’s no need to think any more. If you really enjoy what you do, setting priorities is absolutely irrelevant, because what you enjoy doing now is the best thing you could do right here, right now.

If you still find yourself digging in how to’s and blogs, there’s nothing wrong about it. Probably your research reflex isn’t yet saturated, and you feel more at ease in a research, in a familiar comfort zone of consuming information on a soft couch.

Feedback cycles are very important in software development process. To create cool products we need to get feedback as early as possible, and we need this feedback fast. Design Ideas Board is an interesting way to collect feedback from co-workers on design and UI decisions.

How it works? Mount a large cork board in a busy office location with good people traffic. Anyone can pin a design, a wireframe or anything like that. Then anyone can use sticky notes to provide feedback (make sure that marker and sticky notes are available right there).

Here are some examples: a new web site product page design idea with several critical notes:

A view area redesign sketch with ideas on tags improvements:

Here’s the full view of  our Design Ideas Board:

Why is this board so good? It works as a live information radiator, improving design WIP visibility and fostering team collaboration.

Do you know how to run a really productive meeting? I don’t. I’m learning, and I run meetings with various success so far. My most recent insight is related to the size of a meeting group. Let’s evaluate various sizes and identify strong and weak sides.

Presentation

If you have hundreds of people all you can do as a single group is to listen. You have one presenter that broadcasts information, all the other people consume the information and digest it inside. On the picture below presenter is marked with  red color as a sign that he is the most (and the only) active person there. There is a huge diversity in this group, but there is no feedback, so decision making is impossible. All you can do is listen, think of some new ideas and write them down to discuss later.

Large Meeting

Ten or more people sitting at a single table make a large meeting. Again, there is a great diversity among people, but… Usually several people are almost completely silent, they just listen and do not give anything back. There are several very active people that lead the discussion mainly. The real problem with such a large group is that nobody can consume information from more than 1 person simultaneously. It means when somebody talks, all the others should shut up and listen. Often a large group splits into smaller groups randomly and neighbors discuss something  ignoring the rest of the group. I believe this happens when people ‘feel’ the need for a better communication format. Overall, it is very hard to have any meaningful decision in the end and very often the result of such a meeting is … Yes! To schedule another meeting!

Small Meeting

This is the real problem solver. 3-4 people communicating intensively have more chances to really get the problem and nail the decision. Communication is very dense and there are many feedback loops. You say something, I catch new ideas and say them back. Broadcast-consume-broadcast cycle repeats many times. All people are active. Everybody feels the pace and there is no place for boredom.

Duo Meeting

This is not a meeting, but rather just a discussion. This type of communication happens all the time in pair programming, for example. Communication is very rich and dense, however, sometimes there is a lack of diversity. That is why pair sometimes brings a third person into their discussion to solve a doubtful problem. 3 people can solve problems more effectively than 2 people.

Solo Talk

If you talk alone, probably it is better to visit a doctor. It is much more efficient to have an “inner dialog” than thinking aloud. Surprisingly, thinking is a quite good method to solve problems. For example, I like to think alone. However, sometimes you get stuck and see no fresh ideas coming to mind. Moreover, solutions that you invented may be really bad (or not as good as you think). Group discussion is still the best way to evaluate ideas and select the best.

Now let’s have a look at the resulting chart. It shows meetings by 2 axis: intensiveness of communication and groups diversity.

I think it is better to run meetings with 3-4 people to solve problems effectively and split large groups into many small groups. A small group has enough diversity and intensive collaboration to be effective. Several small groups have even greater diversity and potentially can create an even better solution than a single small group. Sure, it will be more expensive and slow process if you invite many people. Just consider several possible options for your next meeting.

Design Studio is a quite simple and efficient way to run UX meetings. Yesterday we tried it for the first time. There are several variations of Design Studio, we made it simple for the first run and set the following rules:

1. Define problem.
2. Sketch 5 ideas individually. No more than 5 minutes per idea.
3. Present and categorize ideas to the team.
4. Discuss positive and negative sides of the ideas.
5. Select interesting ideas and create 2 versions for each final final solutions.

We ran Design Studio for the first time to design Email Integration plugin UI. This plugin allows to setup emails integration and define some rules like “bind email to project and create request”. This way TargetProcess retrieves emails and does some interesting things.

Alex, UX designer, is asking some questions.

Sketches categorized by ideas: 1 vertical line = 1 category.

Sticky notes show votes for each idea. 3 ideas have been selected as top ideas.

Hot discussion.

2 most repeated ideas: define email rules via drop downs and via drag and drop

The wall overview

Resulting Sketches

Setup email rules via drop downs

Setup email rules via drag and drop

In general, the meeting went fine. It took about 2 hours to generate, discuss and select ideas. 8 people participated in the meeting, and it seems too many. I think it is much better to have 4-5 people, no more. Also the ideas convergence phase should be improved. Too many people generate too much buzz, so it is harder to make decisions. Anyway, we are going to try Design Studio again and adjust it to our needs.