Speed tells us how much distance we cover over time, and velocity adds to this by giving us a direction as well. If we don't arrive at our destination on time, that can be for a few different reasons. We might not be driving fast enough, we might have spent some time going in the wrong direction, or we might have spent some time just parked by the road and not driving at all. Jason Yip helped me clarify some ideas around useful measurements on an agile software project with this example...So my mate Con the courier didn't last long in his job. His boss asked him to drive a package from Melbourne to Adelaide, a trip which takes about 8 hours (if you go straight there). Three days later, he turned up with his delivery, and the boss was fuming."My Grandma can drive faster than that! What happened!"Of course, Con had a different story. He showed his boss the trip meter in the car, which distinctly showed an average speed of 110kmh, 10kmh faster than the average of the best courier drivers. However, the boss also noticed that the total distance was about 2000km (its only 800km between Melbourne and Adelaide)."2000km! Bloody hell - did you come via Timbuctoo?!"Con explained to his boss at this point that he had in fact come via Sydney, not Timbuctoo as first thought (silly boss), and whilst he was there he had worked with a specialist to build a steel framework in the car that would enable it to carry loads of up to one tonne, should the courier company ever need it. The boss obviously had no argument for this logic, but was still confused about the timing."Even if you did come via Sydney and soup up the car, it still should've only taken two days. What happened to the other day?".The boss had obviously forgotten about the regular meetings that had been instated by the parent company. Con pointed out to his boss that he had to stop driving twice a day to attend a couple of one hour phone conferences about car maintenance and planning for new courier routes.Cons boss seemed somewhat flustered by all of this, and was actually quite annoyed by Con's arrogance. He said nothing more at the time, but a few months later, Cons contract wasn't renewed...I see examples of these scenarios every day on agile software development projects.The programmers are inevitably pretty good at what they do. They work hard, and can produce working code quite fast. The amount of time they spend at work is the Project Speed, but the time they spend actually cutting code is their Programming Speed. The difference between these two figures is the Non-Programming Time, and if it's large could mean that, like Con, the developers had to stop driving to spend time in meetings or other activities.Most of the time, the developers are producing code that actually works toward some feature that the customer has asked for. This is their Velocity. The difference between Programming Speed and Velocity is the Non-Velocity Programming Time. Some of this is legitimate (like producing spikes for example), but developers can also be tempted to build unecessary things too (like Con did with his stell framework in the car).All of these metrics can tell you something useful about a project, and they can be quite easily measured as well. Metrics also provide you with great power in influencing (appropriate) change, and can help prevent against knee-jerk reactions like "the programmers aren't working hard enough" when in fact they are actually just spending their time in meetings.Perhaps if Con had measured his facts and just shown the log book to his boss, instead of using his "I know better than you" attitude, he would still have his job today...
We have a bunch of different events that occur at regular times throughout the iteration on our agile project. Daily Stand-Up Meetings being a classic example. One of my colleagues, Perryn Fowler, has seen fit to delve into his library sound grabs to provide with a musical reminder of whats coming up...It all started a few weeks ago, when Perryn worked on a particularly long and drawn out task. A bunch of tests were broken as a result of the work being started, and Perryn slowly clawed his way back to a working build with his new features in it. It took a few days all up, and we were keen to integrate the work. When it was finally time to commit, we heard a song being played from Perryn's desk with the following lyrics:"I'm checkin' in.""He's checkin' in.""I'm checkin' in.""Checkin' chekin' chekin'."This is, for those who don't recognise it, is from the Simpsons episode "City of NY Homer Simpson" where Marge, Bart, and Lisa see a broadway musical in which a celebrity checks in to the Betty Ford Clinic.At the stand-up meetings this week (which people generally don't get too excited about being first thing in the morning), Perryn again decided to pep up the team with a tune. On Tuesday morning, we had a tune from "Caravn of Love" by the Housemartins:"Every woman every man""Join the caravan of love""(Stand up) stand up""Stand up""Every body takes a stand""Join the caravan of love""(Stand up) stand up""Stand up"Then on Wednesday morning, Perryn went for some Bob Marley:"Get up, stand up: stand up for your rights!""Get up, stand up: stand up for your rights!"We've had great success with our musical introductions so far, and are on the hunt for more tunes to show events during the iteration.
The department I am working in at the moment is moving floors. I've made enough noise about optimising are physical team layout in the past that the programme manager asked me to plan it.We had 20 seats in all that I had to fit the following people into:
1 Programme Manager (part time)
1 Project Leader (part time)
1 Release Manager
1 Business Representative
1 Developer/Iteration Manager (me)
1 Continuous Integration Machine
I was basically given the option of making the final call, but there were a few guidelines that our programme manager wanted me to try to follow:
He wanted to sit near his boss (who was adjacent to our area in the top right).
The "management" types on the project should be near each other.
The business representative should be near the other business staff (adjacent to our area at the
The developers should be near the other development teams (adjacent to our area at the left) to allow for fluctuation in the team size as the project went through various phases.
Department ettiquette said that senior staff (we have three of them on our project) should be offered the window seats first.
In addition to these guidelines, I came up with a couple of my own:
Three of the developers were supporting another released project part time. They needed to be close to the project leader (he was responsible for that other project).
I wanted the development team to be as close together as possible (in a "pairing zone") for day-to-day work to maximised communcation. That meant seating 100% allocated staff in that area and putting our best computers on those desks.
I wanted the senior staff to have desks next to the pairing zone to achieve ExpertInEarshot.
Phew! That was a lot of things to keep in mind for a seating layout. Just to make things worse, I had one final card to play. I wanted the entire team to get together and agree on it. One of the other management types told me I was nuts, but I did it anyway.So I drew our floor plan section up on a whiteboard and wrote everyones initials on a post-it note. Then I gathered everyone together and told them all of our guidelines. I immediately had a couple of issues come out which I noted on the whiteboard to keep in mind. We needed a baseline, so I started by putting all of the developers (our largest group) on the plan. Then I fitted in people at random around it.This baseline brought up a lot of discussion. People could now see exactly where they might be sitting, who they were next to etc. However, it was actually very close to our final plan. The main discussion was around the shape and location of the "Pairing Zone" on the layout. A vertical shape put developers the closest together but didn't work with the window seat ettiquette. A horizontal shape on the left was good too, but didn't allow us to have senior staff and management nearby at the same time. We ended up compromising by moving the zone to the right a bit, which meant it had a walkway up the middle, but we could achieve all of our other goals.A few minor shuffles later with input from management and everyone agreed. It only took about 20 minutes - amazing!Shortly after the meeting I made one shuffle to move myself to the edge of the developers and the managers, but went and told everyone. No complaints. The programme manager (who couldn't make it to the meeting) also made one minor change where he swapped to of the senior staff (they were sitting next to each other anyway). Now everyone affected had had input to the seating plan.
I've spent a couple of days worth of effort now setting up my first serious website (this one) from scratch. With any luck some people might find some useful information here that helps them out. I've learnt a bunch of stuff along the way.The design I basically made up using a combination of features I've seen on other web sites, plus a bit of experimentation. The intricacies of cascading style sheets was unfamiliar to me when I started, but now I'm at least a novice user... The blog is run by greymatter, an open source perl project. The wiki is a customised version of JSP Wiki which is obviously a JSP based product - again open source. I've used the wiki many times before on various projects and find it very easy to use. The rest of the site is just plain old html.I think I've got a lot more to learn, but so far I'm happy with how its turned out. I'm looking forward to learning a whole bunch more as I use the site in anger.