Edge of Chaos | Agile Development Blog

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.

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

We live in the age of added value. It’s everywhere. Value-added services, value-added products, value-added goods etc. etc. etc.  Actually, so much value has been pumped up in our life, that it’s even strange that this value is not protruding from us like clothes from an overly packed vacation suitcase.

If we take a closer look at the back side of added value, a huge surprise is waiting there. The example I find most notorious is cell phones. What if I want a simplistic cell phone with NO Internet, no camera, even no voice mail, just live calls and SMS?  You’ll never ever find such a phone.

I bet that a phone manufacturer who stops the rush for more new features, would make a fortune in an instant selling the “new frugal” cell phones. In this case, the added value is content which comes from Internet, capabilities to exchange content. Why should someone want a phone without Internet?  My word, very soon we will see such phones on the market. The niche for them is already there. Here’s why:

More content and more various channels to produce and exchange content is now commonly presented as added-value. Hence, a communication device which happens to be a humble phone is supposed to deliver this value. But as we’re oversaturated with content, no buzz is a huge deal. The luxury of focusing on one thing at a time is something that only a few can afford. Besides, it’d be very frugal (frugal is actually the new buzzword :) to buy a phone for a reasonable price, and sell a used iPhone to some geek. Oh, pardon me. It’s all about iPads now :)

There’re plenty of such examples. Another one: the added value of having a car means lack of natural movement, the necessity to pay for gym etc. It actually brings along the whole array of more added value  goods and services that turn out to be not of added value but of less value, since you pay for what you could do naturally.

Take organic products. Now they’re added value. 100 years ago who could have thought that something natural adds value? Now it’s a rollback. What is simple and natural costs more, but has less value compared to the original added value concept for the matter, and the cycle goes on and on.

And we’re nailing it down to our favorite: project management tools. Versatility and too many features now have bounced back to the simplistic Kanban board.

It looks like it’s time to not only practice lean production, but to produce lean products. Gaining focus requires focused tools, one way or another.

When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the “one thing at a time” part. This is by no means a new thought.  E.g.  Mary Poppendieck was heard saying that product backlog should be eliminated.

So, as in to-do lists, there’s no point in nurturing and moving product backlog items back and forth.  In this case, a lot depends on what is your definition and understanding of product backlog. I’d say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure.  Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a “backlog” but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.

Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we’re now using several buffers – the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by  Product Owner who decides that some time these will be implemented for sure – based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.

Here’s a quick graphical representation of this product backlog upward funnel:

That’s how User Stories lifecycle looks on  Kanban board, from Planned state on:

Backlog is not seen on Kanban board.  When done with their current user stories, developers  pull new user stories from Planned state.

Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation – so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering  is done by moving stories to Planned state and prioritizing them.

I’d say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you  commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can’t resist citing an analogy here: it’s the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps – you’re very agile and flexible to position yourself for the perfect shot.

So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.

That’s the way it goes for us. You’re better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning :) than with giant leaps.

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 :)

Yesterday Google alerted me about a review of TargetProcess  by Boris Gloger. I started reading this review and I couldn’t believe my eyes. How could Boris Gloger, such a respected Scrum trainer, overlook some important features of an agile tool he’s reviewing?

Writing reviews  is a very responsible task. It only seems that web can tolerate all. There’s no censorship, no security checks on whether the info in a review can be trusted or not. Reviews are about knowing all the facts. Only when you make sure that you know all of the subject matter, then you can write a review.  I’d never stand up as a guru and claim – my people, I’m your guru, I know all about this tool –  and then – ooops.. – I’ve got some essential flaws in my knowledge of this tool.

Now, let’s see what Boris Gloger overlooked. Comments on Boris’ page do not work(!!!), unfortunately.

Target Process is a tool created by Target Process Inc. to manage agile process. They can support Scrum, Extreme Programming, Lean and others. The tool have a good set of features and some nice ideas to speed up the addition of data for your project. They also provide a Eclipse and Visual Studio add-in so each developer can see their to-do list right on the IDE. If you like to try it for yourself there’s a 30 day free trial available.

Ehm.  TargetProcess comes for free not only as a 30 days trial. It’s free for small agile teams up to 5 people. It’s our humble donation to the growing agile community. Boris, it’s a fully functional free copy with free updates and subscriptions for agile teams of 5.

The “Features” works like an Epic or Theme for your stories and if don’t care for that it can be totally skipped. If you’d like to use it’s possible to determine an estimation and priority for the features but it really doesn’t make much sense to me.

The Features DO work like Epic or Theme and you can rename Features to Epics or Themes or any other name of your choice. The names are completely customizable and it’s up to you which name to choose.

