Guerilla Scrum: How to force organisational change

Situation

Many organizations do not dare to change themselves although everyone knows that things do not work well. Usually real working employees have a good feeling that things are going wrong. Unfortunately they do not have the power to trigger change but expect middle management to do so. Usually top management expects everyone to do the best job and will ask questions to middle management if things go wrong. Therefor middle management is sandwiched with expectations - this is a hard job to handle and needs explicit skills.

People tend to keep an organisational status quo for several reasons:

• Why change anything? Never change a running system.
• A change would have impact on many parts of the organisation, we just can't do this.
• We do not have time for changes.
• We do not have budget for changes.
• We can't change anything due to laws and external regulations.
• We already tried to change things but it didn't work.
• My boss forbids change.
• I do not change anything so that I am not responsible for any fault.

Analysing any single reason not to change an organisation leads to the basic cause: fear-driven management avoids organisational change.


Solution

Four phases as follows are needed to overcome fear-driven management and force organisational change.

1. Guerilla Scrum

Guerilla Scrum is about just starting to change things in your own local scope of influence. Simply start your next project by applying scrum. Even if you have to deal with scrumbuts like missing product owners or an unprepared team you should start scrumming. Try to live scrum with all the few details it prescribes. Just do it and the results will prove your right decision.

If you can't setup a scrum team or if you are bound to a running project, then try to apply as many of the following:

• Inspect and Adapt: setup timeboxes of several weeks in your project and bring together all team members on a regular basis to do retrospectives of these timeboxes. Do this to find obstacles and impediments and remove them as soon as possible.
• Direct Contact: bring people together. Make people communicate with each other. In many projects people talk to the project manager only instead of talking with the co-worker in the neighbour room. Force them to work in direct contact.
• Show Progress: use the mentioned timeboxes and give a project presentation at the end of such a box. Make the team responsible to demonstrate what they have achieved. Try to invite your product manager or whoever is the major project stakeholder from the business point of view. Convincing this business guy is important for the next point.
• On-site Customer: bring in the convinced product manager to talk to the team. Use this direct contact to clear requirements and get a better understanding of each other.

You will see huge overall improvements after repeating these things two or three times.


2. Push into Organisation

Visit the barber, jump into your best suit and get ready for marketing: make your improvements visible to other parts of the organisation.

Do not promise the silver bullet! Do not promise infinite ROI and do not promise vast improvements by presenting the theory of a new method!

Simply present the real, measurable improvements of your guerilla scrum. Just mention a few words about "agility" and "scrum", just give an indication of doing things differently than before.

You should explain some details of your scrum to the next neighboured managers: show them the daily micromanagement, the tracking of all things, the planning, everything - and let them be both surprised and confused. They will need time to think about what they saw.


3. Expect Growing Interest

The word will spread through your organisation: the product manager will talk to her colleages, your manager will mention improvements of his department with a new method. Other people will take notice of you and your team.

Members and managers of other departments probably will contact you to learn more. Use this chance to give a presentation on agile methods. Set a date for a workshop on timeboxing, agile estimating, or any other interesting agile topic.

Don't forget: always include step 2. and continuosly present your real improvements!

Persuade as many stakeholders as possible.



4. Use Multiplicators

Time will come when someone will have entered the agile train. Maybe another project manager read a book, joined a conference, or actively went into agile in any other way. There will be people getting the big picture and have their eyes opened.

Use these people, they are your allies! Let them spread the word for you. Support them and get supported in return.

Ideally some of these people are from top management - these are your wanted multiplicators! Try to sandwich your middle management organisation with agilists: persuated managers and successful, improving project teams.

When enough people are on your side, being agile becomes common sense and will not be questioned any longer.


Conclusion

Every organization is able to achieve major improvements. Overcome fear-driven management by proving results of guerilla scrum. Do marketing and present your real improvements and results. Persuade as many people as you can, so that being agile becomes common sense.

The most import agile principle of "Inspect and Adapt" will help your organisation to embrace change - so finally you reached your goal.

Explaining Agile Projects

Here are some impressions of expressionistic drawings while I explained how we do Agile Projects to some people.

The complete picture

This drawing covers a lot of aspects. Try to find as many as possible:

• Definition of Done
• Iterative cycle of system qualification (testing) and bug fixing (development)
• The need to release multiple software products due to shared components
• V-Model (with a substitution of level "P"roduct with "F"eature)
• 50% buffers
• Parkinson's Law
• Feature Branching Strategy

Single Point of Communication

In organizations without fully implemented Scrum teams there always are victims in the center of all other groups. The poor guys in the middle (old fashioned project managers) are flooded with questions from the developers and testers (left) and instantly have to pull answers from the business guys (right). As a result, they constantly jump from left to right and vice versa.

Agile Process Refinement

This image shows an approach to implement mixed agile processes to an organization:

