Bad hair day

I think it was the Dalai Lama who said - if you lose, don't lose the lesson,

My last post (real life, not blogging) was an effort to manage a project the scrum way, and I admit (to myself, at least) I failed miserably...

So, in tribute to the Dalai, what lessons did I learn about Scrum implementation?

Or: subtitled, warning signs in scrum implementation.
Before starting, two comments:

1. This post's sole purpose (except entertain ya) is to serve as a postmortem checklist for the health of your process.
2. A small disclaimer, as all of my posts, this is just about me, highly subjective, take it all with at least one grain of salt,

Or in other words:

And now for the list, bottm-up:

Development team side:

1. A team member refers to the sprint as your sprint (example phrase: "this is the last time I stay late for your sprint").
2. A team member states he knows what scrum is, and that you don't (example phrase: "this is not how scrum is done, in my previous company we did scrum and there was a full spec for the whole version before we started the first sprint").
3. A developer does stuff that is not required for the sprint, but that he believes is required in the 'final' version, and than complains he didn't get enough time to deliver his task. (example phrase: "no need for a code review, I know my code sucks, but I had to implement two servers that communicate between them, since otherwise the solution is not scalable and the final product will not support high load, and that's why the two day task is not finished though I am working on it 6 days already", sometimes followed by "I need just one more day")
4. Team bonding: when the only glue the team has is the the consensus about failure/ how the product sucks/ how the QA or Product manager or whoever doesn't know his job.

Product management:

1. No vision: the question where do you want the product to be in 1 year? two? five? meets a blank stare.
2. Constant panic: new urgent customer needs bypass the sprint, one product is stopped mid way to start a second one, which is stopped midway to start a third one.
3. 'User story', sounds like a strange concept, and the delivered spec has redundancy, contradictions, and outdated sections.
4. Everything is top priority.
5. PM located on a different floor than dev (higher).
6. There are several PMs, each with his own priorities.

Organisation:

