The “Last Responsible Moment” is a concept from the world of lean that says, by avoiding premature commitments, you gain more flexibility down the road. Now Karl Scotland has written an elegant post that shows the what the Last Responsible Moment(s) are for Agile2010 conference submissions.
I had a great batch of interesting items lined up and then laptop had an odd shutdown (driver issue) and Firefox couldn’t reopen my state from that day. So much great stuff has been lost. So sad.
This week I lead off with Ilja Preuss’s “The Aha-Experience Exercise” – this an exercise helps attendees highlight continuously review their training and share with each other what is working. The best part I saw Ilja mention this on twitter. I asked for details and week later I have this blog post. Ilja thanks.
Being late to the party I missed Dale Emery’s “Writing Maintainable Automated Acceptance Tests” last year when it first came out (examples in Robot Framework). Uncle Bob replied with a version for FitNesse.
Finally George Dinwiddie reminds us that you really can’t get “100% utilization” (or even close) out of your software developers.
Next week I intend to write a short piece on acceptance testing.
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 :-)
Thanks for reading the 9th Agile Quick Links.
Shu-Ha-Ri comes from the Japanese Martial Art of Akido. Roughly speaking it equates to:
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.
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.
![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).
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?
This edition of Agile Quick Links comes to you from a hotel room in Santa Clara.
Matt Heusser discusses one of my favorite recent peeves in his The Fishing Maturity Model.
Gojko Adzic writes about a recent XPDay ’09 session: Shock therapy agile adoption at 7Digital. It’s great to know that no humans appear to have been harmed during this process.
I’m working with a client who runs a documentation team, so I was delighted to discover HeraTech, a new blog dedicated to applying Agile to Technical Writing.
Preparing for TEDxOttawa this past week, I heard a couple of great talks—Dan Pink on the Surprising Science of Motivation (hint: individual rewards don’t work) and Dan Gilbert on Our Mistaken Expectations (he demonstrates that we’re really bad judges of value).
Henrik Mintzberg revisits Dan’s point to say No More Executive Bonuses!
I love seeing Agile applied in interesting places and seeing how it adapts—so I offer you the Agile Lawyers Association—it seems like a great idea, but the website needs a bit of work.
Michael Sahota visits one of my favorite topics: Joseph Pelrine and “Coaching Self-Organizing Teams,” I wrote about this last year—Coaching Self Organizing Teams and Part II.
Finally, Ilja Preuss gives some great tips on keeping time in a meeting (Agile or otherwise).
This week I’m leading off with a pair of items on the brain and recovering from challenging cognitive tasks: Cognitive Recovery Time and A Dream Interpretation: Tuneups for the Brain (NY Times, login required). The first suggests that your brain needs time to recover after doing something challenging. The second reinforces the importance of sleep and dreams in integrating ideas and information. What does this mean for TEDx attendees next week? I’m not sure except that we presenters will have to work hard to make our ideas stick. I also think it’s a bad sign for the typical two-three day Agile training course.
Joe Little shares his: Agile Principles—examples: all WIP is bad; bad news doesn’t get better with age. You learn the fastest by small mistakes.
Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!
Johanna Rothmann tells “How Not to Win Friends and Influence People”, and I’m only disappointed that she didn’t name names.
Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain’t Enough
Powered by WordPress. Designed by 
Recent Comments