I posted a few weeks ago about an agile refresher I was going to do with my team.  Well, this morning was the day I did it (in between sprints).

The presentation itself was structured and geared towards reminding people of the "why" of agile.  I kept it focused on the reasoning behind agile using things like the Agile Manifesto, the differences between agile and waterfall, and the fundamental need for strong teams to ensure any agile process works and works well.

I ran through things that agile is not, the value and importance of face to face communications, the goal of reducing wasted effort anywhere in the process, the inspect & adapt philosophy, and the understanding that change in your only guarantee.

I then did a Scrum refresher - deliberately keeping it at a high level and encouraging teams to evaluate what they are doing and how they are doing it to improve items.  The last thing I wanted to do was tell the teams how they should be operating (kind of breaks one of the principles) so instead I showed them what some of the other scrum teams around the world have done using photos from the web and suggested that they think about doing the same.  Some will, some won't  - but that's their right.

I then ran through a series of tips on how to make scrum a success and wrapped it up with a Q&A session.

I got a sense from some people that they still weren't sure about "this whole agile thing" and that they were doing it because they had to, and yet at the same time there was also a sense that even though they didn't get it, that if they stuck at it then maybe something would click.  I've got no problem with a healthy skepticism and would hope that those people who felt this way would come up and ask questions until they "get it".

The results?  Pretty positive.  The energy today and the communication was the best I've seen it in a long time, maybe ever.  One day obviously doesn't make a real difference, but if the buzz in the place remains over the next few weeks it'll become habitual and seem like a normal working environment.  If that happens, I'll be a happy boy :-)


If you are wondering - here are my tips for success

1. Work as a Team

Team work is a critical success factor for any agile methodology.  A dysfunctional team, or a group of individuals will never be able to regularly and successfully deliver on their commitments and will ultimately fail.

2. Work for a Result

Effort is not what you are measured on.  It's delivery of working software so keep at the front of your mind that the result is the most important thing.  How you get there is important, but secondary to the goal of delivery.

3. Blame Doesn't Fix Bugs

Try as you might, shouting at a team member until you're blue in the face and you've made them cry because of something stupid they've done will not get a bug fixed.  It may make you feel better, though it probably won't, and it may even help you vent frustration but what it's absolutely guaranteed to do is prevent you working well as a team.

Correct the bug, educate the person on their mistake and move on.  Whatever you do - don't fall into the mistake of personal attacks.  It's a zero-sum game.

4. Don't Work in Isolation

How can you be part of a team if you are on your own?  How can you be alone and communicate with your team members?  It just doesn't add up.  Even if you don't use pairing involve others in your work.  No exceptions.

5. Use Test Driven Development

Quality is critical.  It's hard to be agile with a bug list any long than your little finger, let alone one as long as your whole arm.  In a 2-4 week sprint cycle, the only way to guarantee quality is via automation. TDD ensures that the tests are there, ready for the code to be written.

If you don't use TDD then at the very least, write and use unit tests.  Failing to do that makes agile very hard to achieve.

6. Don't Take Shortcuts

It might seem smart to take a shortcut, especially if it means you can convince the customer that you delivered on time when time is short.  The problem with this is that you're almost sure to have to come back and fix things later and it'll take much longer second time around to do it right than if you spent the time up front to do it properly in the first place.

More often than not, a shortcut is never removed from the system because the cost and time involved in fixing it is just too much.  Then you get kludgy workarounds for the original shortcut and over time it turns into a nightmare piece of code no one can maintain or understand.

7. Question Until You Understand

Don't make blind changes.  If you don't understand why you're doing something then don't do it.  Taking action with a lack of understanding is just a different form of taking a shortcut.

8. Keep it Releasable

If your build server (you've got one, right?) says that the build is broken - don't go home until it's fixed.

9. There is no Spoon

And there is no ideal solution either.  Stop overengineering, stop arguing over the fine points of an architecture.  Just make a decision and get on with it.  If you can't agree get a few other team members involved and vote on it.  The more time spent on arguing the less time you spend on delivering.

10. Keep It Simple

Simple but not simplistic.  Minimise wasted effort by delivering only that which is required.  Bring the YAGNI principle to bear (You Ain't Gonna Need It) on over designed solutions.

11. Collective Ownership

Agile is a team sport. A success is everyone's success and a failure is everyone's failure.  The code is everyone's code.  The design is everyone's design.  The quality is everyone's quality.

If you have people who think "if it's everyone's responsibility then someone else will do it" then you'll need to educate these people and single them out when this kind of thinking hinders the team.  The thinking should be "if it's everyone's responsibility then it's my responsibility"

Following these tips won't guarantee your agile projects are successes but it will certainly help.


I'd love to hear your feedback and if you want a copy of my presentation you've just gotta ask.