Edge of Chaos | Agile Development Blog

4 people from TargetProcess attended London UX Conference this year. It was a decent event and here are mine “take-aways”.

UX + Agile

Alan Cooper read a solid visionary lecture about UX future and adoption. The main trend is to mix agile software development practices with user experience teams. There is a new initiative called Balanced Team. He did not spend much time on this topic, but that is something I am curious about. We’ve been adopting UX + Agile at TargetProcess since 2009 and definitely want to do that efficiently.

It was nice to be reassured that we are going in the right direction as a company. We already do many things  Alan mentioned in his speech.

Visual Meetings

Our meetings might be better. Sometimes they are too long. Sometimes too boring. Sometimes there is no clear outcome. Quite many workshops and sessions at London UX 2011 were dedicated to better, more productive and more fun meetings. Sunni Brown ran a fantastic workshop:  The Art of Graphic facilitation (a.k.a. “How to Run A Workshop with Pictures”). It was very funny and useful. We had several short creative meetings and drew a lot of sketches. I highly recommend her Gamestorming book.

Kate Rutter’s session Design Patterns for Fantabulous Collaborations was very informative and I’ve learned new ways of running efficient meetings, but the practical part was a bit boring and out of context. Overall, after this conference I have a clear understanding how we can improve our meetings which is good. Best Practices for Facilitation looks like a “must read” book, but it seems you can barely purchase it.

We often do ad-hoc meetings, without any preparation. We go like “Let’s discuss this user story with filters”. However, such meetings should be planned. All attendees should be prepared. There should be a right balance of order and chaos. Our meetings are on the chaotic end, so we have a huge space to improve.

Sketching, Sketching, Sketching

Everybody should be able to sketch. It means we should train people to not be afraid to draw something and express information with words AND pictures. Adults often prefer to write and don’t like to draw their thoughts. Mostly because they’re wary of looking  “unprofessional” and “ridiculous”. We should break this prejudice. Sketching is a very powerful technique that allows people to try and express ideas blazingly fast. Bill Buxton wrote an incredible book Sketching User Experience. Read it and you will understand why sketching is so cool.

1. You don’t waste time on estimation

Estimation takes time. Even if you do planning poker and use story points, it still takes time. What do you do to improve estimation accuracy? You gather some data, analyze the data and discuss the results. You are spending time on all that. But are you sure that estimates really provide any value? Most likely not. It is a waste. You’d better spend this time doing something important for the product.

2. You shouldn’t explain to higher managers why it took soooo loooooooong

If you don’t have estimates, you can speak without fear and explain things clearly. You can enumerate problems and explain how they were resolved. You can show that you work really hard and take all the necessary actions to release this story as soon as possible with great quality.

If you have estimates, be ready to hear something like “you screwed up, maaan! You had to deliver this feature till the end of the month! What the f%$k is going on?” as an argument. The team put themselves on a weak side immediately and have to care about deadlines more, not about quality or a better solution. Is it something you really need?

3. You don’t give promises that are hard to keep

You are not relying on people’s optimism (which is built in). People are optimists (almost all of them) and inevitably give optimistic estimates. You can use  complex formulas or very simple rules to have better estimates, but is it really worth it? You can spend many hours defining correct formula for exactly this development team. People will not trust you, since you (rightfully) don’t believe in their estimates. Numbers will look “made up” and still you will have incorrect estimates in the end.

4. You don’t put additional pressure on development team

In some teams Estimate is equal to Deadline. That’s bad. What do you do to meet the estimate? Compromise quality? Tolerate average architectural solution? Abandon polishing? All that leads to poor solutions that end users will not like. It is better (almost always) to spend more time, than planned, and release something really usable and useful.

5. You focus on really important things

Imagine, you have a planning poker session and estimate all stories inside an epic. You sum up all the stories and define it as a 1000 pts epic. You just stick a “fear” label on the epic. People do fear large problems. A 1000pt problem is huge and psychologically it is harder to decide “let’s start it right now”. Product Owner will have a temptation to implement 100 smaller user stories instead of this huge epic. However, it may be a bad decision. This epic may be really important, the morst important thing for the product.

If you don’t estimate it and are not completely sure about its size, you have a better chance to actually start doing it.

What is the recipe of a successful company? How to become an expert in any discipline? People are struggling to get answers to these questions. We have thousands of books full of business advice. We have terabytes of information on any subject. (I believe 80% of information is pretty useless. It contains no real value, just a compilation of other sources.) OK, back to the topic.

Skills

I am reading a very interesting book (in fact it is a list of research papers)  Nature of Expertise. This research is dedicated to human expertise. What is the difference between an expert and a novice? How can we train novices to become experts faster? The general notion about expertise is that it takes about 10,000 hours (~10 years) to become an expert in a complex discipline like programming, chess etc. Yes, there are exceptions, but you have to spend ~10 years on average to become a great software developer.

I’ve contemplated that for over several weeks and tend to think that this is nearly true. Only now I really feel I can do something significant. I wanted this 5 years ago, but obviously was not ready enough. I lacked some skills such as User Experience and Leadership. I was quite bad as a CEO, but improved a lot over the last years.

Success

An even more interesting question is whether we can apply the same rule to companies. It seems we can. If it takes 10 years for a person to become an expert, it seems it takes about 5 years for a company to find its way. It means that on average a company is struggling for the first 5 years, gains some experience and is then capable of doing something significant. Let’s take some random examples. I’m not picking companies that meet the criteria above, just some companies I know and for which I was able to find history records:

OK, it seems there are 2 groups of companies: some of them are really quick and did something cool right from the start. Some of the companies follow the 5-years rule. Also, it seems that fresh startups are more apt to succeed quicker. Does it mean that the years-to-success number is decreasing? Maybe. It will be compelling to verify this tendency. It can also mean that years-to-failure is decreasing as well.

There is a very interesting data about 100 largest publicly traded software companies that shows how fast they hit $50m revenue.

There are 3 groups of companies: Rocket Ships ($50m in 6 years or less), Hot companies ($50m in 12 years or less) and Slow Burners. On average, 8 years is required to have $50m revenue. I believe it is somewhat consistent with the 5-years milestone. Obviously, it takes time to grow when you have created something cool. Usually it is not an immediate effect.

Rocket Ships

I think it takes a good deal of time to research many companies, identify their first key milestones and find out typical patterns. There are so many factors like company size, management style, environmental changes etc. Still it will be very cool research to do and I believe it will be possible to evaluate companies based on its results.

Does the “10-5 law” exist? I don’t know. But. If you can’t master something in 10 years, maybe you should focus on something else. If you can’t do something great as a company in 5-6 years, maybe you should change your business goal.

Editor: Olga Kouzina