Implementing Agile

I started off this last week working with my development team and corralling everyone into adopting some semblance of the Agile development process. There have been some challenges but they don’t come from my team members as I am lucky to have a team of devs who are excited about going this route. Most of my difficulties have been over having a massive project to morph and plan into smaller more manageable chunks but I’ll get into that later.

Use Cards, Post-It Notes, and Whiteboards

With tools like Pivotal Tracker out there for us to use it may be wild to suggest switching to 5-x-7 note cards et al. but there are some solid reasons for this. We had tried using Pivotal and found that although it was a fantastic tool to help us track sprint progress and velocity it took out the human element of what we were trying to accomplish. That and there are some glaring UI/UX issues with it that drove some of the team nuts.

Having physical cards forces tasks into generic, easily defined and understandable tasks. A card must represent something we feel we can accomplish within a sprint. Once we’re all standing around and a stake holder asks us to define what that card represents in complexity we can guarantee that at least two people had a worthwhile discussion to the challenges and merits of completing a card. Once you have a card (or story, or task, or whatever) you can prioritize it and devs can then talk about the tasks that are required to accomplish the card. Everyone involved has input into priority.

Taping these cards and sticky notes to the whiteboard allows us to use markers to add notes, shuffle things, and most importantly — talk. We have a tangible card to see make its way from the queue to finished along with its tasks, number of days it took to complete, and all the discussions and awareness the entire dev team has regarding these cards. You simply do not get this level of involvement from software even if its up on a screen via projector.

Meet Less: Brief Daily Stand-Ups

This forces the meetings to be chunky, content filled discussions which tend to be shorter. I feel it encourages people to open up about their own project(s) and other people’s tasks. Straight and to the point. What are you working on? Maybe start off with some good news? And then, any roadblocks? Everyone on the team has a chance to input. Decisions can be made here that can quickly adapt to the daily changes a task or whatever take.

Standing up and huddled around a task or story board, I feel, forces meetings to be quick and to the point. Hey, we’re on our feet. No need to espouse philosophically.

Dev Retrospective

Once a week on Fridays plan thirty minutes to discuss top issues which the team collectively feels need discussing. There are a few ways we can force people to talk about what is bothering them. The one version I saw of this meeting was very interesting and I think with a little tweaking can be really fun and effective at getting the team to identify and fix pain points in the week collectively. Shooting for a total of 30 minutes, here is a brief break down:

  1. 3 minutes – Using pens and sticky notes, have everyone including yourself write at least 2 notes about stuff they want to talk about. Examples: “Build process broke… again!” or “Jack shit”.  The point is two notes each. The silly pointless ones will eventually go away as in hopefully folks will try and identify real issues to discuss.
  2. 3 minutes – Everyone stick their notes to the board. Have everyone explain what they mean by the note. Briefly!
  3. Organize the stickies into similar groups. “Build process broke… again!” and “Ant dist file exploded.” are essentially the same thing.
  4. 2 minutes – Everyone has 2 votes. You can vote twice for the same sticky.
  5. Pick the top 2 items that people voted for. If there is a tie, everyone gets another vote.
  6. 10 minutes – Discuss the first item.
  7. 10 minutes – Discuss the second item.
  8. 2 minutes – Wrap up with action items or decisions on how to resolve the issues. Our team was able to discuss and generate real goals and changes to existing processes.

It won’t be exactly 30 minutes but you get the point. Have someone set a timer. Stick to the limits. Remember, the more time you spend in meetings the less work gets done. It is tempting to discuss every issue and take all day to address things. No need. If its important enough next week it’ll come up again.

Focus on Delivering Stories — Remember the Chores

No one wants to get through a sprint and find that some important chores and/or bugs have been neglected. Although delivering stories can often times be a stress-er between you and the stake holder, management, or whatever; it is important to remind everyone that without chores and bug fixing sprinkled throughout a sprint will accumulate technical debt. Don’t be horribly disappointed when your velocity drops a sprint because a major bug left the entire team scrambling to fix it. With the removal of hard deadlines and introduction of self management and integrated testing you have mini deadlines keeping a level of manageable stress with everyone rather than building up to a giant point of release.

