The Enterprise goes Agile! With the elegance of the huge battleship being pulled across a desert between oceans by slaves, camels and elephants, the Enterprise goes Agile. You can hear the songs and you can feel the hot air vibrating from thousand chests:
Agile, Agile is the way,
nothing can stop us, now,
when we discovered the true way…
You can also hear the drums… BUM BUM BUM… and the crack of the whip…
The Enterprise knows how to implement a new process. So many were implemented before, distinguished predecessors like CMM, CMMI, SPICE, ISO 9000, ISO 12207… even Six Sigma. Waterfall, iterative, spiral, top-down and bottom-up, unified and so many others… and now… Agile is the new target.
And it is not that hard with that much experience. First you name somebody responsible for implementation. Then that somebody gathers a team around him. They are to become the Agile Task Force. Lots of things have to be planned and thought out for this new Agile thingie. We need consultants, trainers, manuals, pilot projects, tools, metrics and so many other details sorted out. The Enterprise cannot become Agile without planning everything in advance to the last detail.
One question is paramount: how do we measure the increase in productivity and quality. For this, new reports have to be designed and written. Developers have to be trained on how to fill them. Managers have to be trained on how to enforce and monitor metrics collection. New ways of reporting results up the hierarchy are imagined and documented.
If you think hard about it, Agile is just a particular case of waterfall. Agile is supposed to be flexible, isn’t it? And on the other hand there is no point in throwing away what was good before. It can even save a few thousand pages of process from being written from scratch. Just think about it.
Let’s see how Agile Scrum fits in the Enterprise.
The Enterprise is not just a gang of cowboy-developers coding along. Things are more serious in the Enterprise. But fortunately Agile allows for small changes and tune-ups, doesn’t it? So the Enterprise can adapt the process a bit to better fit its needs.
The normal Project Manager will be the Product Owner with a small modification – he doesn’t want to be a “pig”, he doesn’t like the name.
The Development Manager becomes the Scrum Master because he is committed and he doesn’t want to lose the grip on the project. He will also represent the team in higher level Scrum meetings, thus shielding the programmers from interruptions, distractions and information overload.
Since the Enterprise loves democracy when it doesn’t come with responsibility, everybody else is a “chicken”.
Scrum meetings are a bit of a problem in the Agile documentation – they are really really too often – so… because the Managers are already all the time in meetings this is too much. Another small change – the Scrum meeting will take place once every two weeks. But we can compensate and make it 3 hours instead of 15 minutes. And since we have the time why limit ourselves to three questions. We can discuss the project evolution in depth.
At this moment in the design of the Customized Scrum Process everybody starts to feel good about it. This Scrum thing is so powerful and flexible.
And then the “SPRINT” concept is grasped. It so perfectly fits with the way the Enterprise has done things for ever. So it is just natural that a sprint will take place for each of these phases:
- Requirements specification SPRINT
- Design SPRINT
- Implementation SPRINT
- Integration SPRINT
- Testing SPRINT
- Maintenance SPRINT
We’ve been Agile before, but we didn’t know it
Did you know RUP was Agile? Sure it was but they and us didn’t know it. It just needed a label at the time and somehow they didn’t call it Agile. It would have been RAP. But it is not too late, it still can become ARUP, RAUP, RUAP or RUPA. It is just a matter of time before they decide.
Many people are happy since the Enterprise decided to go Agile. There is a wind of change present in the air. People feel empowered. Many want to actively participate. They want to guide the developers, train the developers, measure the developers, manage the developers, lead the developers, show the Agile ways to developers.
All these people apply for positions to write Agile documents and standards and to evaluate/buy tools that will help the developers and more important the Management during this Agile transition and later when the Enterprise will be fully Agile.
Since there are so many things to be gained from being involved in the Agile Project people try to influence their way in these new positions so good to be put on any resume. All the other acronyms are there already, accumulated over years of implementing and replacing processes. The Agile keywords will be next.
The managers feel mixed about this whole thing. They understand the power of Agile but also they understand the power of distraction. Their reputation is also on the line. There are gains to be made but there are also dangers. The way to manage danger is to keep the development team in an iron fist. Agile is good but what if it fails. We need a backup. In parallel with all the Agile lightweight tasks the developers will have to make a little extra effort and do a full estimate upfront. Just to be sure we understand what we are getting into. Perfect idea, this will give the manager the opportunity to show he has a backup plan if the Agile thing goes astray.
Agile crows err… consultants
Everybody admits in the Enterprise – Agile is new and we don’t have experience. How can we take responsibility for something we don’t fully understand and know? But as always the solution is not hard to find: consultants. To help with all this major undertaking a professional Agile consulting company is hired. the price is high but the Enterprise prefers to pay as much as it takes for the best service.
The hired consultants even promised to make an effort and combine Agile with RUP. What a bargain. Everybody pats himself on the back. Now success is around the corner.
Agile 9 to 5 programmers
During the whole storm of changes caused by The Agile Project the developers have to be protected. They are told to have no worry. It will be simple. Nothing much different then what they are used to. There will be a little bit of time consumed with training, meetings and document and metrics recording. But just a bit, maybe 2 days a week… The rest will be almost the same.
This piece of information reassure the developers and they don’t fear Agile that much now. They’ve been through worse storms like the… better not to mention the acronym – around there are still people who declared that a success. Oh is it already 5pm? Time to go home.
The Agile Implementation is already under way for some time now. The Enterprise runs on the new Agile tracks like the TGV. The success is obvious, so obvious that most of the project people look for new challenges, new opportunities. The small market glitch that stopped the pilot project from being finalized and shipped is not really important. Things like this happen on the market. And the customer didn’t want to spend enough time as a stakeholder on that project. At least they got all the RUP documents. What is important is the fact that the concept works. Now the Enterprise can be Agile while the instrumental project people can look for the Next Big Thing.