The Scrum Manager course is an approach to scrum that is different of everything I readed before. He focus in the management part, in how to manage your company / department and the relationships of them. All the books I readed in the subject focus in the scrum process himself or, at most, in the project management aspect of the task. Juan gives us a new point of view in management: applying the agile principles to the company as a whole.

While I was listening his speech, it occurs to me that I was doing something of this intuitively, as most of the scrum practices we do before even know what’s agility. This makes me think about a subject that was not investigated yet, the interaction between scrum packs and other groups organized with “traditional” approaches.

As I see, this is the next step of agility, in a path that is yet unknown but promisses much much more.

I’ll continue tomorrow, after the end of the course, and I hope I can publish some pics too.

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

If you have made mistakes in the estimations, you correct them, hopefully early thanks to the burndown chart.  If you are slowed down because you lost a team member, the solution is the same: reestimating and reasigning tasks. But there is some situations when this is not enough.

One monday evening, the working site burned up. Yes. Totally. Computers. All the paper, the scrum board, all the information in paper, everything. The fire is a very good evidence eraser!

Where I live, is not common the offices have a fire extinguishing system, or even a smoke detector or fire alarm. This is a really valuable lesson that we learnt, at a horribly cost. The feeling is something unexplainable, terrible, as I take out some computers with a shovel, from the floor. A stain in the floor and some carbonized wood is all that remains of my workstation, the place was totally black, walls, windows, everything black and with a obnoxious smell.

Now, two weeks ago, I can sit down and write this recap of the work done in order to reengage the work, the team morality and the “flow”.

As always, the customer is first

After extinguishing the fire and see that nobody gets hurt, the first thing I do is tell the customer of this. This only action have two effects: one, the customer was grateful for being informed, and predispose him to help in anything we need. On the other hand, give us some time to recover the software process (and the hardware). The hardware costs weren’t so high, and we can cover it without problems. Fortunately, we have a backup account on dreamhost that allows up to 50Gb, more than enough to save the company software assets. We have on-site backups also, but they burned up to ashes too, along with all the hardware. We can assure to the client that his project will not be delayed so long, and with the organization that scrum gives us, we are convinced enough that we were not lying.

The right people for the job

An important lesson that I learnt a long ago. Don’t try to repair the things yourself, don’t put your people on repairing, scratching walls, painting, or even installing the operating system (except that the want to). Convert this weakness in a strenght, giving your people a couple of days off. This will, again, give you two important benefits: one, you avoid that the people see all the reconstruction  work, believe me, is exhausting just seeing it. And, you get the morale increase because of the unexpected days off.  As soon as possible, hire some contractors to do the job quickly, and use some parts of scrum to manage their work:  came to the site, ask them what they are planning to do today, watch what they had done, and ask them if you can help in any way. Scrum if shmantastic!

The importance of the off-site backups

You don’t appreciate the value of the off-site backups until you have a contingency like this. If we haven’t got this automated backup, we probably lost some valuable information. It seems that the more recent information generated in a project is the most valuable (is this the time for a barroso’s law ?). As we have an automated script to make the rsync backup with the backup server, we havent lost a bit! In addition, you need to have a recovery system that is easy to operate. In my case, I haven’t seen this obstacle until I need the recovery. Anyway, it was just a rsync script et voilà, all the information in place again, but if you can, have this part of the backup automated too.

Team (re)building

Now is an excellent chance to redecorate and refunction the place. You always wanted pouffes ? Small, japanese-style tables ? Pink in the walls ? This is the time of your inner-decorator (not @decorator, though). But this is the moment where the good managers separate from the outstanding managers. Call your team, all of them, and give them the power to decide in the rebuild. Remember all the bibliography about lowering the people turnover ? This will give your team members the opportunity of create roots with the place, and for transitivity, with the company. Remember that your biggest asset is your people, and investing in them will always give you the best return.

Prepairing the return to work

Now that all the furniture and hardware is in place again, let’s talk about the software. Reclaim your backups in your servers, and give your team a day to customize their work environment.  This is not a lost workday, they will spent more time customizing their desktop environment in between the job, distracting them, etc. so allow a day for this.

Call your customer(s) and organize a meeting.

Go!

It’s 08:00 am. You and your team are ready to start the work, but has been so long (a couple of days can be a long time) that nobody remembers what to do. Your new, shiny scrum board is there, but empty. What now ?

I don’t know what’s the right answer, I’ll tell you what I done. Having the customer representative in place again, we started to renegotiate the iterations, the release plan, and anything else affected. We have lost 10 work days,  if you have like me a two-week iteration lenght, this means a full sprint. Considering that the event happens in exactly the middle of the sprint number 3, and we are making a sprint plan in day 6, so we have 4 days of work left. We decide to make a small sprint instead of time shifting. I have commented in another post that we use 2 week sprints, with the sprint planning the first monday and the demonstration in the last friday, giving us the saturday (yes, we work on saturdays, but very lightly) in between to make the sprint post-mortem.

That’s all you need to back on track again. Hopefully, the next planning meeting will be a success, and start the exact day you planned it in the project begining. If you have a good product backlog (and if you are reading to this, you have one), the planning meeting wont have any problems, and everybody will forget the incident in one, at most two sprints.

Conclusion

I hope that this text could help you if you have a situation like this. Even if you don’t following, the recommendations here may save you a lot of money and / or give you some good ideas with your team. I learned a lot with this, but the cost is terribly high, even with the added gain on team strenght and diminished turnover.

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

This will be my diary, where I’ll write all my experiences in this journey, and I hope several things more.

To begin, lets speak abot the negotiation: in order to change some of the corporative manners, your boss / managers must have a lot of confidence in you, because this looks like a big step (and indeed, it is!). In my case, the only point where the managers get a little nervous was when I say that we will not use gantt charts to track this project. The bosses then ask me some method to know what’s the project level of success, then I show them the  burndown charts and explained it’s use, then they remained calmed (for now).

I’ve promised the first demo in exactly 7 days from now. Wow. I’ve been working in this since monday, so a first iteration of 9 workable days, 2 weeks seems reasonable to me.
I’ll be using plain paper to carry out the whole system, I’ve designer myself a scrum board, the history cards and the tasks post-it (not really post-it in my case, but small square pieces of paper). On monday I’ll start using the burndown chart updated to thay day, so the managers can remain happy until the demo presentation.

That’s enough for one day, I’ll continue soon…

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog