Introduction
I'm working for a big international corporation, in division responsible for providing IT services to the rest of the group. Besides server hosting services and running our corporate network, we are also building software solutions. We are organized in a way that other corporate entities are our customers and we deliver using standard commercial model including competition on the market.
My job is to develop software and after spending nearly 7 years there also providing couching to other developers. Several years ago I adopted agile method and I started using that in my projects with continuous line of success. Recently, I was given a task to spread this know-how to rest of our software development department which is very conservative and stick to classical waterfall method. What a challenging task!
On the other hand I found agile software development to be very healthy method of building software. Significant advantage is that it is compatible with developers minds and with customer expectations. This is very rare match I need to say and I do believe this is core of the whole success of the agile. Let developers to do their work in the way they feel it is correct and incorporate customer interaction into such an environment. That is actually very easy and working nicely.
Now what is interesting, it seems that only people who wants to keep traditional development method in their products are developers themselves (and of course connected project/product management). Our customers are completely supportive when it comes to eventual switch to agile software development and even our senior management it giving green light to this transformation. We are actually delivering small number of our projects in an agile manner and we have built quite large set of success stories already. But developers are still quite negative when agile is discussed in the scope of their particular product.
So far, I observed that it is close to impossible to switch to agile software development in a "Big Bang" style, this is actually well known experience. You need to administer only small portions of "agile" to the project teams one for each project cycle. And this is what this series of blogs will be about - about my experience of introducing agile in this very conservative environment, about specific points that I discovered on the way and about recommendation for any eventual followers.
Chapter 1 - First step towards being agile
First step is aways the most difficult one; the same applies here therefore it is very important to select "the best pill". This step should obviously bring a lot of value to show to the team that implementation of agile is actually win-win situation and that improvements can be expected even quite early during adoption process.It is not much beneficial to start teaching project teams whole new agile methodologies like for example SCRUM (not saying that SCRUM is bad) but it is important to introduce ideas of Agile first. This is the most important part of the whole transition, change of the spirit, change of the mindset of the team.
I found that for this purpose, Agile manifesto is the very best starting point. It summarizes everything important in 4 simple sentences (and well recently they added about 12 points with more practical principles). Unfortunately when you read it, it looks like bullshit bingo. It is so difficult for bright ideas to shine thru ...
So you need to identify something more practical for a real first step (just after showing manifesto - why not give it a change anyway). And first step, first implementation exercise should be then an "iterative development" including reviews with customers. This is the most valuable part of agile. If you implement just this point, you are half way there and your customer perception will improve - that is guaranteed.
Iterative development means that you need to introduce several reviews with your customer during your standard project run. Practical example: One of our major product has traditional release cycle that spans roughly across whole year (including periods of idling, waiting for customer inputs). Usually development team receives business requirements during Spring and build them till early Autumn. Customers are allowed to see actual implementation only very lately during October just few days before scheduled release to production. Switch to iterative development means that whole cycle is broken into for example 2 weeks 'iterations' and after each of this iteration team demonstrates to customers (and other people who are interested) result of their work. Of course it is important for a team to plan content of the iteration in the way that they will have something to show.
You will find this difficult - especially in so-called legacy products. Teams will say that is it impossible to demonstrate something just after 14 days (that only installation takes 10 days). Well, I said that first step is the most difficult. Agile software development has a unique feature of identifying weak areas of your product build process that are otherwise hidden (but still present and you have to pay for them anyway).
Good message is that you don't have to figure out how to do that - development team usually knows already what does it takes. It only needs a space to let it happen. And you customer will appreciate this, he will provide his feedback much sooner and team will still have a lot of time to incorporate all his comments. During this period, you will observe that a common mutual understanding spreads across development team and customers.
So to conclude: first pill towards agile is to break your build project cycle into "iterations".
To be continued ...
