While writing this blog post I am in a restaurant in the Vienna airport killing time until my next flight to L’viv will depart.
The reason why I am going to L’viv is to pay one of my regular visits to the near shore development company from which we hire a number of developers for our teams. I will be staying in L’viv to conduct job review meetings, job interviews with new candidates and of course socializing with our Ukrainian employees.
The last time that I visited this company there was a company wide meeting about their CMMI level 3 implementation. One of the procedures they were discussing during this meeting is that all teams, regardless of the project, technology or team members will use the same development process and practices up to details like using pair programming or not. This is quite the opposite of how I think an agile organization should be run.
In my opinion the use of development practices, such as TDD, BDD, pair programming, continuous integration, etc. are up to the team to decide. As a manager I cannot impose those practices on a team, I can merely advise them to take a look at these practices to see if they can benefit from them and support them in implementing any practices they might choose.
And why is it that the manager cannot decide which practices to use? Each project and each team is different and can require it’s own practices. The fact that some development practices have been a success in some projects does not necessarily mean that they are applicable to all projects. Things that work well in one project could even have a negative impact in other projects.
For example a very short lived project (only several sprints) might not need a continuous build because the overhead of setting it up would cost too much compared to the relatively small benefit you can get from it in a short project.
My advise to all managers, delegate the selection of development practices to the teams itself and only interfere if you see things going terribly wrong.
Ideally you would also want the choice of the development process, SCRUM, Kanban or XP (I could also list things like waterfall and RUP here but this site isn’t called agiledevelopment just for fun) delegated to the team. Because in general the same applies to the general development process for a team, depending on the team, the project and the circumstances certain development processes could be more applicable then others. But most of the time the team does not get to choose their development process. Since it is widely accepted that this is a management decision.
The interesting thing is that when agile methodologies were first introduced into companies (about 15 years ago) the introduction of agile in a company was usually in a bottom up manner. Meaning that the development team would get sick about working in the inefficient traditional approach a company was using and decided to start introducing a different way of working which we all now know as agile.
Over the past years the introduction of agile in a company has shifted from bottom up to top down were management decides that the company should do agile. In my opinion this has two main causes:
- Success stories about agile are reaching managers and naturally they want the benefits and would therefore like to introduce agile methodologies.
- The early adopters and enthusiasts of agile have moved to management positions and ended up in companies were agile is not introduced yet. These people are highly motivated to change the company were they are working to adopt agile.
Is it a bad thing that agile is being introduced from top down instead of bottom up nowadays? Not necessarily. Sometimes the need to change starts at management level when there are insufficient results from the development team(s) to satisfy the business needs of the managers. In these situations it is quite logical that the managers want to improve the development processes and are willing to try a different approach.
There is however a risk in this and that is that maybe not all alternatives are looked at with an open mind. If I look at the company were I am working, we implemented SCRUM about 14 months ago. And even though I am the biggest fan of SCRUM within our company and I sincerely think that for us it is the best possible solution, I doubt that things like Kanban and XP were considered while selecting the development process.
Luckily we ended up with a process that we are very happy with and is bringing us the results that we were looking for. But it is the pitfall of top down agile introduction. When agile would be introduced bottom up it is probably because the development team has tried and researched several possible solutions and came to the best solution based on that.
But doesn’t the bottom up introduction of agile have risks as well? Unfortunately yes. In my opinion the risk of introducing agile bottom up is that development teams tend to tailor it to their needs or their current way of working straight from the start while a top down introduction of agile would probably not.
Not that there is anything wrong with tailoring a development methodology to your needs, but in my opinion it is better to start with the basics and then tailor it along the way. I have seen tailored agile implementations in several companies and not all of them were bad, but a lot of them resulted in a waterfall like approach hidden in agile terminology, some examples:
- Design sprints followed by development sprints, followed by test sprints.
- Waterfall within the sprint; testers are sitting around waiting and then are franticly testing everything in the last few days of the sprint.
- Beta sprints at the end of a release cycle.
- Alternating sprints. I once heard a SCRUM master of a team explaining that they do all the development work in one sprint and then the sprint after that they focus on testing and bug fixing in what they created in the previous sprint.
There are also good examples of course:
- SCRUM combined with XP practices such as TDD and pair programming.
- SCRUM with a work in progress limit and other KanBan principles (also sometimes referred to as SCRUMban nowadays).
So when you tailor an agile methodology to your own needs, make sure you do it in the right order. Try the documented and proved approach and then make some changes based on the experiences that you have with it. And as always, be agile while doing this. Review your process from time to time and make changes if necessary.
Ok you are probably thinking: “make up your mind, is it a top down or bottom up process?” In my opinion it is neither. If you want to introduce a new methodology in a company you need support and motivation from all people that are involved. A bottom up introduction will fail instantly if there is no support for it on the management level. A top down introduction will fail eventually if there is no support or motivation from the people that actually need to work with this process.
The general conclusion that we can draw from this:
- Development practices; Let the team decide these by themselves. Advise and support them were needed and only interfere when the world is on fire.
- Development process; This should be a discussion between management and the development teams. It will only work if both sides are motivated to make it work and are willing to support the ideas.
Trackback from your site.