Reading through Scott Ambler’s recent results of his Agile survey it stood out that one of the least used practices was colocation. Common coding conventions were almost 4 times as popular and even pair programming is more popular than colocation. Fighting the facilities battle is still a losing battle many places.
After picking up a rugby ball over the weekend to use as a prop or talking stick I sprung it on two Scrum projects today. I just explained that the ball when you held the ball you talked and when you were done you passed it on to the next person.
On the first standup which is only about 6 days into it’s first Sprint I think it helped focus the conversations around what the team was working on and kept some of the divergent conversations down. On past standups the meeting had broken down to the point that issues were discussed, but the simple what you did the last 24 hours, what you’re doing for the next 24 hours, and any impediments got lost. It also appeared to help the focus from the Scrum Master to the team members which was really part of the point.
On the second standup today with a team that’s on it’s sixth Sprint the results were more mixed. This is a team that has standups down pretty well, but occasionally focuses on the Scrum Master to keep the flow of the standup moving. I was hoping to break some of that default behavior.
First they wanted to know who thought up the idea and I gladly acknowledged that I had over the weekend upon seeing one at a local soccer shop. I explained that the idea of a talking stick had been used on many other Scrum projects. At least two developers thought it was unusual enough to just lay the ball on the table when it was their turn instead of just holding it while talking. And one developer who’s more of an observer announced he would just ‘pass’ a very simple pun, as he handled the ball to the developer on his right.
Overall I think it’s been a fun experiment, but on the more mature Scrum project we might end up dropping the idea. Definitely something to reevaluate in the retrospective if not even sooner.
I’ve been a Getting Things Done (GTD) practitioner for more than two years now. For a simple overview it’s an organization system based around dumping every todo onto lists, organizing them into contexts and projects, and then reviewing on a regular basis to decide on the most logical think to work on right now.
Anyway my technical implementation has been with 37 Signals Backpack product for the past year or so and it’s worked fairly well. The pluses are:
- It’s internet based so I can get to it from my work and home machines.
- It’s good for capturing projects per page and adding related details.
- You can organize contexts by using special characters for the first character. For example all of my GTD contexts start with @, all my work projects have a minus sign and all of my home projects start with a >.
The main issue with it is it isn’t really easy to handle next actions, and you can’t easily tie an action in a context to a project action without resorting to duplication with cut and paste, and it can’t be searched well.
I’ve finally gotten around to looking at a product I’ve known about for some time–Kinkless GTD. It’s a series of Applescripts to turn Omni Outliner into a GTD tool. I had avoided it before because I can’t use it at work, but I’m exploring it again because it appears to allow you to actually have next actions and tie actions in context lists back to projects.
Not very far in yet, but it looks promising. The intro screencast is very nice.
I like the idea of leaderless standup meetings, but so far I haven’t found a way to pull one off. Pretty much everyone waits for the Scrum Master to start the standup and then keep the conversation passing around the room. Dave Nicolette mentioned on this in a recent comment:
Your choice of words caught my attention: “The tech lead was holding the standup meetings.” Ideally, no one “holds” the standup. The team stands up at the appointed time and they talk to each other. There is no leader as such, and anyone can get the ball rolling.
Two new ideas have occurred to me for some experimentation:
- Have some totem to pass around the room between each team member. Anyone can pick up the totem and start the conversation. I think a rugby ball might do well here. Kane Mar calls this a talking stick.
- Today I heard another idea from Doug Shimp on the Net Objectvives Lean Agile Podcast. This idea was to have the Scrum Master move around the room during the standup so the team members focused on speaking to each other and not the Scrum Master.
In a talk tonight at the SACJUG meeting Roman Hustad of Foundstone talked about a number of issues in writing more secure code. Luckily he comes from a coding background so much of the advice was a lot more relevant than the typical network security perspectives.
Foundstone has developed a couple of example applications to illustrate bad coding practices which include Hacme Books. He covered ideas like testing fields with a single quote character to test for SQL injection possibilities and something called a horizontal privilege attack. That’s an attack based upon gaining access to other users accounts with the same permission level so that you can steal there information or use their account. You might do this with a badly coded web application by simply changing the value of a user id URL parameter.
He mentioned two relatively recent texts on how to apply better security practices within a software development lifecycle. And both of the suggested books included ways to deal with it on an Agile project:
Overall a good introductory talk by a practitioner. One of his main points was that security was becoming something that you needed a few developers that specialized in so that you could keep a team up to speed on the newest techniques. Trying to make everyone a security expert just isn’t going to happen. And finally, a last point was that code reviews are a great place to inject secure software practices.