When I started to work at my current workplace, one of the first things my manager asked me to do was to prepare a presentation explaining the Agile methodology to our stakeholders. They were unfamiliar with this philosophy, so it was best for us to explain what this was about before we started the project.

So I sat down and wrote an informative presentation, explaining our Agile methodology: how we’d sit with them at the beginning of the process and document all their requirements; how we’d then go away and work on these requirements; how we’d come back at the end of the development and ask them to test the program. It was a wonderful presentation.

I gave it to my manager for review.

He came to me a couple of days later and asked me to do it again. I was a little surprised but, well, he was the boss and I was the new employee trying to make a good impression. So I revised it and re-wrote it, still explaining gathering requirements up front, then doing development, then getting the users to do their testing.

A few days later, my boss came to me again and explained that our company had an account with an online bookstore, and I might be interested in reading a book that was available there: Agile and Iterative Development: A Manager’s Guide by Craig Larman. Well, why not? He’s paying me — if he wants me to read, I’ll read.

So I read.

I read about sprints and iterations, and just-in-time requirements, and user stories, and story points, and The Agile Manifesto, and prioritising working code over documentation, and preferring response to change over following a plan — this was nothing like what I knew! And, embarrassingly, it was nothing like the presentations I’d written. I went back to my manager and said I’d revise the presentation again.

I then realised that my previous employer had led me astray. Their statement about their processes being Agile was misleading at best — from what I now knew, there was nothing agile whatever about what I learned there.

So I kept reading — every online book and website I could lay my eyes on, including the following:

• Agile Estimating and Planning by Mike Cohn
• User Stories Applied: For Agile Software Development by Mike Cohn
• www.agilemodeling.com by Scott W. Ambler

I had no idea who these people were — I just knew that I needed to learn about Agile, and quickly. Thank you, Google!

Luckily, I had some time: the developers’ start date was delayed due to budget issues. So I read and read and read.

Then the developers arrived and the project started in earnest. The project manager and both developers were experienced in Agile methods. I...was not.

We were using a hybridised Scrum methodology. So I started writing user stories. I helped plan iterations. I sat with the developers and worked with them every day. I wrote test cases instead of requirements documents. I attended daily stand-up meetings. I did none of the things I’d done before; none of the things I was used to. Everything was new to me.

I worried that I didn’t know what I was doing; I stressed every day that I was letting the team down; I tried as hard as possible to work in a way I’d never worked before. There were times when it got too much for me — and I’d take it out on our more senior developer, who would patiently accept my bad temper, knowing that it was directed more at me than him.

However...I adapted. Now, I can’t imagine working any other way. When I attended a BA conference recently and a presenter started talking about how to write a better up-front requirements document, or how to manage change requests, I found myself thinking that this was a silly way to work. Why would anyone waste time writing a big up-front requirements document, knowing that a lot of it would change or even be out of date by the time it was needed? Why not simply write another user story and add it to the product backlog to be fleshed out just in time for development?

Without ever intending to, I made the transition from traditional waterfall to one of the Agile methods.

And...if I can do it accidentally, you (or your organisation) can do it deliberately. What’s holding you back? Fear of the unknown? I didn’t even know what Agile was when I stumbled across it. Fear that you won’t be able to change the way you work? I didn’t know what I was doing, but I managed.

I’m not here to say that Agile is better than waterfall (that’s another blog post!). But, I will say to anyone who is considering making the transition: If I can do it, anyone can.

Don't forget to leave your comments below.