Archive for the ‘Refactoring’ Category

Last week we published version 43 of the book Who is agile, Volume 1 (Yes Volume 1 as we have decided to create also a volume 2)

With version 43, we added Peter Armstrong as 89 person to the book.  That is the last person we add to Volume 1.

From now on, we have a quality control phase. (Wow, how un-agile of us…) What would Lisa  or Elisabeth say of this? ;-) )

these are the different steps we have to do for each person in the book:

  1. Spelling and grammar
  2. Are the  links to person you mention that are  in the book, are these internal book links working?
  3. Are the books you mention in the book list?
  4. Are your links you provided in the contact list?
  5. Is your question in the question list?
  6. is there anything you are missing in the book?
  7. is your location on the map correct?
  8. Update: is your location mentioned at the bottom of your answers?
  9. Update: Does  your location (mentioned at the bottom of your answers) have a correct wikipedia links?
    (You might want to download the latest version of the book for 9 as we only added the links on 2012/10/30)
    As you can see, doing this for 89 people and +20 community events is a lot of work. That is why we are sending out mails to everyone in the book to help us.

    Will you help us too?
    If you send us info, please add the version of the book you  have been reviewing.

 

 

 

 

Related to “Just do it” is this theme. The title is a quote from Grace Murray Hopper one of the amazing IT women (I added a book about her in the booklist at the end.)

A special case of perfectionism is people waiting for permission . Complaining that their bosses take to long to take decisions, or that they are moron’s that don’t take the right decision. Complaining does not help your situation.
Agilists are professionals. Professionals take decisions for their work.

Most perfectionists look for some kind of recognition. For some of them that locks them from starting anything without permission.
In reality most chefs are very happy when people come with solutions instead of problems.
Even happier when they execute things and report on the progress.

Some managers have not enough experience with this kind of behavior. Maybe you are a manager and this idea makes you afraid. What will people think of me as a manager when my people take decisions?
Will they consider me as a good manager?
Hold this thought for a while.
Let’s first focus what this could mean for your time.
– A lot less boring meetings
– A lot more time to do all the things that you are supposed to do. And you know do in the evening.
– You will finally have time to help your boss be successful.

⇒ Imagine you can focus on helping and making your boss successful.

Now go back to that thought you had before.
How will she think of such a manager?
Right, she will want more managers like you!

Do you see a pattern?
A perfectionist boss, creates perfectionist teams.
This is called team==product.

Agile Techniques Supporting “Ask for forgiveness instead of asking for permission”:

  • Retrospectives
  • Self-Organization
  • Refactoring
  • Visual Management
  • Small Iterations
  • Continuous Integration
  • Unit Tests
  • TDD
  • BDD

Books:

Just as there was a risk with “yes we can”, long term vision might block people block from starting. I call this the perfectionist syndrome. People rather do nothing than doing something wrong.
Well, in reality never taking any decision is worse than taking a wrong decision sometime.
The cure for this syndrome is “Just Do IT” A lot of books about starting your own business (see the biography), tell you the same thing: better start.

Just start doing something,as whatever you do now, it will be wrong anyway!
;-)
Ok that might feel bad. Stick with me for a second. If you take for granted that you will be wrong whatever happens, you will feel better if actually, what you do is wrong. (In the sense that, you did expect it to go wrong anyway. )

And if, by fortune, you are right, it will be a bonus and you have all every reason to have started !

The benefit of starting before you think you know what to do, is that your customer will discover what he wants by you showing him what you’ve got. (And you will discover it at the same time.)
yes, just like you, I want my customer to know what she wants before I start. Unfortunatly customers never do. When I show her what I have done. She looks at it, sees something she does not like and then tells me what she needs. Then I make a new version and we start over. After a few versions, we together create something my customer really likes. (This is true even if I am the customer.)

A lot of agilists, react to BDUF, which is the best know part of perfectionism. That is the old model perfectionism, the “Active perfectionism”.
In agile teams I see the same idea popping up: “ I can’t start with a scrum-board as I don’t have the right material/software etc…
The right answer is “Yes you can. Just DO IT.”

