When talking about becoming agile or using agile methods and processes, the set of rules to follow are generally quite short (at least in the case of Scrum) . Those are actually more principles as opposed to real rules. But when it comes to apply them and implementing SCRUM in the real life of a software development environment, things become more difficult very quickly, especially when lacking experience. But we all have to learn one time, and we learn best by doing mistakes

Transitioning to Scrum requires modifying the process at all the organizational levels. As Mike Cohn writes in the first chapter of his book “Succeeding with Agile”, it involves everybody, need the support from the management (the CEO in my case) but also the enthusiasm of all team members. Fortunately, all those conditions were fulfilled.

The problems come more from all the habits to change. In my organization, we have several products running in parallel. The support comes in everyday, and the lack of structure on past projects comes back to bite us in the ass on a regular basis. Change is needed, everybody agrees on that, but it is a long process that won’t show a total improvement right away. Let me detail what are the challenges I meet.

Engineering practices

Scrum does not define any engineering processes, and it is sometimes criticized by the agile community because it would let one believe that a team can be agile without changing their way of coding the software. This is wrong in my opinion. Scrum is a framework to manage agile teams on agile projects. It doesn’t mean we don’t need to follow good practices though.

“Scrum is a fine example of a Lean environment. Scrum is a set of practices; this is how you do things. Lean would be the principles behind those practices. Lean is the general principles that encourage you to use something like Scrum”. – Mary Poppiendiek http://www.infoq.com/interviews/poppendieck-lean-2007

I really started to push the move to agile several months ago, by implementing progressively those so important engineering practices. No project had unit tests associated, and the code base structure didn’t support a continuous integration set up. This has been fixed now, and every new project has its set of unit tests which run on a build server after each commit. Metrics such as code coverage can finally be measured! (We use TFS, and stick to MSTest testing framework for this particular reason).

We started pair programming more and more, and we can see the improvement instantly. Developers learn from each other. Work is more fun, and we accomplish more during one day, with a better quality.

Stop Working on parallel project

This is a hard issue. When you have several applications in production, and the developers have not been working as a team on those projects in the past, or some have moved to another job, the knowledge is not shared within the team. That means that developers are working on different areas. It is a slow process to get out of this cycle.

An issue that I can’t exactly figure out how to get rid of is the situation where a customer has a request to test what we are capable of which needs to start up a small prototype (basically a small service that could turn into bigger a project). Of course, those tasks are assigned a high priority, because it could mean signing a new customer right away. But this leads again to parallel work and prevent from using all the developers as a team on one single project during a sprint.

The solution I see here would be to demonstrate to the management the hurt that is done by starting up multiple projects at the same time on a small team. For this, the article of Stephan Schmidt “The high cost of overhead when working in parallel” is a very good start.

This is the first part of an ongoing serie of the difficulties I encounter while transitionning to Agile in my company. In the second part, I will talk more about the different Scrum meetings and the impact observed, together with the problems I find on the way.