Visual Aids for StandUps

I came across this post about Agile mascots from Kane Mar via the Carnival of the Agilists.

Indigenous peoples have been running well organized tribal meetings for many thousands of years. One of the methods that they developed involves a token often called a Talking Stick. Traditional Talking Sticks are decorated with carvings, feathers or other items of significance. The use of the Talking Stick is very simply; only the person holding the Talking Stick is allowed to speak. When he or she is done it’s passed to the next person.

His examples are a stuffed pig and a Rugby ball. So far none of our Scrum teams have used this, but we have used two related devices to hold to the 15 minute timeline.

One, is to use a special pen where the ScrumMaster pushes a button and it flashes red if someone’s veering off topic or just taking to long. I have to admit though I’ve had it for one project I’ve never actually used it in anger.

Second, is that anyone on the team can do a timeout signal with their hands if a person is veering off topic for too long. This was introduced by our Agile coach and appears to work fairly well. The timeouts when they happen are taken in good humor and everyone gets a little laugh about it. I’ve also seen people call timeout on themselves when they realized they’ve started rambling.

The talking stick idea is gentle enforcement of the standup meeting principle to stick to 15 minutes, tops. I rarely have problems with people going over on this, unless its a larger team say 8-10 people in which case everyone pretty much has to get through their update in 90 seconds which can be a little hard. And the idea that no one else talks while someone has the talking stick doesn’t allow for people to ask questions or comment on someone’s update easily. My guess is that you don’t stick too exactly to this unless you’re training up a team new to standups and you want them to really get the 15 minute limit part first.

Climbing the Hill of Higher Quality Software Development

Some signs we’re cruising up the hill:

  • Another team of developers on an Aigle project, none of whom report to me, are writing unit tests. Even without much support they’ve plunged ahead and they’re making progress. The best part is one of the developers is very good, but also very skeptical of new practices. His only exposure to TDD was a one day TDD seminar I ran a few months ago, so I assumed it would take more evidence before he really tried it out. Pretty soon all of the web developers will be running test first.
  • In an architecture meeting of all things today we ended up talking about wikis and figuring out light weight code reviews. We usually debate some aspect of our SOA approach, but this time we talked about real development practices. And I actually have developers excited about code reviews of all things.
  • After instituting Confluence as our wiki solution we’re seeing a much larger amount of content go up per day at least 5-10 new pages. We also maxed out our 25 named users license as well today.
  • Some of our mid-level developers are really starting to shine as they’re getting beyond the learning curve with java, J2EE, and TDD. One one project we’ve seen a dramatic turnaround with a developer who was able to really step in and lead while the tech lead was out on vacation including pushing through a difficult configuration problem. On another the tech lead remarked the other developer is able to just run with their own modules whereas even a month ago they still needed a lot of mentoring. The developers are really stepping up to the challenge of self-managing teams.

    Different developers have taken the lead on researching, piloting, and bringing in new tools from Maven 2.0 to the AJAX script.aculo.us library.

The best part is just two years back we had about four java developers and twenty Coldfusion developers. A few of the Coldfusion developers had used Fusebox (a Coldfusion MVC framework), but most were developing typical Coldfusion applications. Two developers were doing unit tests. Some medium and small projects worked OK, but the large ones were pretty much all death marches with hundreds and hundreds of defects.

RSpec Updated

Playing around with RSpec again recently I noticed its undergone some major development in the past month or so. The web site has been built out quite a bit and the API has become less test like and uses the keywords

1
context

and

1
specify

to organize things.

Eliminating Front-Line Technical Managers

Cory Foy posted a thought provoking comment to my post on Grooming Technical Managers:

One of the interesting discussions I had when I came on board at my current job was with the XP Coach. Part of bringing on XP at the company was that he convinced them to do away with the front-line technical managers. Everyone became a developer.

It’s an interesting study because there are two primary teams (of about 30 devs each). One of the teams embraced this (or embraces it now) while the other seems to fight it. And in that, it seems like the ones who embraced it – who traded management for self-managing teams, who traded assigned leaders for those who showed their strength for it in the group – are doing much better. In fact, they are coming off a 600 unit story that they completed the week they said at the onset being only 4% over budget. Not bad. 😉

I find the idea of doing away with my job fairly appealing. I love the idea and practice of self organizing teams. My personal goal both in consulting and as a development manager has been to bring the team up to a level where I was no longer needed.

I do have fears however that some stuff gets left behind by making everyone a developer. Most organizations just have a lot of administrative stuff that someone has to take care of to keep everything rolling along. And someone has to focus on things beyond the project at hand. In a team of developers who does one-on-ones, fills out the purchase orders for a new build box, or makes sure time sheets get signed off and approved.

The admin duties of a line manager can get absorbed in part by the team. Someone can take the task to run the purchase order through the procurement division and make sure it arrives. Tracking down time sheets can fall to the ScrumMaster. Reviews and feedback can come from other team members and mentoring relationships can be established while pairing.

And Cory’s point here is that your trading your assigned leaders “for those who showed their strength for it in the group.” Thus leaders are elected by the group and not chosen. I have a healthy ego, but if the group wanted to elect someone more qualified, I’d be pretty happy to have someone to use as a mentor.

At one startup in the past I experienced something like this process. The startup was opening a new office in Las Vegas of all places and I was brought in as the first web developer along with a senior Java programmer and one Microsoft programmer. I was never officially granted any management title, but I simply stepped up and took the reins. As I performed on projects and helped stabilize the web developers we were hiring, they just started referring to me as the lead/manager. As a nice bonus they started raising my salary without even telling me. I remember looking at my paycheck and noticing it had jumped three separate times in a single year. This was of course when you could barely type out some HTML and recruiters would throw crazy salaries at you.

Eliminating front-line technical managers can probably work, but within a corporate environment it’s going to be a tough sell. I know at my present company it would raise more than a few eyebrows if we attempted it, but given enough time and organizational change we can get there. But, darn as James Shore asks:

Is burnout inevitable for anyone attempting organizational change?

Grooming Technical Managers

My manager mentioned a common difficulty to me at our last one-on-one meeting:

“You don’t want to make role of a manager appear too frustrating or you can’t find anybody willing to take it. And since senior developers can often make as much or more than their managers you have the problem that no one wants the job.”

He spent a good portion of his career at EDS so I often get good insights from his prior experiences.

This might explain why too often we see the case where a technical star takes on a management position in order to advance their career or sometimes for more money. They end up doing a poor job primarily because the managing part of the job never really interested them and they can easily fall back into coding and architecting and let the management part suffer.

I’m not sure how you make the concept of technical management appealing and draw more good candidates into the pool. I’ve known quite a few good friends who’ve stepped into a management role because they were asked or possibly for the money and found their lives a miserable mess. Going back to senior developer lowered their stress and made them effective again. They often point out they’d never want to do what I do now.

Leading a team and making them more successful is a special sort of reward, but it’s very different than being able to solve a particularly difficult coding problem in software. It’s really less about individual achievement and more about the team, much like a sports coach. At the end of the day your teams done great things, but if you’ve done your job well not of that code that is delivered is yours.

I suppose another fear of many developers is that if they commit to doing technical management, many of their coding skills will wither away. If the last time you did much coding was back in the days of client server you’re vulnerable to a downturn in a way none of your developers are. I avoid much of this dilemma myself by doing development in my spare time as a hobby, but that isn’t be an option for everyone.

I’ll continue to grapple with this, as you have to do some succession planning as a manager.