I’d prefer to see something simpler like tags for the stories.

What??? We’ve got tags for user stories and for all the other entities! We’ve got bundles of tags. Tags board. Tags are powerful tools for categorization and filtering, so if I were a certified Scrum Trainer I would have quadruple checked before making such a blunt statement about no tags in any agile tool.

We talk about estimating feature so, of course we can estimate stories also. That’s the first problem i think the tool have, it’s only possible to estimate using time units, ideal or not. That’s no mentions to story points at all, this miss, pushes Target Process to field of time tracking tools, which is not a good thing.

Wrong, wrong, wrong. You missed the point with story points. They’re there, and you can choose between ideal time units and story points. This bold statement of no user story points in TargetProcess pushes you, Boris, to field of shallow reviewers that do not take enough time to study the agile tool they’re reviewing, and then spread this distorted knowledge to their students on Scrum trainings.

Target Process is supposed to work with different agile models, so they use the term iteration instead of sprint.

Foul and a miss. As I already mentioned, one can customize terms and rename the term “iteration” to “sprint” or whatever. TargetProcess is supposed to work with different agile models, so we’ve made our terms and processes completely customizable.

On the Taskboard there’s an awkward choice, there’s only two columns available Open and Done, where’s the WIP ? It’s on another tab Kanban Board, I really don’t understand why they went that way, but it’s no good at all.

Ugh. I really don’t understand how Boris could have overlooked such essential part of TargetProcess as customizable states and processes flow.  Two columns Open and Done on the task board are available for dummies. For advanced reviewers, all the states they want are available. Users can introduce as many states as they need to their development process, and they can give any names to those states. Kanban Board states are customizable as well. It’s no good at all that our honorable reviewer missed this..!

It’s hard to say what I think about Target Process, they had good ideas, like the shortcut flows, but really bad ones like the Kanban Board. Overall the tool is ok but not very intuitive, could be more polished on the user experience, and of course the common problem of too much focus on time tracking hurts a lot.

Boris, I promise you will not be that hurt as you take a closer look at TargetProcess. You seem to have some special inkling with too much focus on time tracking, that’s why you see it where there’s no special focus on it. Time tracking in TargetProcess is just in the right amount, no less, no more. IMHO, it’s rather less of it, than more.  As for user experience – draw the curtain… look in here :)

There’s so much room for observations and analogies in the evolution of production trends. Analogies are not merely a candy for the brain. They bring along a deeper understanding of phenomena and ultimately are one of the greatest aides to align (or misalign) with mainstream.

If we look back, to the 18-19th century – mass production was a dream. The philosophy was: produce more.  Lavish architecture designs, garments, gardens – everything created by people was about going more massive and taking much space. Standards of innovation have been changing over the centuries  - what’s been innovative and massive, has been becoming obsolete. Minimalism is the new innovative. Is it because humans subconsciously feel they’ve taken too much terrain and sky on this planet for industrial experiments and now are trying to compensate for that by being minimalistic in everything? Or simply finding ways to fit in?

Hardware/software as well as visual designs and interfaces are meekly following the same trend. This just shows how subtly the “new innovative” standards are taking over. We remember huge PCs. Now we’ve got all kinds of minimalistic devices the names of which start with “i“. We remember waterfall. CMMI standards  with their tons of rigid rules, regulations, documented processes. Now we’re  going “lean” and “agile” – the same minimalistic tendency.

People have managed to stuff the overproduced artifacts not only all over the planet but all over themselves. Fatness is the problem. Again, what a shift in standards –  as late as in the beginning or even middle of the 20th century it was considered trendy to be fat. Well, not obese, but hearty fat. Now, we’re all about lean. Off with plump beauties. Straighten up now, lean is the philosophy of minimalism in production.

P.S. I truly believe that all the fat folks are hiding the “lean” insignia deeply inside them. It just takes some effort to peel off the layers :)

Recently I’ve read a very interesting post by Anna Forss called “Stupidity of the Team”.  While Anna concludes, that it’s healthy to introduce diverse opinions and invite opposing minds to dissolve the like-mindedness of homogeneous teams, I think there’s one important nuance that shouldn’t be overlooked.

Let’s think:  teams exist for some purpose. To resolve some goals. If it’s a small product development company – then this team exists to develop a product. Permanent rebels are not welcome in any group – because what they do with their rebels, argues, drawing attention to themselves – they blur the focus of the whole purpose why team exists. Of course, a team will naturally outcast this person.  Next, if a team is bombarded by controversial opinions and judgments, they will spend all their time evaluating and thinking if this is right or wrong. They will get busy sticking tags on new opinions instead of focusing on their work – and they will inevitably lose their focus.

