In a month we will run our third internal conference. This is supposed to be a full-day event, with one-of-a-kind sessions prepared and presented by our team members.
Here is the program:
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:
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 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.
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.
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.
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.
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:
| Company | Founded | Significant Milestone | Years |
|---|---|---|---|
| 37 signals | 1999 | 2004 (Basecamp) | 5 |
| Fog Creek | 2000 | FogBugz 4 (Dec 2004) – won Jolt award 2005 | 4 |
| Atlassian | 2002 | 2007 (Confluence won Jolt award) | 5 |
| Rally | 2002 | 2006 (won Jolt award) | 4 |
| Mint | 2005 | 2007 (best online financing software) | 2 |
| Dropbox | 2007 | 2009 | 2 |
| Groupon | 2008 | 2010 | 2 |
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.
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
Yesterday we had quite a hot discussion about releases schedule in TargetProcess. There are two main options how you can release functionality:
Which approach is better? Everyone in agile movement will vote for the first approach. It is clearly a waste to hold a done feature in the backpack without making it public. Every marketer says that release should be a significant event with solid preparation to explain why this release is cool and how it helps to solve real life problems.
In general, it seems there’s a Development vs. Marketing opposition.
Development wants something quick, off we go, collect feedback and improve.
Marketing wants something big enough and predictable, to prepare all materials and promotion.
I must confess, there is no clear answer to this question. As a developer I want to release feature asap. As a product owner I want to release feature asap, but understand that without major releases customers/leads may have a feeling that there were no significant changes in product over a long period of time. Is this a real problem? I don’t know.
I believe that Marketing should adapt somehow to frequent releases and change strategy to use this as an advantage. How? This is something we should find out.
Last week at the mini-conference, one of our guys had no time to do a nice visual wrap-up for his presentation and sufficed with showing portraits of authors while just reading the extracts from their works. The topic was lean basics, and he was talking about Deming and Taylor. While everyone seemed to get bored with listening, as there was no nice visual stuff like we’re all used to now, I suddenly caught myself visualizing the talk of the boss and this worker. The story was about the boss who was convincing the worker to bring 47 tons of iron instead of 12 or something like that.
This got me to thinking that sometimes visualization is doing lip service to us. We’re sitting comfortably, watching TV or watching presentations with nice stylishly UX’ed data, and we are losing the ability to make visualisations with our own brain! The picture is brought to us, so we make no use of the imagination “muscles” and our imagination weakens.
I’m not saying that everyone who watches animated drawings from RSA Animate is doomed. But there always should be a balance between perceiving someone else’s visualizations and creating your own. The power of creative imagination is above everything. No speaker or agile champion, or TV presenter will draw a vision of your business, your product or some function of the software you’re crafting. There’s always a time to look at someone’s visualizations, and time to create your own. Each and every “how-to” about creativity includes this magic word called “vision”. Have you ever thought why any business starts with a vision? It’s exactly for this reason.
There’s a paradox: on the one hand, visual media is everywhere. Lots of visual channels deliver the dish to any, even the laziest perception. The problems is that the legion of those watching produces too few creators.
We’ve got 1 more day left in the year 2010. It’s time for New Year miracles. So let’s devote this day to our creativity, to cleaning the debris of anything we don’t want or need any more, and let’s visualize a
You are having your first project. In the beginning, you know almost nothing about programming languages, business domain, development process, efficient practices and other good things. In the beginning, you know almost nothing about political games, external factors, progress reporting, human stupidity, fear of mistake, boredom and other bad things. You can’t do your job effectively. Suddenly, in 10 years, you are becoming a great software developer. Or you are buried by mediocrity and never ride the wave. Why? What should you do to advance or just survive?
I think one of the most important factors is perpetual, passionate learning. Learning is the most important thing that drives software development forward. Learning is the most important thing that drives you, as an individual, forward. It drives your team, as a group of people, forward.
source: Ashiro’s LabZone
I believe, learning is a key attribute of a good software development process. Process that empowers learning will work, process that impedes learning will fail.
Basically there are three levels of learning. First, you learn as a person. Then you learn as a group of people. Finally, you learn as a whole organization. This post focuses on personal learning.
I have my own vision about software development. Most likely it comes from my personal background and products I’ve worked on (all of them web-based).
Software developers solve problems. To solve a problem in a cool way, you need to be a multi-skilled professional with quite solid knowledge from as many related disciplines as possible. Only this will give you a complete vision of the best possible solution.
We are stepping on a slippery ground of deep specialization vs. broad knowledge. My belief is that at the current stage broad knowledge is better. Why? I can provide some analogies that prove nothing, but still are interesting.
Software development is a young discipline. It has its own properties that are not fully understood by most people. You can’t apply mass-production to software development so far, since you can’t formalize it enough. You can’t write a product specification, create design and generate complete application from UML diagrams (yes, I am aware about Model-Driven Development, but it is not even close to mass-production).
Look, there are so many related topics, from psychology to programming languages, from ToC to pair programming. There is no best way to write software so far. If you can’t apply mass-production to software development, you can’t do it efficiently with people who have a very narrow specialization. You can’t put it on a conveyer.
Let’s take science and look back 300 years ago. We will see that many discoveries were made by generalists. Let’s check Wikipedia.
It was common 200-300 years ago. In modern science you can’t discover anything without deep specialization. There are people with broad knowledge, but it is quite rare these days. More often you will find people like:
There are rare exceptions for sure, like this one:
What is the point? Software development is obviously neither a science nor a ‘tangible’ industry, so all such analogies don’t prove anything. But I think software development now is somewhere in 17th century compared to science and in 19th century compared to usual industry.
With this in mind, a team of generalists with some specializations can create a better software than a team of highly specialized people. It is not obvious and we need to evaluate this assertion. I can throw some arguments:
I believe in multi-skilled software developers. The right question to ask is “how much skills should I have and how deep?” It really depends, but here are the skills/domains/attributes every great web developer should have. The list is sorted by priority and I put hours that should be spent on formal education:
I insist that these skills are very important for any really great web developer, but they may vary depending on software development type. I expect questions like “Why the hell you put User Experience before Programming?” The reason is that UX is an important part of problem solving. It is more important than implementation itself. UX gives developer the right perspective and makes a strong impact on software solutions. Without UX you can beautifully implement a crappy solution, and 90% of all existing software is exactly like that. IT’s crappy, unusable and bloated with unnecessary features.
Great developer should have a “sense of beauty”. It’s hard to formalize, but in general he should be able to say “this button is ugly” and “this menu is beautiful”. “Sense of beauty” is a very important property, it affects everything: visual design, documentation, architecture, source code. Everything. You can (and should) train it.
In the next post I will share my vision on Learning as a Team.
If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc. Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives. Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences :)
I tend to think that with all the information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile - it’s hardly that something will be totally new to you (“totally” is the keyword).
Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) . As opposed to most attendees, I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team :) I’ve seen a bit of those “paper sword fights” :)
After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way (including live jazz night in Krakow).
This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration. In a sense, that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire even if this is your first experience as a speaker.
And.. it’s great that there’re many more agile conferences to come :)
January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back and recall the most interesting blog posts by TargetProcess in 2009 :)
Based on visitors count, the posts are ranked as follows (descending order):
1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.
2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)
3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.
4. Tale: Deadline and Technical Debt: Once upon a time… Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go: smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.
5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong” instead of “what’s right” …
6. How We Use Kanban Board. The Real Example: Once we figured that Kanban process is just the right thing for us and put it in action, we shared this experience with our blog readers.
7. 5 Right Reasons to Apply Kanban: There they are :)
8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.
9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.
10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.
These are the TOP 10 posts in 2009 from TargetProcess agile blog (click here for more)
Happy OLD NEW YEAR! :)
Kanban is becoming a popular agile tool. Indeed it is very good for software projects of certain types. However, there is a danger of false reasons behind Kanban adoption.
“Our stories vary in size a lot from 1 point to 40 points. Large stories just do not fit into an iteration”
It is very easy to say you can’t split user stories, thus iterations should be abandoned. An easy solution is not the best one. There is something important behind the fact you can’t split stories. Most likely you don’t know how to split stories right. It is quite hard from the beginning and demands creativity.
Moreover, according to Queueing Theory, it is better to have small stories with roughly equal size. Small batches with equal size improve flow (and you have a better and more predictive cycle time). So in Kanban you still have to split stories to smaller stories and try to make them equal size.
“We can’t complete most stories in a single iteration”
There may be many, many reasons behind. Mini-waterfall approach, velocity greed, large stories, manual testing, poor stories description, etc. You may even have a wrong iteration length. For example, in large projects 1 week iteration may be an overhead with a huge transaction cost. So 1 month iteration may be much better in this case.
You need to analyze true reasons, the roots of the problem.
“Retrospective meetings are waste, they do not help in process improvement and we want to remove them”
You just don’t do these meetings right. One popular failure is no Action Items after the meeting. Without action items a Retrospective Meeting is just a kind of informal chat that you may have over a glass of beer. You meet, chat about your problems, and get back on the same track next day. Rule #1 is to collect and write the list of Action Items that you will try to accomplish during the next Sprint [or any other time box].
One more common pitfall is to skip action items execution. You may collect them, but not really try. You may even try them, but abandon too quickly. Almost all new rules or practices put you off the comfort zone. It takes time to learn them, use them and like them (or dislike), but it should be an expert opinion, not just a gut feeling.
If you expect that you will replace failed retrospective meetings with a nice and simple “stop the line” rule, you’ll fail, since it is even harder than scheduled regular retrospectives and demands even higher level of self-discipline.
“We have a single pool of developers and share them between projects. We can’t form stable project teams”
Do you really think that Kanban will solve your social and organizational problems? C’mon! It helps to visualize flow and find bottlenecks, but if you don’t have a cross-functional team — you have hard times. It is proven in so many sources and researches that cross-functional teams perform better, produce better results and better software.
If you are experiencing difficulties planning sprints with shared pool of developers, try to fix the root of the problem first – switch to cross-functional teams and eliminate multi-tasking.
“Kanban is so simple! No plans, no estimations, no iterations, no overhead”
Indeed Kanban looks simple. But it provides nothing interesting by itself. To ensure a successful Kanban adoption, you need to apply Lean principles first. This new buzzword may sound like a silver bullet, but obviously it is not. Hard work, discipline, target on perfection and constant improvements – all that is required to apply any agile methodology.
Don’t get me wrong. I am not saying that Kanban is bad. We use it within TargetProcess and I personally believe it works way better than iterative development (for us). I just want to make a point that you’d hardly resolve all your underlying problems as you switch to Kanban.
P.S. I usually don’t read posts like “10 reasons to …” Can’t believe I wrote such post myself! :)
P.P.S. Read next post 5 right reasons to apply Kanban.