Just look at your todo list, GTD cards, backlog, what is blocking you from starting? Really? Are you sure it’s not resistance?
In Do the Work, Steven Pressfield goes over the different reasons of resistance.  Are your blockers really blockers or only resistance?

Look at your list again. Forget what block you and just DO IT.

 

Agile Techniques that support Just Do it

  • Continuous Integration
  • Refactoring
  • Unit testing
  • Daily Standup’s

Books:

Games that teach “Just Do IT”:

Thanks to Jurgen & Oana for reviewing this post.

One way to gain trust in people, is to gradually give them more responsibility. By splitting work up in very small steps, that is possible. There are actually lots of reasons to work in babysets.

My friend Pascal says, if its hard to do, do more of it.
My partner says to our kids: chew smaller pieces (of meat).

In babysteps multiple dynamics come together:

  1. When the work is smaller, the problems are smaller.  Joshua Kierevsky launched the limited red society in 2010. He wants people to do TTD and refactoring in smaller steps. The idea behind it is to keep the time of a none working project as small as possible.  As part of his e-learning course, they offer a tool that graphically shows when people are in the red.
  2. One interesting observation they saw was that people that are less in the red, usually end up with nicer designs.
  3. People that achieve a series of small steps, gain more confidence than people that do everything in one step. When I try to achieve one big goal I encounter a lot of problems, I only have a feeling of achievement at the end. (While trying I actually am frustrated most of the time)
    When I do something with small steps, I achieve one goal after another. Like with tdd where I implement one test after another.
  4. At the end of the day I actually feel I have done something (implemented x tests).==>  I gain confidence.
  5. Its easier for other people to see what I am doing.
  6. With babystep not only is what I am doing visible. It also shows my real progress.
  7. Because all the sub-steps are visible, they can congratulate me on specific actions. When they are specific in their congratulations, I tend to believe them more thus trust them more.
  8. When the direction I am going is wrong, people have the option to give me feedback (not possible if they only see work when my work is done after a few days)
  9. Depending how the work is splitted, other people might have the options to help me. When I do everything in one large chunk that is never possible. This way people see me less as the hero, but the work gets done.
  10. Not only can they help me, it is also possible for people to take over when my priorities change. (Both  personal or company driven priorities)

Update: Or like Peter Sims from TC says Don’t bet big.

 

At ACCD10 one of the sessions was a Marshmellow Challenge. This TED talk shares some of the lessons learned about the nature of collaboration.

As an agile coach and Core Trainer, I’m not surprised that the best results are created by teams that are working in small iterations. (Not aiming for the single right plan.)

Also interesting is that CEO’s become a lot better when executive admins are added. (Because they have facilitation skills..) Interesting that is why facilitating skills are so important for Scrum masters.

Lately I’m talking a lot about refactoring.

When I do, I use a lot a metaphor I have learned from Vera Peeters and Pascal Van Cauwenberghe.

Refactoring is like cleaning a kitchen.

If you observe the kitchen of a restaurant, you will see that they are cleaning the kitchen all the time.

So cooking and cleaning at the same time. (In other words I see refactoring as part of doing development)

Nobody would accept a cook to enter the restaurant and say: today the steak is 20 euro’s more expensive as we have to clean the kitchen first.
(And I presume that is when most people talk about refactoring and want a lot of money/time for it. They talk about doing a big refactoring that is more a rebuilding the kitchen instead of cleaning.)

Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today?

In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.

They presume it goes faster to build dirty code. Does it go quicker to cook in a dirty restaurant?

The big question is of course what to do when the kitchen is in a big mess?
(or what do you do when the code is in a mess)

There I say – use the boyscout rule: leave the place nicer than what you found.
In other words, do a little bit of refactoring to clean the code up every time you add something.
As we don’t want things to break, for me this would be start by adding unit tests.

To do this, I don’t think a team needs the approval of a manager.

A good book that helps people to learn about these first steps is Working effectively with legacy code.  I recently started yet another book Reading club at a client with this book.
I’ll write more about this in a future post.

Update: Another good book is Refactoring to patterns

Second Update: Joshua created a google group around metaphors, I hope you join the discussions around metaphors.

Third Update: Joshua is also the inventor of the Limited Red Society