In a previous blog posting I wrote about my top 5 signs that an organization is not really agile. That posting was more about the mechanics of Agile. In this posting, I present 5 signs that are more social or cultural indicators that agile either is not working in your organization, or is doomed to fail. Or flail.
Honorable mention, because I thought of this after I already finished the top 5: the expectation of heroic effort to meet unreasonable expectations. Sometimes this is coming from Some Guy (see #5, next) or it is indicative of a disengagement in your planning or demo process between your development team and your product owner; perhaps your product owner is expecting more than is reasonable to expect based on your velocity, or there's an expectation that change can happen without any consequences. We embrace change, and we can try to predict how much change is going to affect the schedule, quickly and with reasonable certainty, but we can't ever predict that the cost is 0. Also see item #2 in my previous post.
5. There is someone in your meetings who can't tell you why he or she is there (or what Agile role he or she is playing). For a proper game of Agile Development, the roles need to be clearly defined, just as in any well-organized game. Games of American Football are not played with a Center, Quarterback, Guards, Tackles, Running Backs, Wide Receivers, Tight End, Linebackers, Referees, Coaches, and Some Guy. There's no place for "Some Guy" in this process. Similarly, in Agile, there are well-defined roles, and no role called "Some Guy who shows up to your meetings and injects noise." And that's what happens when someone who is not properly involved becomes involved: noise in your signal. It's a distraction and an interference with your team's ability to self-organize to meet its goals. If Some Guy is trying to control, manipulate, or micromanage your process from the outside, it could be a sign of serious trust issues that I can't help you with. (Though you might want to skip to my last paragraph below.)
4. Your team frequently demonstrates misconceptions about Agile. Part of implementing Agile correctly is that the players have to understand their roles, and they also need to understand something about the game they're playing. I could do an entire blog posting on Agile Misconceptions, but for the sake of brevity I'll cite just a few common ones here: the idea that "agile" is synonymous with "fast", the idea that planning is minimal to nonexistent, and the idea that somehow Agile has no or low overhead. The remedy to this is education: you must consistently reinforce with people the reasons for being agile: delivering the right product with decent estimates and responding well to change.
3. You are a slave to your tools. Usually this means being a slave to Rally or Pivotal or Jira or even Excel or your favorite Gantt chart nightmare. You spend a lot of time in your planning sessions fighting with or updating these tools. You find yourself changing your own processes that work well for your team so that they fit into the model provided by the tool, or you spend a lot of time faking-out the tool in weird ways to make your processes work. In the worst case, someone from #5 above sees pretty charts in your tool and starts using the tool as a mechanism of bean counting or performance tracking. If you must use a tool, at least kick it out of your meetings. Sticky notes if everyone is present, or just your favorite text editor shared in an online session if you have remote people will speed your process along, and then you can go update your tool later when you don't have a room full of expensive engineers sitting around wasting their time.
2. You are not doing Retrospectives. Or worse, you are doing retrospectives, and the team is offering few, if any "starts, stops and keeps." (Worse because their time is expensive, and it's a waste of money to have them sitting around doing nothing.) This is a sign that your team is not engaged or invested in the process. Take a team out to lunch, and they can think of 20 different ways the restaurant could have improved their performance. It's hard to believe, then, that after a week of meetings and development time, they can't think of anything they'd change. To fix this, you have to figure out why the team is disengaged. Is it something you said? Are they afraid to speak up? Do they think their previous retrospective items have been ignored or gone unimplemented? Are there other problems going on within your organization that has impacted your team's morale? This is by no means an exhaustive list of questions, but rather a place to start. Lack of engagement will kill your process, so figure it out and fix it.
1. You are not doing demos. Your product owner should want to see progress. Your team should want to show off their achievements. Moreover, demos offer a unique opportunity to "force" any integration work that might otherwise be put off until it's far too late. (Integration should be happening more frequently than your demos as well, but nothing forces the issue like having to give a demo to your product owner.) A lack of demos can have many causes. You may have a disengaged team (see #2). You may not be truly performing iterative development. You may be putting off integration work that you shouldn't be putting off. You may have planning problems with stories that are badly written or far too big or you may have no proper product owner (see #5 in my previous post). Whatever the case may be, if you're not doing demos, find out why, quick! A failure to demonstrate work achieved on a regular basis (ideally every iteration) is a tremendous red flag that something has gone wildly off the rails. If you can change or fix only one thing, fix this one, because this will tend to expose and correct many other, smaller problems under the hood.
Remember: Changing code is easy. Changing behavior is hard. Changing culture is almost impossible. If you're having these problems, the fix may not be trivial. It might be very difficult. Start with education and get the support of your management chain if the onus is on you to correct the problem. (And if you're a self-organizing team, the onus IS on you.)
And I hate to say it, but I would be remiss if I did not mention Martin Fowler's well-known quote: "if you can't change your organization, change your organization." In other words, if nothing you can ever say or do will make your organization "get well", and you want to be someone involved in an agile development process, you might be better off making a career adjustment. I also take this statement in a way that Fowler probably didn't intend: if you have people in your organization who are holding it back and sabotaging your agile development efforts, maybe you need to have their careers adjusted so that you can get on with the business at hand.