Full Buy In

Everyone who can influence the development team priorities needs to fully buy into the Agile process you (and they) define. There can be no exceptions. As soon as those crop up the process breaks down and all the effort into self organization go to waste because the rhythm of the sprints is interrupted.

Also, manage through gossip. Have meetings where people can choose to eavesdrop and/or join in easily. Don’t be disruptive but avoid conference rooms for meetings unless everyone is present.

Team Build

Get developers away from their desks! Encourage the team to do more than just program together. Take breaks together. Go get coffee together. Eat lunch together. Organize outings to local meet-ups. The goal here is to get the team talking about anything. We need to have team members willing to open up and share more than just work. The goal here is that eventually getting up and asking questions and conversations will happen organically without meetings or planning.

Peer/Pair Programming

Schedule two 90 minute peer programming sessions with each of your devs a week. My goal was to eventually reduce that to one peer programming session per developer a week and have the developers initiating these sessions by themselves at least twice a week with each other (and me).  These are very important because they help mitigate the problems associated with expertise silos, help open the team up to one another, and help expose competency problem which the team will probably address on their own.

With the pressure of smaller sprint goals looming every week or two weeks, we can quickly see that hiding in a corner cubical for months and then crunching the project in the last week before the 6 month deadline isn’t going to work anymore. We want people who love what they do and are excited to do it.  It can be possible that some programmers are introverted and that peer programming (and Agile for that matter) are best suited for extroverted types. I think with the right coaching and encouragement everyone can get excited to share and talk about code. How did these people get trough your interview process if they didn’t! I feel that people will embrace Agile and work to make it successful if they see the benefits.

Evangelize Agile

There is no hard definition to Agile. There are only core tenants or principles. Those you should have memorized and fully endorse. Some of these are weaker than others and will require that you and your team make sure you try and work out a way to encourage that all the principles are touched on. Talk about how this is good for the company because it is. Understand why. Encourage others to join in on meetings and have them contribute.

Everyone Knows Best

Originally I had thought about this section as “Developers Know Best” but that is entirely wrong. Developers may be the ones who know best about what they are delivering to the customers or stake holders but it is the customers that know best about what they want. Developers have to remove themselves from a position about taking the code personally. There is no room for territorial behaviour. The trust must be mutual. Developers trust the business or stake holders. The latter must trust the developers. If that doesn’t exist then that is something both ends of the spectrum will need to work on.

When the business or management want something done they should approach any dev and ask for an estimate on a Sprint story. A dev should then be comfortable roping other devs and giving the stake holder what they need to know: the cost of getting something done.

Sprint Review/Planning

Once a week on Friday afternoons we get together and review what we’ve done (usually with stake holders). This is a very positive meeting. We’re all professionals and try to encourage and support one another in what we’re working on and got done.

For planning everyone will get together and try and sequence tasks so that things reliant on one another get done in the correct order. Priorities are chosen and with the limited people to do the work and scope of a week or two worth of time things quickly get filtered into musts, nice to haves, and if possible.


Not every shop’s development process will look the same. The same shop’s process won’t even look all that similar after a period of time. We are constantly trying to improve what we have and how we do it. It’s been two weeks and we’re tweaking and changing things as we go along. Our shop runs Trac hooked into SVN so we’ve decided collectively to use Trac as a way to tie all commits tied to a particular story inside a Trac ticket. Things change. Change is good especially when everyone is on board and wants to improve what they do and how they do it. Earlier I had mentioned using cards instead of Pivotal. On smaller more intimate teams this may make less sense.

I’ve been thinking a lot about whether stand ups are helpful. I think they are great places to share issues or progress an to hopefully encourage people to work together. I think there seems, in my experience, to be a steady direction of developers to work themselves into a cave working alone and without much interaction.

Anyway, it is an organic process. Don’t be afraid to change it.

This entry was posted in Programming and tagged . Bookmark the permalink.

Comments are closed.