I posted a new newsletter, Three Tips for Your Geographically Dispersed Agile Teams. If you subscribed, you’d have seen it last week… There’s still time to sign up for the workshop in Tel Aviv next week.
Bob Payne interviewed me about agile program management last year at the Agile 2010 conference and posted the podcast. We always have a great time talking, and that podcast was no exception. He makes me sound quite coherent! Matt Heusser interviewed me about my new workshop with Rebecca Wirfs-Brock about Agile Architecture. My column on
When I lead public workshops, I ask people what their experience with with agile is. In the past, if I asked people if they were experienced with agile, their answers were reliable. Now, not so much. People think if they can spell agile, they are agile. If they sometimes use timeboxes, they are agile. If
I’ve been writing through my travels. Today, Stickyminds published Not Ready for Agile? Start Your Journey with Release Trains. In February, Gantthead.com published Timebox or Kanban: A False Dichotomy. I would have let you know, but I was traveling and was unaware they published it! I write the columns ahead of time and don’t know
Shane Hastie and I taught our Working with Geographically Agile Teams workshop last week in Sydney. One of the questions that arose is “What tool do I use with a distributed team?” That same question is on the scrumdevelopment mailing list this week. Shane and I don’t know what is wrong with a whiteboard and
Shane Hastie and I have been working across timezones in preparation for a workshop: Working Effectively With Distributed Agile Teams. I’m keynoting at SDC in a couple of weeks, and am looking forward to being back in Wellington and Sydney. First, Shane and I built a backlog in Google docs, so we could both see
A few months ago at Agile Boston, Mike Cottmeyer said that when he looks at teams who want to scale agile, he looks at their ability to create working teams. If they can create teams, they can scale. If they can’t, they have little hope of scaling agile. (Mike, if I’m misquoting you, I’ll correct
A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information. But what do you really need in a charter? Too
My Gantthead.com column has been up for a couple of weeks, but I was too busy traveling to notice :-(. The Silent Project Killer column is up. Enjoy!
I knew I was going to like The Agile Samurai from the first page: Agile is a way of developing software that reminds us that although computers run the code, it’s people who create and maintain it. Jonathan Rasmussen, the Other JR, has written a great, short, to-the-point book about how to move a project