I’m very happy and excited that I’ll present the Lean Lego Game at the Agile Australia 2011 with Frank. The game was created by Danilo and Frank who have presented it at several conferences all over the world.
1 month to go and looking forward to it… 
Stand-up Meetings are a simple, yet effective, way of getting teams to communicate, commit to short term goals and solve problems. There is a proposed format for stand-up meetings which suggests that each team member should provide answers to the following three questions:
Have you ever done that and eventually it turned out to get pretty booooooring? I have… Countless times…
Yesterday/Today Stand-Up Meeting (Traditional Proposed Format)
The Yesterday/Today format is a good way to start with, do not get me wrong. I think it’s very important for teams that are not used to communicating daily to start with that format. I just think that we should always look for improvements as opposed to just following a pre-determined format… Recently we have been trying something a little bit different and it turned out to be much more effective, I’ll explain why. Jason Marcotte coined the term as the Walk the Wall Stand-Up Meeting, I quite liked it.
Basically the sequence of the stand-up meeting is determined by our Story Wall. Each item on the wall gets discussed taking into account the 3 questions mentioned before. Martin Fowler reminds us on his post to “Focus on the Backlog” and this is what this new format is all about:
Walk the Wall Stand-Up Meeting
Here are some of the issues that we are addressing by doing the Walk the Wall Stand-Up.
During the Yesterday/Today Stand-Up we noticed that each team member ended up talking alone and in sequence, usually there were no discussions or quick Q&A. That defeats one of the main purposes of the stand-up, which is communicating. I found a word that describes what we were experiencing: Soliloquy.
Walking the wall allows more than one team member to talk about something, e.g.: explain what they were working on yesterday. It could be that they were actually pairing on that particular item and have similar things to say about it. It also allows people to talk to each other about a particular item (Story, Task or anything on the wall) that is relevant to the entire team. After implementing this we had developers/ba’s/testers talking more about a particular item.
But…
Keep an eye on the quiet members of your team… One of the good things about the Yesterday/Today stand-up is that everyone gets to say something, which empowers and therefore motivates them. The facilitator should perhaps ask direct questions sometimes.
The three questions above suggest that each member has to explain “what they did” as opposed to “what they achieved”. This leads people into explaining the “tasks” that they executed, as opposed to “goals” that they achieved. E.g.: “Yesterday I went to meeting A and I wrote document B and I paired with John on story D”. There’s a lot missing there:
We see those discussions happening when it’s focused on the stories. It is easier and more likely that someone will mention that “In order for me to finish Story A I need help from a BA” for example.
We also learnt that it helps to have a facilitator during the the stand-up just like we do with retrospectives.
Walk the Wall Stand-Up Meeting with Facilitator
But…
We have noticed on our current project that during retrospectives people usually raise good and bad things from the last days only. At the moment we have a 3 weeks iteration and it’s hard to remember what happened on the first days. I have already used from 1 to 4 weeks iteration and each project has its own reasons for choosing this length. To help the team improve around things that happened during the whole iteration, we have a box called the Future Retro Box, where people can all keep adding notes throughout the iteration.
The reason why the box is called Future is because it will be opened during the next retrospective. The items inside the box will bootstrap the retro wall when people can add other ones.
Make sure the box is in a visible point of the work environment.
Another option would be to have an on going retrospective wall, as suggested by my friend Lachlan. However, this might work better for a co-located team, we are distributed. We tried using a wiki for that… It didn’t work… No one adds comments to the wiki… Why? Perhaps the wiki is a Refrigerator as opposed to a Radiator. The box has been working fine so far. The notes are not visible, but the box itself is.
Although we should avoid as much as possible Technical Debt, most of the projects end up incurring some of it. However it is important to know “how much” we owe and how much interest we are paying.
Know your debt
Recently on our project we did a Technical Debt Retrospective. Basically we brainstormed on the wall all the Tech Debts we thought we had incurred since the beginning of the project. Then we decided to categorise them by Effort and Pain:
“The relative effort that the team would have to spend in order to pay this debt.“
“Pain is the direct impact on productivity that this debt causes. (interest)”
Keep paying down the principal, not only the interest
If we do not pay down the principal of our debt by refactoring our code we will always be paying just the interest, which means reducing the productivity. The question we asked ourselves was “Which ones should we pay first?”
Looking at the four quadrants of this wall we can identify which ones we can pay so that we can have the highest return.
One interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.
After the retro we kept the Technical Debt Wall next to our Story Wall. From that day on it should become an ongoing wall that we will keep an eye on… Paying whenever possible…
My colleague Jason Yip posted some very interesting thoughts on roles and hand-offs and I thought perhaps I could express them with some images… As I really like images better than words.
Jason mentioned that usually this is what happens:
They miss the point by assuming this is enough:
“We’re not just re-ordering hand-offs, we actually want to remove them.” (Jason Yip)
Prioritization is crucial for a project to succeed. We need to make sure that we deliver what’s most important, what adds more value. The interesting and most challenging part of this is when we have to ask the business (client, product owner) to prioritize items. By calling them items I mean they are not necessarily stories, features or a product backlog. Sometimes we want to prioritize needs, purpose, goals and outcomes as well. The way we ask them is the trick…
I’ve seen many different ways of defining the priorities and usually there are ranges involved, sometimes with labels or numbers, like:
There is nothing wrong with creating the labels, but when we ask the priority of one item only, that’s what happens sometimes:
How do we understand business priorities
The most effective prioritization exercise I’ve seen was to give the business a randomized list of items we want to be prioritized, then we ask them to give us the X most important items. And these will be the ones considered during the next timeframe. We should always let the list visible to the stakeholder who is prioritizing… It has to be clear for him that he is giving up on items in favor or others… at least for the next timeframe, which could be the next iteration of release.
It’s like a son’s birthday gift…
Good parents apply this rule with their children. Let’s say it’s close to my son’s birthday, I don’t have a son, this is totally hypothetical :), but my mother used this rule with me… So, I want to buy him a gift, ONLY ONE, of course, because I’m not the kind of dad that gives everything that my son wants. So I have a list of gifts that I know my son wants. Bike and video game are top of the list, but I can give him only one now, because it’s his birthday. We all know It’s close to Christmas (next iteration/release) and I will give him the other one on Christmas, but now it’s his birthday time, only one gift… I, then, make sure that my son understands the one gift per event rule and ask him which one does he want as his birthday gift… As a clever boy, he will think carefully which one really matters more to him because it’s clear that he has to give up on one in favor of the other. He will not give up on it forever though, it’s just until Christmas (next iteration/release), however, he knows that one of them will be bought and received first, and the other will come later…
As I said, there is no problem in defining labels and priority buckets, the only thing we have to bear in mind is that whenever we ask the business to prioritize items, we do not ask them in which bucket he wants to put one single item. And that’s when the principle comes.
Principle of Relative Priority:
One item by itself is usually important, otherwise it would not even be in the wish list… If I ask my son:
But when they have to CHOOSE… That’s when the most important items are picked… And during times of crisis, like now, with budgets constraints, we don’t even know if we will be able to afford a Christmas gift, so let’s make our kids happy during their birthday…
DRY is a concept applied quite broadly in code. In a web application it’s also important to extrapolate its use to the view layer (MVC) in order to increase clarity and consistency.
At the end of this post I’ll explain how a user story that had to be delivered became much easier to implement because we had a dry and refactored view.
Concrete example of a view pattern being refactored and dryed
As I usually try to explain things by example, I’ll show a JSP that can be refactored and dried. Please notice that the idea of refactoring and drying your view using conventions is technology agnostic and can be achieved with other languages and frameworks as well.
Let’s say we have to implement this form:
The example below shows one way of implementing the aforementioned form using Spring MVC JSP tags.
The convention used was that the default label will be label.${id}.
Tag Files and Conventions
If you want to know how to create your own JSP 2.0 tag file, like the one created above (form-ext:inputText), here are a few tutorials.
But always remember about the conventions over configurations.
Here is the file that was used to implement form-ext:inputText:
You can download it if you want: inputText.tag
If the user of the tag (inputText.tag) still wants to send the parameters label, size and maxlength, they would be able to do so. They are not required and have default values, though.
Basically if you apply these two concepts (Tag Files and Conventions) you can dry your JSP’s… But you have to identify the duplication patterns.
Extract Tag File - A view refactor similar to Extract Method
What was shown above is a step by step of a refactor that I call Extract Tag File. It’s quite similar to extracting a method, but instead of code, we have JSP.
I wish the IDEs had this refactor implemented … Who knows someday… Or maybe we could write a plug-in for Eclipse or IntelliJ.
How we applied this on a real project to deliver business value quickly
Recently, on my current project, we had to change the way the error messages were shown to the user. They had to be field context aware, which means that if there was an error related to the field “Given Name”, the error message had to be show next to the field.
This is what we had before:
This is what we had to implement:
Can you imagine how much easier it was just because we had our DRY VIEW? Our fields were wrapped and, therefore, it was just a matter of implementing this inside the tag file…
That’s what we aim… Deliver business value quickly!!! Happy client… Happy developers…
We have adapted on our project James Crisp’s cool idea about changing the color of the command when the build fails or passes… Now it works for maven
mvncool.bat file
@echo off color 07 call mvn %* IF ERRORLEVEL 1 goto RedBuild IF ERRORLEVEL 0 goto GreenBuild :RedBuild color 4F goto TheEnd :GreenBuild color 2F :TheEnd
It’s quite similar to the one that Crisp posted, so thanks Crisp for the interesting and reusable bat file.
Some small things are different for maven though… Check them out.
Step by step to have it working on your maven project:
Before mvncool
mvn clean install mvn package mvn (anything)
Using mvncool
mvncool clean install mvncool package mvncool (anything)
During the Release Planning phase of a project we usually estimate and prioritize the MSL (Master Story List), also called Product Backlog in Scrum. The output of these exercises is a Release Plan which contains a vision of Time, Cost and Scope of the project. This phase usually happens for the first time during the inception, before the project starts. It needs, of course, to be constantly reviewed and recalibrated in a more fine grained level of details once the project is underway.
One of the main things we need to keep in mind at this time is that these are ballpark numbers.
Definition of Ballpark: A good numerical guess; an estimate.
In order for the decision makers to have an idea of these three variables (Time, Cost and Scope) and then make a decision whether to start the project or not, taking into account mainly ROI (Return on Investment). Most of the time they need these numbers for budget approval so that the project can start. The numbers are not precise at all and they will change for sure when the project starts. But as I mentioned before, they are an estimate, something close enough to the real numbers.
We should only spend enough time to get to a comfortable stage where a decision can be made to take the next step.
One of the clients I’ve been to had a very good way of deciding about funding approval according to the output of the release planning. They knew the numbers were not precise so they had a form with:
How long is the project going to take?
How much is the project going to cost?
The main point is that it’s useless to try and figure out whether the project will take 30 or 35 days at this time, of course we need funding and budget allocation, but nothing stops us from allocating X amount of money, try it and then continue if it works.
“Don’t aim too much before shooting, shoot and then adjust and then shoot again and adjust…”
Sometimes it is good to remind ourselves about the obvious…
“9 pregnant women CAN NOT ‘deliver’ one baby in 1 month.”
To understand the metaphor imagine:
