People some times wake up “Agile” no mater what.
After a few years, working on the customer site, things change a bit, and now we are working for the same client under a new OUT sourcing contract, so, I came back to the “home” office.
The first thing I have noticed back to the office was the “java team agile style”.
There is a task board on the wall;
The Java source code is under CVS control using “sprint” branches;
They have regular meetings every week…
So I need to ask my VB team mates: You are not agile yet? Why? Does your working environment let you be or become agile?
A few weeks later I realized that the point is not agile methodology but agile PHYLOSOPHY.
If your working environment doesn’t embrace the agile philosophy, there is no way to become agile no mater the amount of agile methodologies you use.
Some practical examples:
The weekly meetings were not focused on the project sprint deliveries, and soon they were disabled for the “big project” the java team was working on. And the other projects are not “big enough” to be selected by this kind of weekly meeting.
I need to implement an urgent but simple feature on the original java application they were working on (the big project). So I asked on which CVS “sprint” branch I should work and was told to use the 5th sprint.
Then I asked when the user have received this sprint, and was informed “No there is no sprint delivery to the client, we are working hard the last 6 (six) months implementing the new functionality and trying to integrate it with the original application”.
Well that is my point, why do they waste their time applying some agile methodologies if the overall philosophy remains waterfall.
This brings me back to the source “The Lean Principles”.
- Specify value from the standpoint of the end customer by product family.
- Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.
- Make the remaining value-creating steps occur in a tight and integrated sequence so the product will flow smoothly toward the customer.
- As flow is introduced, let customers pull value from the next upstream activity.
- As these steps lead to greater transparency, enabling managers and teams to eliminate further waste, pursue perfection through continuous improvement.
If we can put it on just one phrase, the “Lean Philosophy” is:
Do nothing but what gives to your customer some value.
So which is the value to the client on using the precious development time specifying and modeling the full feature; calculating Function Points for it, creating a document detailing each aspect of it, and implementing each of the possible functionality, with no delivering at all.
At the end we can see: if the enterprise still waterfall there is no way to be agile.
First of all we need the enterprises to become agile; we need the managers on both sides to become agile.
There is no way you could be agile if your manager insists on detailed upfront schedules.
There is no way to be agile if your manager insists on FPA for each functionality.
There is no way to be agile if your customer demands a huge amount of documentation.
There is no way to be agile if your customer demands a lot of form to be filled out just to get a new version of the application deployed.
So, managers, please read a few books about being agile, starting here.
And you folks, developers and other professionals try to share the agile philosophy before the agile methodology.
If you try to use agile methodologies into a “waterfall” environment, you are wasting your time a bit.
Good luck.
Posts
