How to kill your Company using an Agile Transformation

Nowadays you have a number of different possibilities to kill your company or to seriously impact its capability to deliver. As Agile methods and their application in the enterprise context continue to be very popular I want to explore your opportunities to do that using an Agile Transformation. Let us explore the steps and measures which will help you to achieve that.

Avoid Training People at all Cost

You have heard about agile methodologies rather often recently. It also seems that everybody is doing Agile right now. So, since everybody does it, it cannot be that difficult. It is mainly about delivering some piece of software in short cycles and naming your meetings differently, as far as you have seen. So that is straightforward to do and there is definitely no need to train your people. Furthermore people in Agile are self-motivated and will strive to improve continuously on their own, so they will take care for their education on their own anyways.

Just do a Big Bang Change

Since it is that easy to do, why should you actually bother to do a test run or pilot. You have made the experience that pilots have never uncovered anything you would use further down the road anyways. So basically, it is only a waste of time. If so much can be gained by switching to Agile, why wait?

Avoid Coaching of the Employees in the First Months

Like up front training, coaching in the first time is a complete waste of money. These coaches will only tell you that it is not about the meetings and the cycles, but that you actually have to change something about culture and mindset. This is not what you heard. The teams are self organizing, so they will find their way out of troubles with the method on their own.

Do it for Development only

Agile methodologies have been developed by developers for developers to make their life easier. But in the end they still deliver software, so it shouldn’t change anything to the outside world. It is therefore only fair to let the other departments untouched by that transformation and, at best, just tell them they will get things faster and much more flexibly, as you are now doing Agile.

Continue to accept Fixed Scope/Fixed Deadline Projects

As you already said to your requesting departments and customers, your transformation won’t change anything for them. It is therefore fair to say, that you still can accept Fixed Scope/Fixed Deadline Projects as before. The big advantage is that you are now way more flexible, so they can request changes up until the week before go-live without causing you any troubles.

Avoid Empowering People

The transformation should not leave you without control. Therefore, all the decisions should still be made by you or your upper management. This should not cause to much problems, as the teams are self-organizing and you and your management team are around at least once or twice a week. So there is no need for them to have the power to decide anything, which would maybe cause some trouble anywhere else.

Scale Agile without Governance

Since you make all the important decisions, you are ok if some tech stuff, which is not that important, is decided by the different agile teams. This is also better for the motivation of the teams. So you let them decide on sprint lengths and start times, tooling and technology on their own. Just because there are 10 or more teams in your company doesn’t mean they have to work together or have any points of contact, so it is completely ok to have different toolsets in each team.

Scale Agile without Architecture

You have read that architecture is emerging throughout the development. That sounds good to you, as these guys took way too long deliberating the pros and cons of different approaches anyway. So, instead of someone trying to tell these now self-organized teams what to do, the architecture will just evolve as the different teams deliver their part. And evolution is great. I mean, it brought forward mankind, right.

Scale Agile without a Systems or Integration Group

It is completely feasible to expect that all the teams understand the overall concepts and business processes of the overall system they are working on. It is therefore only fair, that you do not need someone to care about the architecture (see above). It is also only logical that these high performance teams will produce artefacts that just work upon integration into the overall system. A group dedicated to overall integration is therefore a complete waste.

Do it with the Wrong People

That is a tricky one. You have heard and read that this methodology is for high performance teams. Yet, after four weeks after Agile you still do not see any higher performance of your organization. And the people complain and just don’t seem to get it that they now have to be Agile. So maybe you should get rid of them and get some new people in who are better performers and are agile. The loss of knowledge cannot be that big that these high performance Agilists cannot pick it up quickly.

Or: if you believe that the methods described above seem like a good idea to do an Agile transformation, it might be you who is “the wrong people”!





Leave a Reply

Your email address will not be published. Required fields are marked *


Time limit is exhausted. Please reload CAPTCHA.