Almost no spare time this week, so just the links:
Virtual Team Member Dolly – from Lisa Crispin. Lisa talks about giving a remote Developer based in India a presence on her team. This is cool. Now if only we could erase the time difference 
Quick Agile Links #10
There are no Best Practices
Pet peeve warning. I keep on hearing questions – what are the best practices for Agile, or … .
There are no best practices – only good practices in your current context. The whole idea of Best Practices implies that you can learn them once and apply them in any context. I prefer the notion that there are some ideas. Sometimes they work well, sometimes they don’t. Try lots of small experiments and learn. Also the idea ‘Best’ implies there is never any room for improvement – ‘Good’ is a better word because it holds open the promise that tomorrow might be better.
So please no more best practices – only “Good Practices in the Current Context”.
Agile Games – at Agile Ottawa
Come play a game with us.
You have been hand-picked by your company to join an exciting new division. You have over-heard that this new group will be ‘Agile’ but what does that mean? Is this the career opportunity you’ve been waiting for? Is this a chance to make your mark and be part of something big? Did someone just say “making games”?
On March 9, Bryan Beecham will bring us through an Agile workshop to help sharpen our team skills. We will simulate the experience of a company that has just decided to become Agile. Regardless of your experience in Agile there’s a spot for you on one of our teams. To understand Agile you can’t just read about it, you need to experience it. Come and join us for an exciting evening of learning and discovery as we tackle some interesting problems by applying Agile principles.
Location: 343 Preston Street, Ottawa, ON (Detailed directions)
When: Tuesday March 9th, 2010
Time: Networking from 6:00-6:30; meetup from 6:30-8:00
Shamelessly copied from the Agile Ottawa blog
Agile Quick Links #9
Thanks for reading the 9th Agile Quick Links.
Shu-Ha-Ri comes from the Japanese Martial Art of Akido. Roughly speaking it equates to:
- Shu – learning the basics, repeating movements and following commands without questioning.
- Ha – breaking with tradition, finding exceptions, asking questions.
- Ri – transcendence – there are no longer individual techniques or practices, instead everything can flow.
This progression has often been used in the Agile Community to remind people not to question or alter the basic practices when they’re still learning to become Agile. (Thanks to Alistair Cockburn for introducing us to the idea in his book: Agile Software Development: The Cooperative Game). Rachel Davies has recently come across some harmful uses of the idea and talks about them in: Shu-Ha-Ri Considered Harmful? I don’t entirely agree with Rachel but that will be the subject another blog post.
Misuse of Velocity in Agile Projects
Like clockwork every month, someone on one of the Agile Mailing lists asks a question about “comparing velocity between teams” or “benchmarking data on velocity.” Before we examine the problem, let’s recheck what velocity is—the amount of work completed by the team/time taken to complete it. The amount of work is usually measured in Story Points (a relative measure of size). So velocity is just the number of points the team completes in the average iteration/sprint.
The underlying point is that Agile/Scrum teams use relative estimation (i.e., is this story/feature bigger or smaller than our standard story?) vs. the traditional approach of absolute estimation. The problem with comparisons, benchmarking, or any other attempts to compare velocity is that my story points ≠ your story points, because different projects use different standard stories. They work in different problem domains, and they have different people.
Quick Links Week #8
Hopefully, it’s obvious to all and sundry that this blog has been transformed. As you can see, I’m in the middle of launching a new business site: Agile Pain Relief Consulting. The blog will always be called “Notes From A Tool User,” and notesfromatooluser.com will always work, but from now on it will be a 301 redirect to this site. The upshot—please do not adjust your set. It is functioning as intended.
The transformation is far from complete—some structural work and a lot of writing are left to do. Please excuse the mess. In the meantime, I’m going to get this blog back on track.
This week’s Quick Links:
We’re hearing a lot about Toyota’s woes in the news. Hal Macomber thinks the common claim that Toyota lost its focus in attempting to become the world’s largest car manufacturer is wrong—read: What Is Going on with Toyota and Toyota’s Lesson for Project Managers for more.
Dave Nicolete (riffing on some comments by Dave Rooney) suggests a simple way for estimating a team’s initial velocity for its first few iterations. This is the problem that teams new to Agile have. Management wants an initial estimate of how much work will get done before the product is released and the team doesn’t have enough experience to give it.
Sandy Walsh (a former colleague from Andyne Computing) is writing an interesting series on the importance of readable code: A Tale of Two Code Bases and Your Code is the Other Team Member .…
In Goal-Oriented Daily Stand-Ups, Joakim Karlsson offers the idea of setting a daily team goal, which helps to ensure that the individual tasks toward the team’s goals.
In the early ’80s, the department of Computing Science at Queen’s University got its first Vax 11/780. At the time, my father complained that professors no longer talked but just emailed each other even though their offices were only 10 feet apart. Phil Jeffs notices the problem continues: Don’t email me. I’m sat right next to you.
Quick Links Week #7
![PeterDrucker002_jpg[1]](/images/old/6a00d8341cc2cf53ef012876ebb621970c-pi.jpg "PeterDrucker002_jpg[1]")
Sorry for missing a week. I’ve got serious business site renovations going on. Stay tuned for an announcement in the next week or two (note that this is an estimate and not a commitment).
Jonathan Rasmusson offers the Drucker Exercise, a simple way to get a team to gel at the start of a project. I think I might use this with the next team I coach to help break down those initial barriers.
The Mostly Free Detroit Agile Conference is a great little conference in Dearborn, Michigan (a bit far from Ottawa), which leads to Matt Heusser: Conferences on the cheap. Matt offers ways of doing conferences for much less than the expected rate.
I keep on hearing about Continuous Deployment, and while I think that most teams are not ready for this by a long shot—it’s one hell of a goal. Eric Reis introduced me to a great case study from Ash Mauyra. The downside of being an outside coach is that I rarely get to see clients make it to this level. They usually let go of their outside consultants long before they get to this stage. Way to got Ash.
Over at Cutter Jim Highsmith has some good reminders around Self-discipline and Self-organization. Short, simple and sweet.
A very large list of on line collaboration tools. Might be useful assuming that you feel you really need distributed teams (see Self Inflicted Agile Injuries).
A Community of Thinkers – A personal commitment
In December, Liz Keogh, Eric Willeke, and Jean Tabaka got together at the Rally offices in Boulder. In only a day, they drafted a statement of beliefs and respect. If we all agree to follow them and respect each other, many of the rifts that have appeared in the Agile community in the past year will start to heal (see the comments under Jean’s post “Escalation” for examples of those rifts. Also see the Cutter 2010 predictions).
Agile Quick Links Week #6
I’m back in the saddle after having taking a couple of weeks off the Internet.
This week we open with a pair of posts around TDD. First up—Scott Miller of Atomic Objects ran a simple experiment: Faster, better, cheaper! TDD wins in a simple experiment and then earlier this year Mike (GeePaw) Hill wrote: How TDD and Pairing Increase Production, a good explanation as to why it works.
Xavier Quesada Allue aka Mr Visual offers Build a taskboard in 10 steps.
Not a blog post but a useful tool: Sonar from Codehaus may be a way of measuring some (but not all) of your technical debt.
Dean Leffingwell uses Little’s Law, Queuing Theory, and Starbucks to show us why large backlogs are not Agile: An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility.
Anyone who has taken Agile Training from me has heard my remarks about team size. Johanna Rothman gives us “Ideal” Team Size and Ratios—I’m with her. If you have more than 9–10 people on a team, you will get separate subteams forming. On the subject of how many testers/writers does a team need, I like to start with one of each and add developers until they’re at capacity.
Richard Lawrence is chugging away and creating new versions of Cuke4Nuke—a version of cucumber that allows you write your step definitions in .NET: Screencast: Testing Web Applications in .NET with Cuke4Nuke and WatiN.
Michael Dubkaov shows us why it’s a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?
Self Inflicted Agile Injuries
Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately, in doing so they’re often reluctant to pay the price to create and maintain high-performance distributed teams.
Agile works on the basis of a few simple principles:
- Short Feedback Loops—which leads to iterations, TDD, …
- Radical Transparency—which leads to daily standup, demo/review, …
- Face-to-Face Communications—which leads to high trust, group problem solving, …
- Value—which leads to eliminating waste
- Continuous Improvement—which leads to retrospective, adoption of engineering practices
Thinking back on every project that I’ve ever worked on (Agile or not), the quality of communications was a good predictor of success. So when we run distributed teams, there has to be a focus on making communications work.
At best, the typical approach to this problem is to buy web cams, fancy video- conferencing software, and conduct our meetings sitting in front of them. But that misses the point—these devices improve the quality of communications but not enough. They don’t build trust. To really build trust, you have to meet face to face for at least a week. Unfortunately, trust is weakened through the course of a year, so it has to be renewed. At a minimum, team members should visit each other twice a year.
So, if you really want to get a high-performing team—don’t underestimate the real costs. Be sure to budget for travel—a minimum of twice a year to build and maintain trust. Don’t shortchange your distributed teams.
