One of the earliest critique Agile being very good for projects, but not for BAU activities. How could a helpdesk be Agile or how could the server team work in an Agile way? I always worked in projects, so it was clear to me that Agile can be used effectively for iterative-incremental software development – but struggled as well to understand how does it work for the whole organisation.

The more I learned about Agile, the more I realised it’s not just a software development methodology, but a different approach to work. There are tools Agile provides to deliver real business benefit early. Just to mention a few that can be useful in any work environment where there is a team:

• Daily stand-ups. 15 minutes will not take away much time, but can add a lot of value to understand what are the goals for the day, how we’re tracking. Make sure, it’s not 30 minutes… This can be facilitated by an Agile coach in the first weeks – but people will learn the objectives of this meeting and run themselves.
• Team co-location. If it’s possible, work together with the people you need. Pop-up teams can be very effective, when dealing with business problems.
• Face-to-face communication: Tired of receiving hundreds of e-mails a day? Why not ask in person? Trust is very important in an Agile team, and you should NOT be focusing on covering your backside (if you have to do, there is more work to do – and showing that you trust can make wonders). In the Agile world we have to learn to trust each other and work as a team to deliver.

But you might have better ideas on what tools could we start using to be a leaner helpdesk or IT operations. I welcome any good ideas or constructive feedback as I want to learn just as much as I share my experience.

The company I work for invited external consultants to help us with our Agile transformation. There was a lot of noise, from the “why do we need consultants?” to “why do they put lots of post-its on the wall?”. The first jokes were about “Agile being putting post-its on the wall and increasing our stationery costs”.

Obviously we didn’t know much in the first period and these comments were natural. I didn’t worry about the cynicism that much as I knew, we will have more and more visibility of what’s happening and why do we need those post-it notes.

Since I was curious, I went to YouTube and watched a few videos about Agile (and Scrum). This one was a pretty good summary: http://www.youtube.com/watch?v=XU0llRltyFM This short video helped me to be able to participate in Agile related conversations.

Then I started to look at the post-it notes, and what’s on them. One of the my favourite wall we created is the Program wall. It has all the projects that we are planning to run or we’re currently running. Before I heard people talking about the projects in lengthy meetings and saw a few spreadsheets with the list of projects . But these Excel sheets were different every single time, and could never find a single source of truth. Now the wall is always visible and I always know, what projects are we planning to run. As a test manager I was often approached quite late in the SDLC and had no idea about projects that were already underway. Now I have much less unexpected work and I am aware of upcoming projects. Never thought that post-its can work better than a spreadsheet :-).