Life in a small development team can be compared to living in a sheltered reality, with it’s particular culture. An isolated sheltered reality will not last for long if it’s completely isolated, so emerging on the surface for a gulp of fresh air is really needed.  As a member of a small team – can you remember when the opposed rebels and opinions really did help? When they triggered something that the team would not have thought by themselves? Well, of course, if someone comes up and says – “your UI is bad” – then another person comes up and says – “your UI is bad” – then you start thinking that it’s indeed something wrong with it. You’ve got this signal from outside world. You work on it. Basically, you know what you should work on. The outsider’s opinion has accomplished it’s task – the outsider’s opinion can now go, because you’re not interested in hearing variations of one and the same opinion.  You get to work, and you work to develop a nice new UI.

There’s no need to focus on outsider’s opinions and pay too much attention to them. Outsider’s opinion is just a trigger to team’s actions – it’s not something that the team should busy their brains with all the time. In a way, diversity of opinions may be even harmful. I guess that’s why we’ve got leaders – authorities who tell the crowd “THIS is your Holy Grail”.

My conclusion is: healthy vaccination with opinions opposing a team’s culture is  good. But don’t overdo with them. Too many opinions will not increase collective intelligence for this team’s specific purpose, they will blur it.

Recently I’ve come across a post on harmfulness of analogies with martial arts. Indeed, there’s a handful of posts comparing software development, or agile adoption, or product development  with  martial arts  - Aikido, Karate, Judo etc.

If you make a direct analogy of software product development and mastering some martial art, it would not be exactly accurate. I guess  people revert to the analogies as they try to project their copies as romantic martial arts disciples into their usual lives as software developers, managers etc.  Perhaps, they’re making the image of their lives more mission-filled this way since there’s not too much space for showing primeval qualities of warrior in software development. But the need to exercise this attitude is still there, as it turns out.

We don’t have beasts to fight, bloody battles and mortal combats. This wrap-up for courage, strong will, persistence in achieving goals and readiness to fight has remained in the past largely. With no wrap-up, people forget that there’s lots of space to exercise these qualities in their usual life.

Let’s go back to analogies. Roger Federer is an unbeatable specimen of mastered elegant performance to me. Look at the way he plays. No waste. He knows, what to do, he knows when to do what. It’s a perfect flow,  the model for effective lean production with no waste and –  the model for perfect warrior  in our modern life. Elegant, no blood on his hands, but he fights, has pitfalls on the way,  stands up, recovers, marches on and wins gracefully.

But he’s just a guy in red T-Shirt. As many software developers :)

Another point is that it’s much harder to fight, win and achieve goals when there’s no immediate physical danger involved as in tennis.  Soo much room for elegant warriors, isn’t it ?

The point I’m trying to make is – let people compare their lives and their jobs to whatever they want. If it inspires and motivates them, makes them feel good about their lives and their work – and makes them feel like warriors, achievers, believers, fighters, winners.

P.S.  February 23 is a perfect day for such a blog post :) Wish you well, guys!

I got this insight on lean and agile techniques in military context when reading  “Ideas Made to Stick” book.  The workflow of the military was described there as an example of how important it is to make messages as concise as possible to accomplish tasks.

The evolution of the military strategy with dates and sources is not a subject of this blog :)
With no extra details, here’s the core of the point I’m trying to make:

First the Army’s approach was to make sure that every single action is planned down to smallest details. But, as they found out, “enemy bears no plans”. An unexpected move could destroy the whole set-up so  ”all king’s horses and all king’s men” could not make the Army function again. Effectively, I mean.

So, they reverted to something very similar to agile technique of creating user stories – Commander’s Intent. Commander’s Intent is “the commander’s stated vision which defines the purpose of an operation, the end state with respect to the relationship among the force, the enemy and the terrain; it must enable subordinates to quickly grasp the successful end state and their part in achieving it”.

Do you see the resemblance? It’s a replica of lean production principles, only in military, not in civic, context. And it’s exactly like the agile principle of engaging people and encouraging their creativity to achieve one common goal.

I will not go into quoting sources on the web on Commanders’ Intent and military doctrines to find more analogies and similarities in military setup and lean/agile methodology.  I just outlined the idea.

There’s a misconception related to this topic: Some people think that agile works all OK for lazy folks. It’s all about freedom, about looseness, no obligations. Not at all. Agile is less conventional, it does not care about being in the office at 9 am sharp, or about wearing a tight business suit. But agile projects do have their Commanders’ Intent and they require genuine responsibility and engagement from the team – the soldiers.

Now, as  the Army follows agile principles, would you need any better proof on the effectiveness of agile and lean methodology?