Agile – Keep It Simple

Being hip followers at work, almost all of our projects are agile now. But while have a solid agile process defined which works well across disciplines and time zones (i.e. off-shore), just peeking in on various projects every now and then makes me wonder why I see the same problems pop up again and again.

First of all, agile is actually a very simple, disciplined process — and that’s the beauty of it. It’s simple. Plan out your work, track it, create a workable/releasable piece of software with every increment, do a demo, regroup, repeat. A simple process built on simple principles of sustainable development (that means not burning your teams out, dummy).

So what are some of the things that I keep seeing that are messing with the success?

1. Keep re-planning throughout the sprint

Constantly re-prioritizing every day and letting the clients and other sprint teams (e.g. user experience/functional folks) influence the core development team. This is a major no-no. The idea is that at the beginning of the sprint you plan out your work together with the product stakeholder. You do not add or change work or the major goals of the sprint during the sprint. If the sprint plan needs to be changed, interrupt the sprint and call for a planning meeting. It seems to be tempting to squeeze a little this and a little that into a sprint, but in the end it compromises the quality of the increment’s deliverable. And usually causes  long hours for the dev team.

Here’s another awesome idea. Invite many managers to every meeting (yes, they exist in most organizations) and have them talk, create chaos, then leave for a few weeks just to come back and change direction.

Remember – agile teams are to be self-organizing and interact with their product owner for direction during sprint planning. The key is really in the self-organizing part. Empower your team.

2. More features

You want to impress the client and add more and more features into the sprint and think it’s perfectly ok to implement each of them half of the way as long as you have something to show for. Well, remember that one principle of agile development? Workable software with every increment. Having a bunch of half-implemented features not only creates half-assed non-releasable software, but also causes your features to bleed into the next sprint where your team will spend half the sprint cleaning up the features from the previous one. And of course your client won’t be happy because the sprint demo probably won’t go well. Your developers will hate you for the long hours trying to just get something to work even though they probably have to rip half the code out again in the next sprint.

Time savings? No.

Increased productivity? No.

Happy clients? Probably not.

3. Who’s the scrum master?

Appoint a non-technical person to be the scrum master of your tech team. This might be a little controversial, but I don’t think that project managers without tech background make good scrum masters for a technology team. The scrum master should be the equivalent of the technology lead for the team. This is especially important in a multi-team environment like we have at an agency or any other sizeable project. The lead of the team needs to be able to participate in scrum-of-scrum meetings with the other teams and be able to fully understand the technology as well as any implications of decisions the other teams are making. So the scrum master of the technology team needs to be able to coordinate between the user experience / functional scrum team and the technology team. Otherwise you’re headed into disaster with two interdependent scrum teams which are running into opposite directions. And you need scrum-of-scrum meetings to coordinate in a multi-team environment; don’t think you can save those 10 minutes a day.

4. Code away

Write no documentation. Yes, agile processes are light on documentation. But that doesn’t mean that you don’t document and just code away. That’s the cowboy methodology. You still have to document what needs to be documented. Just create a task for the documentation during your planning session. Documentation isn’t all bad, just keep it to the necessary amount. API specs of interfaces your provide to another scrum team would be a great idea to document, so are core data models of your application so you don’t have to repeat the same discussion with the team all over every two days. Use a wiki.

5. Standups

Sit down and talk through all the issues for an hour every day during your standup meeting (I guess that would make it a sit-down). Really, keep them short and simple, all major discussion should be happening outside of these meetings. Limit them to 10-15 minutes, talk about your accomplishments, what you’re about to do, and your impediments. You might be able to just get by with talking about impediments, but that depends on your team. These meetings are not meant to waste time and make managers happy. If you’re having a hard time with this one, pass around an egg timer that goes off after a minute or two of talking.

 

Alright. That’s five for starters. So please keep agile simple. I know it’s not easy, but resist the dark side.