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
My column on Stickyminds is up: Measure Throughput, Not Utilization. Enjoy!
I’ve been working with and discussing agile program management with a bunch of people. One of the big issues is: what do we call certain people at the program level? We need a program manager, someone who sets/explains the program’s vision, develops program-wide release criteria with sponsors, has a way to articulate program status, someone
I’ve been working with several clients on their transition to agile. Yes, the technical staff needs training. Yes, they often need coaching on how to choose small chunks, estimate and commit to an iteration’s worth of work, and then to deliver that work. And, I am beginning to think the biggest problem in transition is
I’ve been working on agile program management and a colleague emailed me about his program. He’s having trouble seeing how to do agile on a large program. The customer wants to see a working system before they add the features, so the customer thinks the program need to provide “all” the architecture, with some hard-coded