The fist of five

The fist of five sounds like an old kung-fu movie. But if you are new to scrum and your team has been failing to make their points for three sprints or more and you don’t have large stories of 13 points or more. You need to look at how you get the team to commit during the planning meeting.

Does the scrum master or project manager decide how many points should be achieved or are you using the fist of five technique?

This is the basic way it works.
You put the sprint backlog on the board and ask the team to do the fist of five.
No fingers mean – no chance.
One finger means – snowball chance in hell.
…(Two to Four is the warmer feelings)
Five fingers mean – hell yes we can.

If anyone puts up anything except a fist with five fingers you remove a story from the bottom and go again.
You only stop when the most pessimistic person says the team will make that number.

An achieving team is a happy team.

The role of the Agile architect

In the last week, I have been listening to a lot of reasons why Architects should not be involved in code. They don’t have the time. It’s not in their role description. They’ll get bogged down in specific applications. They should spend their time at a higher Enterprise level.

So through a full vertical slice, there is a point through which they don’t want to go as it is too far down. I suspect that this point is above anything that requires a knowledge of current technology and implementation thereof as it is based on documentation and models. These models are supposed to then enter the sprint as a user story where the Agile Architect takes over the responsibility of its delivery. So our architects are stakeholders and the Role of the Agile architect moves over to the most senior developer in the team.

For the rest of the discussion, I’ll give some points I and others think is important to an Agile Architect.
First is the 10 things that Tom Hollander thinks is important to an Agile Architect.

10. “Just enough” up front design
9. Start with a vertical slice
8. Just-in-time design each iteration
7. Trust your team… but be there for them
6. Write code!
5. Be involved in everything
4. Drive a culture of quality
3. Know when changes are required
2. Shield the team from external randomization
1. Write docs only if someone needs to read them

Nearly all these are also this post by Peter:
Architecture Is a Frame of Mind
The War Room Is Where It’s At
Listen First
Shepherd the Team
It’s All About the Code…

Peter is a little more direct and dismissive of the Ivory Tower Architects.
“The agile architect must understand the current state of the software and know where it is going. He must spend his time with the team and be involved in all aspects of the project. The days of the ivory tower architect, sitting in an office producing diagrams and documents that may or may not be relevant, are dead.”

The only thing I asked from our Architects was to be directly involved using Pair programming for the first vertical slice. So that they can have a closed feedback loop with the developers during the time when the trend for the solution will be set and the architecture concept is set and tested in the code.

During this first vertical slice a few trends are set:
The coding standards are started for the solution.
The first unit tests are written.
The first pattern implementation occurs.
The architecture becomes reality.

The trend for the whole project is set. A trend not easily diverted from. Bad coding standards set during this time are kept consistent until the project’s end. Lack of unit tests becomes an overwhelming problem until adding a new one becomes a nearly impossible task as the code simply doesn’t allow for it.

But I suspect that from the Ivory Towers perspective the lowly actual delivered software code is not really relevant or worth the time spent on it. Shame the poor maintenance developers and users can’t share this perspective.

The Importance of Retrospectives.

There is a big continuous improvement drive at work and the simplest tool for continuous improvement is the retrospective. It’s the reason we do one every sprint. So we can find out what is stopping us from doing things better. It’s so we improving things in our environments bit by bit. As a SCRUM master, I find Retrospectives as one of the most important tools to master.

But haven’t you found that after a few they end up being nothing more than a complaint session, or they simply don’t return anything to the team. No return on investment soon breeds apathy. The team just sit in the meeting because they have to do it because the SCRUM master said so. This is the time to do something counter-intuitive. Have a retrospective on the retrospective. Keep it short and try and get an action from it. Soon you’ll see why. It’s something you are doing in the retrospective making them ineffective or the same action appear unresolved over and over. And for the long-term improvement of the team, you’ll have to resolve them.

Try to do one today.