Eric Lefevre-Ardant on Java & Agile

Many people have asked me to talk about the A4 Reports that I have introduced on one of our projects. I’ve postponed this for a look time, but I finally got around to do it.

The idea came from the book Toyota Way, by Jeffrey Liker. At the beginning of the book, the author warns the reader against a classic trap: after reading about the success met by Toyota, many want to implement their practices verbatim. Well, my philosophy is that, if I got only one useful practice from the book, then it was worth paying for ;-)

So anyway, the author is telling about the fact that Toyota employees do “A3 Reports”. The idea is that, when there is a problem, after careful thinking, the people in charge produce a report that fit on an A3 page. The reason for this constraint is that 1) is it quick to read, 2) it can be faxed around the company with the fax machines they have.

Another thing is that they tell about the problem and the solution using Plan-Do-Check-Act (PDCA). Which means that their reports typically contain:

• a description of the problem
• an overview of the possible solutions, including options that were later discarded
• a description of the implementation of the solution on a limited scale (Plan & Do)
• a description of what needs to be monitored, and milestones (Check)
• if the solution is proving a success, a description of the implementation company-wide (Act)

I was personally attracted to the reports, because they force the writer to keep the information concise, though readable. Graphs were good too, as long as they make the contents clearer to the reader.

My personal problem was that, as a ScrumMaster, I have to produce reports every time we complete an iteration. The reports are boring to write, probably boring to read, and they were getting longer as the various stakeholders regularly demanded that I add more information. Other metrics that had to be maintained included productivity, progress on project, etc. I felt that these metrics were not very useful and I had also been getting into arguments with my boss’ boss, especially after a steering committee where it had become clear that I couldn’t make the situation easily understandable to our clients, even with an Excel document containing 6 sheets. So I was feeling some pressure to show goodwill, and to produce something that was actually useful.

One day, my direct boss demanded that I produce not only my usual textual report (generally 2-page long), but also a 10-slide PowerPoint presentation. I was underwhelmed, since I already felt my report was not that useful. I got her, though, to agree that, in addition to what she wanted, it’d be worth trying those shorter reports.

I set myself the following constraints:

• must fit on a single A4 sheet, as this was the only format of paper supported by our printers
• character size must stay at 12 points for normal text; text that was part of graphs just had to be “as readable as I could make it”

The result for the first Sprint to have an A4 report is the following (in French):

Things of note:

• the 3 columns; they are the key to fit as much text as possible when you have many bullet points
• the charts, especially the burndown chart. This was the first time I managed to show the burndown chart in a readable fashion in a report to people external to the team.
• the content, which is made largely by the information gathered during the iteration retrospective

When my boss saw this report, she was delighted. It became the main document discussed during steering committees between the various stakeholders, including the CEO of the company. I also sticked it to the walls of the development room, in full colors.

In later iterations, I refined the report a bit, but it stayed largely the same. For a few iterations, I had a tendency to change the charts, depending on the situation (for example, if speed of development was an issue, I’d add a chart showing the number of actual work days per iteration). I have found that it was not as necessary in later iterations. Probably a good thing, as I would not be able to gather all the data necessary.

Here is how it looked in a recent iteration (in French again, so it might be hard to figure out what each box is for):

How I build the report:

• The report is built using Excel. Some charts come from external sources, such as the burndown chart which I extract from the Google Spreadsheet-based Sprint Backlog; an issue is that, being images, they are hard to redimension. Other charts come from separate Excel files, which is a bit annoying as Excel suggests pulling data from the other Excel files every time I open the report. Finally, some charts are made from data that are hard-coded in the same Excel file, such as velocity and code coverage.
• A lot of information is actually coming from the Sprint Retrospective. I can prepare a few things before the retrospective (mostly the charts) but much of the data is mined from what was learned during the retropective.
• I spend quite some time adjusting the boxes on the sheet. The best way I’ve found is to use drawing features from Excel that let you perfectly align or center elements together. Still, it takes significant time to clean up at the end.

For your information, here is a list of the noxes used in the last report. You will want to adapt this to your needs:

• Sprint Number & Dates
• Implemented Features
• Features that Were Not Implemented
• Important Facts from the Sprint
• Burndown Chart; this is now coming from a Google Spreadsheet ;-)
• Statistics on bugs
• Things We Could Improve Upon
• Things We Are Happy About
• Actions For Next Sprint
• Project Trends
• Velocity
• Overall Progress on Project
• Overall Bug Statistics
• Code Coverage By Tests

I hope all this will help. Let me know your improvements on my design!

Well, it took 5 long months, but I can finally honestly say that we are doing (some) Scrum things on my current project.

I joined the project in February this year. My first idea was to convince the project lead that Agile Is Good ™, but I quickly gave up, especially since he had made clear in pre-assignment talks that he was rather skeptical.

I then resolved to do whatever I could on my side. TDD, some Continuous Integration, some rare Pair Programming… all good stuff, but my heart was not into it (except for TDD).

Then, just a couple of weeks ago, I was joined by another consultant colleague who had agreed to the assignment because we would be doing Agile stuff. Finally, we did real Pair Programming, real Continuous Continuous integration, and still real TDD.

(more…)

This week, Jean Tabaka from Rally Dev came to teach Scrum to my colleagues from Valtech. In the evening, she gave a talk on her book, Collaboration Explained.

I have been very impressed by Jean’s easy-going personality. As most people had left the office, I was still hanging around with the boys for a few more minutes when Jean came over and ask if there was anything left to drink. Well, our resourceful Gian managed to find 2 bottles of red wine and the party went on till 10pm.