1. No space is dedicated for the team (no wall can be dedicated for the daily standup, no whiteboards in any meeting room since all walls are made entirely of glass (on which you are not allowed to write on with a marker), except for one with a plasma TV.
2. Your manager (the one that hired you to propagate scrum to the system) calls all the project managers one day to a meeting where he announces that today is his last day on the job, and wishes you all luck..
3. Management doesn't know team members by name, and presents yearly plans without consulting the team.

(last but not least...) You:

1. The days you come to work optimistic/ happy/ motivated get rarer and rarer.
2. You start a blog-post with everybody else's symptoms and put yours in last place.
3. You stop doing Scrum, (and no one asks you why)
4. You stop publishing the Blog you started on scrum, since you have no positive experience to share.
5. You start looking for another workplace.

Here's lookin' at ya, Lama!

- Till nextime!

Time (is on my side)

Sometime you realize how disconnected you are from someone else's reality only when it hits you in the face.
Following is a word for word transcript of a totally fictitious conversation...

- I don't understand, why should we start the standup at 10:00 sharp?
- Because it is the time everyone is already in, why is it a problem?, we can make it 10:15 if it is too early.
- No, if it is exactly on time, than if I start something before that, I have to cut whatever I am doing for the standup
- Yes, but you can plan your time, don't start anything big before it, and just prepare for the three standup questions one minute in advance.
- But why can't we have the standup when I am finished with what I'm doing?
- Because this way everyone else would have to wait for you.
- Hmm..., OK, so let's start the meeting everyday when the last person of the team shows up!
- Don't you see it is worst for you? this way you will cut your work unexpectedly, and what if when the last team members arrives, one of the existing ones take a coffee-break?
- So let's do it everyday when everyone can.
- RRRR... OK, It is at 10:00  because I reserved a meeting room for this hour, and it won't be available later!!!
- OK, OK, dear lord..., why are you shouting?

Creationism my eye!

One of the proofs Creationism uses to show Evolution is rubbish is the eye.

Basically it goes like this - The eye is too complex a functionality to be created at the process of evolution, hence there must be someone who thought of the whole functionality, and created the organ to suit it.

If you are not a software developer, you may also claim that the existence of MS-Windows (*)  is the proof of the existence of Bill Gates that had a big and totally detailed idea, and created this marvel of software to suit it.

Being in the software business, though, I know things work totally differently.

Most pieces of software, even the famous one (Say an Operating system) have the following life-cycle:
- Someone has a vague idea of what she (**) wants.
- Some code is written to implement this, on the way some details turn out to be impossible or too hard to implement, and some plain irrelevant, and of course some bugs are introduced.
- Through Q.A. ,user's feedback, manager's ideas, or something of the sort, some bugs are fixed and some minor functionality is added or altered.
- If the initial idea survives for long enough, some major changes are introduced (think of major Windows versions), most of the time based on the old code (using the "if it aint broke don't fix it" law)
- If the system survives longer than ATNP*π, the following applies:
   ( ATNP = the Average Time it takes a developer to seek a New Post,  π=3.141592653589793 23846...) 
   - There is no-one who totally understands how the code works.
   - The functionality is as far away from the original design as (fill in your own metaphor).
Given the fact the first man was born at least 5771 years ago (which is the minimum of 3.5 billion years, the Ussher date, and the Hebrew date) and setting ATNP to 30 years (a generous average time for a human to give offsprings), and given the fact 30*π <  5771, I'd argue the eye is a nice piece of evolutionary artifact.

Now, I know what you are thinking (***), but I assure you my intention in this blog is to talk about Software and Scrum, and I'll really try to get closer to it next time! (though I think I talked about both today ;-)

Till nextime!

The S.E.B.


(*) Some argue Bill Gates is the devil, I'd say he is god since they say god is in the details, and MS-products tend to have waaaay too much of those. 
(**) See my previous post.
(***) You are thinking - "no you don't"

The Boy scout Rule (or Ignorance vs. Apathy)

Scrum or no Scrum, the quality of your product depends of your developers.

There is an old joke about a poll taken once in the US, 

One of the questions was - which is worst, Ignorance or Apathy?

And the most popular answer was - I don't know and I don't care.

 

 

So which is worst?

I'd argue for the second.

In fact, I'd go as far as saying that ignorance is sometimes a blessing... 

(Well, not exactly, but the more someone thinks of himself as a professional, the less likely he (*) is to be one.) 

- I had a member in my team introduce himself last week, and what he said struck me.
     he said "I don't think I am a good developer".

- How likely do you think he is to learn new stuff from his peers?
     without the fear of appearing unprofessional, it is sky-high!

On the other hand, let's look at Apathy.
Imagine you have a big pile of tangled code, and the team members, when they have to touch it, do the minimum necessary to fix it...

- meaning 

• Understand the problem, set up the system and try to reproduce it (three hours).
• Find the relevant part of the code (two hours).
• Perform a surgical cut and paste (**) operation (3 minutes), copying a piece of code that includes:
• a try-catch-finally block
• a check for null condition
• a strange number representing the system state, something like
                       if (item.getState()==15) ...
• a logger code like
                       this.logger.debug(
                   "myMethod (15) param1="
                   + param1);    
• Change the copied code, setting the state in it to 16, change the log - setting the state to 16 and the method name to myOtherMethod (2 minute).
• Test the fix. (20 minutes).
• change and fix again (wash and rinse) until it works (say twice more = 1 hour).
• Perhaps deploy the fix on the pre-production system for the QA to test it, and than on the production (two hours), and perhaps some more wash-and rinsing.

The whole process took about half a day if we are lucky (up to two bug a day, not bad!).

BUT, there are a few questions that really bother me:

1. What are the chances the bug was not fixed properly? (say the log still points to the old method...) 
2. What are the chances this code didn't say its last words? (meaning there are other bugs lurking to pop up)
3. What are the chances the same developer will be assigned to the next bug?
4. If he does:
1. What are the chances he will bitch (***) about the fact it is always him stuck with this lousy code?
2. How much faster will he fix the code next time?
5. If he doesn't, and a new developer will handle the bug:
1. What are the chances he will hate the old developer?
2. How much faster will he fix the code next time?

I'd say the answers are:

1. 15%
2. 80%
3. 80% (since now he is considered the "expert")
4. 100% , and a 50% improvement on the actual cut and paste operation, bringing the whole fix to a 20% improvement.
5. 110%, and he will show a 5% decrease in fix time, since the code is 5% more complicated.

And this is where the Apathy factor comes to play!

The developer handling the bug looked at the code as it was covered by an SEP field (as the good book says) 

What if the developer actually took responsibility of the code?

• Try to understand the whole functionality.
• Clean the clutter (is 30% of the code just error handling and logs?, is there an enum saying 15 means "Pending-state", and 16 means "Eruption-state"?, is the logging necessary? is the function/ class too big to swallow at one chunk and can be divided?, perhaps even some code can be reused?)
• And than test, change, fix, etc...

I'd argue the results would be:

• The code touching phase took about 20 times longer (2 hours instead of 5 minutes) and the whole cycle 2 to 3 times longer.
• The developer merited a feeling of satisfaction at the end of the day. (mood increase - 50%)
• Perhaps even a few more bugs were fixed at the process, hence - chances of another bug are lower.  (50%)
• Next time
• The old developer would not bitch that much (50%)
• The new developer would not bitch that much as well. (30%)
• The new developer may be even encouraged to fix some more things, and show them to the old one.
• If you do the math, the process starts paying for itself in 2-3 months, resulting in:
• Fewer bugs.
• Faster response time to new bugs.
• Happier developers.
• A better team-spirit.

And this is the golden Uncle-Bob's boy-scout rule, get it to your team, and you are on your way out of the mess:

Always leave the campground cleaner than you found it

Notes: 

(*) I know I refer to all developers in this post as a "he", there are two reasons 

      - They are a 'he' 93.6% of the time (****) 

      - The 6.4% remaining develop-hers are more likely to follow the boy(eh-voila! why not girl?!)-scout rule.

(**) There are some software dictatorships where the punishment for someone caught cut-n-pasting is a decapitation of the paste finger (see the term 'Yubitzume') , I think it is plainly cruel (and hurts the piano playing capabilities), a simple keyboard hack connecting two live electricity wires to the ctrl and 'v' keys, giving a shock when the circuit is closed seems good enough.

(***) Developer's Bitching is scientifically quantified by WTF/H units (though European and US units differ due to the average working-hours/day and the lunch-break duration).

(****) All measurements mentioned in this post are based on years of experience, as gathered throughout the globe in the past 179 year. personal measurements may vary.

Till nextime! 

The Scrum'em Bear.

The SCRUM Sales pitches

OK, you guessed it, it was SCRUM.

Anyway, a consultant came and started coaching us.
Now, this was the beginning of the fun part, see, up to now no one ever treated a professional training as a coaching.
I must admit I got hooked quite fast, and if I recall the pitches I liked were:

The short blanket pitch
All our life we try to hold a too-short blanket to cover the triangle of features-time-quality.
Since management is great at demanding features and insists on delivery on time, quality suffers, (which effects the time of delivery finally as well...), so let's try another approach: to keep high quality, and deliver on time, let's loosen up the requirements! (we can't define the full requirements for a two year project anyway...)

The human factor pitch
OK, as difficult as it to admit, we are not robots, and we make mistakes, in estimations, in choices, and marketing makes mistakes in requirements. so let's take in small chunks.

The 'It's a give and take relationship' pitch
- We are responsible to make the estimates of the required development, and no one has the right to tell us we are over-estimating.
- We engage to deliver working software in a month.
- In return - requirements are frozen for a month.

The fun pitch
- Thou shall not stay late due to overload (unless you miss-planned), and thou shall learn your lesson if you do.
- The planning is done with post-its, all the development participates. lots of noise. lots of coffee.
- There is a five minute daily meeting, called a standup, we actually stand (and no coffee allowed), so as not to tempt us to babble in it.
- Every end of month (end of Sprint) besides a demo there are:
  - a retrospective; let's try to see what we learned from the way the sprint ran.
  - a celebration: hey! we spent a good effort (even if we failed miserably), let's have an hour of fun!

Given such strong sales pitches, seeing only benefits, and given the fact we had no say in it, we said yes.

And so the story began...

Till nextime!

The Scrum'em Bear.

Welcome aboard!

If you read this post thus far, two questions probably came to mind:
1. Who?
2. What?
3. Why (well, it's a third one, but it came anyway...)

I'll try to answer both (or troth) with this post...

Hop right in.

Age of darkness:

- For more years that I can count I’ve been doing different variations of the same role, which is walking the fine line between developing software and managing a team of software developers. 

and for more years than I care to admit the dynamics of work was a bi-polar one, hence -

- periods of nothing clear to do, and a big project being managed somewhere. (dunk, write some sample code that will maybe be useful some day, tetris, minesweep, coffee-breaks)
- periods of panic: either the deadline is too close (have we implemented all that is needed? why doesn't this work?, the ship is 'bout to hit the fan..) or tons of support cases piling up.

At both cases, the feeling was that we are not doing what we should, someone up there must have a clearer idea of how things should run, but we are expected to swing it.

Gantt-charts were a nightmare to use, since dependencies were always moving and reappearing, and ms-project … well.. don’t get me started...


Let there b lite!
And then at one place I worked a decision was made to start developing in another fashion, there were rumours that the development procedures would change, and as someone who hates bureaucracy all I had to say was, oh shift.. another document set to read, more forms to fill, and just more mis-communication between the top floor (BTW - why does management always have the top floor?!) and the people really doing the work.

But you know what? this time the idea was actually a good one! 

the direction was how to increase communication, how to not do redundant work, how to have good close visibility of what is required, and how to (as the good book said on the back) NOT PANIC!

And the name of this new thing was: …
.
.
.
I’ll tell you next time.
(but I can hint is starts with an ‘S’ and end with a 'CRUM')

till nextime

the Scrum.m.bear