The morning begins with everyone arriving at the office and gathering in the kitchen. The whole team is works together, there are no remote workers. As folks grab coffee and maybe toast a bagel, there is casual banter about the game the night before, the kids performance at a school play, and plans for an upcoming barbecue. When the last member of the team arrives, they all gather round into a circle looking at one another. There are a few mumbled “good mornings” and one memb

When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for onl

When some people transition from traditional project management to Agile, they seem to lose their voices. These are people who had great, strong, passionate voices. People who felt they were engaged and empowered to lead their teams to success. And then some consultant comes along and tells them that they got it all wrong. The wise consultant tells them that they are part of the problem and need to change their evil command-and-control ways. They need to be a servant leader –

So, let’s pretend that you are working someplace where you have two or more teams working on development projects. Furthermore, let’s say that those teams have been in the same configuration (same folks doing the same thing) for 3 or more years. Things might start to get a little stale right? Teams might start to get a bit isolated, each focusing on their own areas of domain expertise. You might find it very difficult to introduce change in this kind of environment – in fact,

There was an article in the CACM recently that caught my attention entitled, “In Praise of Bad Programmers” Still here? Apparently the provocative  title really sets off some fire alarms for people. I shared the article, which I personally thought was great, with a team and we discussed it together. I thought the whole conversation went really well and I thought it felt very productive. Afterward, I discovered that everyone in the room had apparently been thinking one thing:

Grab your pith helmet and join me for a little journey. Shhhh! Be vawy, vawy quiiiet, we’re hunting for projects! We move through the jungle with exaggerated stealth, placing each booted foot with care. We stop before a bank of thick fronds and I gently part them. On the other side lurks a horrifying creature: a man sitting alone at his desk staring intently at a monitor. I stifle a scream. Our programmer (Mr. Livingstone I presume?) is obviously engrossed in something intere

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied th

So I scratch my head and wonder, “What’s wrong with these people?” There seems to be this invisible barrier – they accept me because they have to, but they really don’t want me around. Me? I’m going nuts. Every day feels a little bit more aggravating than the next. Nothing seems to get through to them. Finally, there comes a meeting where I totally screw the proverbial pooch. Nothing major, no fights, no cursing, but something I say really pisses off the whole team. And they

How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit: New Artifacts: Team Working Agreement Team Definition of Done Task Board Burn down chart Impediments list Release Plan Backlog New Meetings: Sprint Planning Daily Standup Sprint Review Sprint Retrospective Backlog grooming New Concepts: Stories Story points Sprints Releases TDD Continuous Integration Cross Functional Teams

Here is an issue that has come up over and over again – scrum masters and product owners that don’t trust the teams they work with. I’ve struggled with this problem myself over the years, so I can definitely relate to the mistrust. Here’s my favorite example: Sandbagging: The team is not delivering 100% of their stories each sprint. The team is not pulling as much work as you would expect each sprint. Everyone is coming in late and leaving early. No one is staying late nights

A few years ago I went to the Apple WWDC (World Wide Developer’s Conference) in lovely Cupertino California. I was kind of a loner at the conference. It was my first time. I was by myself and I didn’t know anybody. But I had a Mac. Being the person that I am, I often felt like I was on the outside looking in. It was a very sociable crowd. People would get together in the hallway, sit right down on the floor, break out their titanium PowerBooks (OK, I’m showing my age), and st

In our last sprint retrospective we were not able to complete nearly 50% of the stories in our sprint. What was up with that? The last day before the end of the sprint, everything was still in progress (say 80%) but nothing was done. We talked about it in our retrospective. Why was this happening? Lots of reasons: The stories as they are broken down are typically taken on by only one person. Aside from any distractions, that person is focused on one and only one thing for tha

Here are a few ideas for things we could try out to improve our teams: Work on only one story at a time Minimize square footage of the team area Daily Design Review Change the way you do retrospectives (a coffee chat rather than an inquisition?) Bring one new idea to every stand-up meeting Daily interaction with other teams (ping pong tournament, sports book, whatever) Utilize ambassador pattern between teams Get to know I new thing about a team mate each day Focus on a sin

You know, sometimes the hardest part of working with a team is learning to shut up. During the honeymoon phase of a project (forming), it’s easy to deal with the team with a reasonable sense of detachment. If they make a decision that you find questionable, it’s no big deal. When the team steps on that garden rake, Whammo! “Hey, I bet that really smarts!” You just shrug it off and move on. Here are some real life “rakes”: Maybe we should try CI? What if we documented the arch

Here are a couple of definitions of swarming: 1 a: a great number of honeybees emigrating together from a hive in company with a queen to start a new colony elsewhere b: a colony of honeybees settled in a hive 2 a: a large number of animate or inanimate things massed together and usually in motion : throng <swarms of sightseers> <a swarm of locusts> <a swarm of meteors> b: a number of similar geological features or phenomena close together in space or time <a swarm of dikes>

At work everyone on the team have their own offices. It’s a pretty nice setup: lot’s of space, privacy – in short, it really doesn’t get much better in terms of individual space. However, the offices are scattered about the building and they definitely create barriers to certain kinds of communication. It has all sorts of interesting side effects. For example: currently, people will call into a meeting from their office, even if the meeting room is 10 feet down the hall. I ha

As a coach, I’ve encountered a great deal of confusion when talking to teams about building a cross-functional team. Often, as soon as I mention the notion, the reaction is negative. People often seem to think of cross functional behavior as every person on the team being able to do every job on the team. The impression that they get is that they are being told specialization is bad, and generalization is good. I believe this is often exactly what some Agile advocates are thi

As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows: Analysis ->Design->Implementation->Test->Release Or something close to this (you may use different terms). Basically, we do this, then this, then th

There are a few disruptive corporate behaviors that have been bothering me for a while. Forgive me for a moment while I get them off my chest. If you have witnessed these disfunctions, I’d be curious to get your perspective on them. Here are my top 10 ways to destroy an Agile team. Break apart the team when the current project is complete Keep the individual/team compensation plan a secret Don’t openly share financial data with the team Lay people off on a periodic basis Refu

So, you’ve experienced the Agile transformation now. Your team has a planning meeting, everybody goes to the stand-ups, and you do the obligatory review and retrospectives. You might even deliver some value to the customer every now and then. Sure, it’s an improvement over what you used to do, but it’s hardly living up to the hype. Bob the tester is still pissed off that nobody ever listens to him (they call him the “Bob the Test Monkey” behind his back). Joe, the senior deve