This is very much in contrast to the only other ScrumTrainer I know, Craig Larman, who I think can be fairly described as “frugal”.

Once issue that we have with our customer is the definition of iterations. They want us to work with 6-week iterations, and release a previously-agreed scope at the end of the 6-weeks. The reasons for this according to them is that they need that long to run all the test cases they have (note that this development is a re-implementation of an application developed in Forte; all the specifications and test cases are already available and reasonably stable). At any rate, it does not break Scrum rules too much, so it should be alright.

Anyway, they do not mind us having shorter iterations. So we took the liberty to arrange the external iteration into three 2-week internal sub-iterations.

Problem is, how can we arrange the Iteration Backlog and still make things clear for the customer… and for us?

A first attempt has been to create new Excel tabs for each sub-iteration. So we would have 1 ‘backlog’ tab and 1 ‘burndown’ tab for sub-iteration 1, same thing for sub-iteration 2 and 3.
The issue that rose was that it became difficult for us (and for the customer) to understand what was going to be implemented in the external iteration. Say that the customer wants to check if a particular feature was going to be implemented. He would have to go to the first ‘backlog’ tab, then to each of the 2 other ‘backlog’ tabs. In practice, of course, he would stop after the first tab (I would too), and complain that we promised to do things and did not even list them.
As it turned out, the 2 other ‘backlog’ tabs did not contain this information. The person in charge of creating this Iteration Backlog had thought that things would be pulled from the Product Backlog during the Planning game for the other sub-iterations. Well, maybe so, but it is not making clear to the customer what we are hoping to implement in a given external iteration.

So I have suggested to rearrange the 3 tabs into a single one. The 1st tab would remain as it is. The 2nd ‘backlog’ tab would be copied just below it, in the same fashion as the ‘finer grained’ section in the Product Backlog, except that it would be called ’sub-iteration 2′ instead of ‘finer grained’. The 3rd ‘backlog’ tab would go further below. Maybe we could keep the labels ‘finer grained’ and ‘coarser grained’ as sub-titles for those sections, until we get in the middle of those iterations.

I think this allows everyone to see easily what is going on, while still capturing the idea that the later sub-iterations still need to be analyzed in the planning game.

Today, I organized the first Sprint Review for our project. This was not something that we had planned in advance. I did mention it a couple of weeks ago to the people in Valtech, but I did not take the time to tell the customer in advance.

Anyway, the delivery had been made the day before, and I thought it would be a good, Scrum-friendly idea to get the customer (that is, their Project Manager, plus the testing team) to look at our application in a controlled environment before they start playing with it on their own machines.

For this, I contacted 3 people outside our Team, mentioning that any other people would be welcome:
- their Project Manager (not a Product Owner)
- our own Project Manager (not a ScrumMaster… but could be called Delivery Manager, though there is another person who might be with that role on our side)
- the head of the client testing team (you would call him the Product Owner; we consider him that way, though he does not know it)

The reaction:
- our Team (3 persons) agreed it would be useful to give it a try
- their Project Manager liked the idea, and mentioned that he would join, but didn’t
- our Project Manager didn’t mind either way; by chance, she was in the room at that time and kept a distracted ear open, but worked on other things
- disappointingly, the Head Tester (our Product Owner) was not interested at all. He kept refering to the fact that any live demo will not be as committing as the Release Notes and other documents. I did make the point that it would make it easier for us to convey information, and also that we will happy to have a live reaction on our work (I didn’t say that it might also make it easier for us to make them swallow some shortcomings). Still, he didn’t care. However, he did talk with the other 2 people in his team, and they agreed to come over.
Important note: this Head Tester (”Testing Head”? ;-) ) is *not* an employee of our customer. In fact, he is himself an external contractor, which must explain why he is being this rigid, by-the-book (or rather by-the-contract) guy.

The setup:
- our functional champion took over a computer that was not used for his tests. This is because the official test machines (target systems in the contract) are in fact painfully slow and we thought that they would not show the application in a good light. Also, another problem is that the Contract signed between the customer and us still referred to obsolete computers that are now being retired. So the actual computers will be much faster than the ones provided to us by the customer. Note that the testing team also uses these new machines.
- our functional champion was sitting at this machine.
- the 2 guys from the test team sat behind him.
- I got caught into looking at other things by our Project Manager, though I did manage to keep an eye on the demo most of the time.
- the last member of our Team was following the demo, standing behind (in fact, the functional guy was using his desk, so he had no choice but to watch).

The demo:
- the functional guy basically went through all of the implemented screens, commenting quickly on what had been done, and what was still missing (all information already in the Release Notes). Occasionally, the rest of the Team (the other guy and I) stepped in to provide more details that were being forgotten.
- the test guys asked about a few features that they were interested in, with a slightly derisive tone on their voice. That was not very pleasant. That said, it is probably an improvement, compared to them criticizing us on their own (presumably).
- one or two screens failed to open, which was a bit of a blow to our self-esteem.
- at the end, we asked a couple of questions, not directly related to the delivered application
- in total, it took about 30 minutes

Was it useful?
- well, most of the developers were actually missing, since they are based in Bangalore. So it certainly was not very useful to them.
- one key person (the PO) was missing.
- I believe it did help in creating a link between us and the testing team, making them ‘feel’ for the fact that they are now taking the baby in their arms
- since it is taking not very long anyway, it’s worth trying again

Possible improvements:
- get the Product Owner to come (maybe he will come by himself next time, depending on the feedback from his team)
- make the offshore team more involved by keeping a webcam open for them to see how it goes
- I sent an email to the guys who did come over (with the PO and Project Manager in copy), explaining why we did that demo, and why we’ll do it again at next delivery. With a tentative date.