• Discuss about features on an epic level with top management. Call this FDD for these guys and show them the FDD process - they do not need more details.
• Refine these epic features and create detail feature specifications with the lower management and business people. I call this F++ just for fun. They want to discuss implementation details and user interfaces - in fact, this is where user stories are created.
• Implement Scrum (or better: ScrumBut) for the development and testing team, use task boards, burndowns, dailies, and retrospectives.
• Major goal in this drawing: pull the business guys into the Scrum team and convert them into real product owners.

ScrumBut: The "Agile" Buzzwords

A normal day in the office. I tried to get more details for some stories from a product owner. Half an hour before lunch time a co-worker entered the room, we did some small talk and made an appointment to go for a walk'n'talk later.

Suddenly he wondered about the book on my desk: "Agile Retrospectives" by Esther Derby and Diana Larsen (http://bit.ly/cvoaH). He took a look at the back and read "Project retrospectives help your teams examine what went right--and what went wrong--on a project."

He instantly asked "Why is any new book called 'agile'? There are enough 'agile' books on the market. Is there any need for a book on retrospectives? Doing retrospectives is a common project management method, so what for do we need that 'agile' buzzword for retrospectives?"

In my point of view we need the 'agile' buzzword for everything we do! Why? Simply to intensify our agile project marketing. There are lots of stakeholders who still do not understand what it means being agile. We have to throw all that agile mumbo-jumbo around so that they get the chance to ask what we are talking about.

"We have to get higher quality, faster development, more features realized, so we will use a bunch of agile best practices. But whatever we are going to do, the most important thing is to control everything in a closed-meshed manner. And we need key performance figures."

The biggest ScrumBut in this quote is "use a bunch of agile best practices": do some planning poker here, take the name 'feature' from FDD, talk about Critical Chain project management, and write a 40 pages definition of those 'best practices'. Will such an approach have any chance for success? I doubt it.

Lets take a look at the other points of the quote. You want to control everything? Of course, you can, it's no problem at all: daily scrums, iteration reviews, and product demonstrations will assure controlling. You want figures? Just collect our agile metrics and you have them: velocity, burndowns, number of stories done, and so on. But what is the goal of controlling and collecting figures? We want to improve our team, our methods, our agility. The best way to improve is by implementing retrospectives the agile way (just read the book on my desk if you want to know more http://bit.ly/cvoaH).

Once a manager said: "Could you please stop talking about 'timeboxing'! This concept is so old and it's common sense to keep track of my project at least once a week. I don't want to hear that term 'timeboxing' any longer!"

"Timeboxing is not about frequent progress tracking, it's about fixed lengths of meetings and iterations. You even can timebox our release if we have to be date-driven. If story priorities change at the end of the timebox, some lower valued stories will just be moved into the next release", I replied.

"What do you mean 'moved into the next release'? You gave the promise to implement this set of features for this release at the planned date."

"You know reality. Project scopes change constantly, things may be decided to be more important this month and less important next month. Additional features are moved into a project and some other features get too large to be implemented at the proposed date. If your goal is to release twice a year, we have to timebox our releases to 6 months. This will guarantee a sustainable pace for the releases. If additional requirements get into a release, some other stories have to move to a later release. Otherwise we will not be able to guarantee a new release of the product every 6 months. Even worse: the succeeding release will be delayed before it ever started."

Somehow my last sentences opened his eyes at least a little. But that ScrumBut discussion has not been finished yet. I will report the results of our next discussions, of course.

The team leader of a group of developers once said: "we will not do iterations. That would be too many changes for the team, let's just do this feature driven-development now. If this works, maybe we can do some more."

This one is a heavy ScrumBut: do half of some agile method. Without iterations every other advantage of being agile gets lost completely. You would win nothing if you had to take a look at the project's results half a year later for the first time. Iterative planning and iterative retrospectives are so important that they must not be skipped by any means!


If you want to know more about ScrumButs, take a look at Ken Schwaber's site http://www.controlchaos.com/. Some interesting thoughts about ScrumButs can be found in http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html.

Daily Tracking

A big advantage of the perfect world of strong, deterministic, complete, overwhelming and unchangable project scopes is that you can track your progress on a micro percent basis, two post commas included. All glory to the waters falling from beginning to end!

Suddenly everything is different in the real world where we live such wondrous things like Scrum.

I was asked by a senior project reviewer how I do track the progress of my projects. He was wondering about missing work breakdown structures with assigned resources and working hour efforts - none of that was in my pro forma MS Project plan.

I told him about story point estimated, feature story based release planning and burndowns. "OK, but..."

I told him about iteration planning, task breakdowns of stories, task estimates in hours, daily scrums, daily progress, daily tracking, daily burndowns, daily knowing-what-happened-what-will-happen-and-what-the-issues-are. His eyes got wide and he said "wow, I'm really impressed of such direct, short-term feedback cycles. Let's give it a try. I'm curious about the results of the next weeks."

Satisfied we left the meeting and yet another time I thought how easily critical people get persuated simply by explaining the details of what we're doing on a daily basis.

Praise the Daily Day!