How to start your own agile transformation in a large enterprise

In my last blog, I talked about the emphasis of large enterprise world toward lean agile software development methodologies. In addition, people are favouring “owning” their agile transformation rather than relying on external consultants to hand them one!

What does that mean to all those people out there still looking for help and answers on their quest for agile transformation, lost in the vast sea of enterprise IT? First and foremost, define your needs/challenges. What is the problem we try to solve? Defining the right problem has several advantages, one of which is easier to get management buy-in. Then get enough management support! This is another one of these crucial success factors. While it is possible in small organization for grass root agile movement to take hold, it is almost impossible to do so without management buy-in within a mid-large organization. You don’t necessarily to ask for “Agile” transformation, but ask for a chance to explore possible solutions to your needs/challenges in the first step. The next step is to find that guiding light. As with many other things, Google can be your friend or foe. You may decide to do the research yourself and start the transformation from the things you learned. Internet is full of resources on this, but information overload and misleading opinions also makes it very dangerous to place your bet on any literature you read online. As a sports enthusiast, I can assure you that the difference between learning any sport with or without coach is night and day. The top problem is that it is hard to unlearn bad habits. The time and money wasted on learning and then unlearn the bad habits is way more costly than paying for a good coach even before considering the damage done by the bad habits. So, getting someone to help you start the groundwork getting everything moving is the next critical step. Now, be aware of anyone or organization that promised the silver bullet solution. That doesn’t exist. Just like there is no magic herb that can treat all diseases, there is no one agile methodology or technique that can fit your organization right out of the box. If you have bought any COTS solution that supposed to work “out of box” for enterprise, they never do. Instead, look for someone with deep knowledge, patience, listening skills that can ask the right questions! As Peter Druker, father of management consulting, had proven time and time again, you hold the key to the true answer, consultants are just the torch to help you find the right door to open.

Hopefully, once the right help is found, you would have a great trip down the agile lane. But what happens when the Coach leaves, as they suppose to? I will follow up with my next blog.

Is #scaled-agile frameworks the next step or a mis-step?

Agile software development has become the mainstream for a few years, now. With the help of its successes in smaller and younger companies, larger and more traditional companies like banks are starting to experiment with them as well. Lately, scaled agile seems to be a hot topic. More structured frameworks like SAFe and DAD are becoming more popular by the day. Yet, there is strong resistance, and sometimes almost resentment, towards them from some agile practitioners. Everyone agrees agile needs to work at scale, the disagreement is whether that needs to be done under a seemingly more waterfall-like framework.

Interestingly, both frameworks mentioned above are started with people used to work in a large enterprise environment. Should we trust frameworks that came out of such traditionally non-agile settings? We all know that one of the major reputation issues with agile is people practicing wagile (waterfall agile) or scrumbut. What makes these self made frameworks better than the rest that people look down upon? Well, it turns out, a lot of the original Agile Manifesto signers worked in large enterprises. That proves good things can come out of these environments. In addition, having consulted in one of these enterprises, I can say that people who work in large enterprises are just as talented, creative, and sometimes free spirited as the rest. However, they also constrained by a lot more external factors like regulations, industry rules and standards, social pressure.

An experience agile coach Joe Little had an interesting correspondence with James O Coplien through one of his blog post on this very subject.  While James is obviously very knowledgeable in agile and especially Scrum, I agree with Joe’s point that explaining, much less convincing, most people about expanding the agile practices in a self-similar pattern is a quick way to send people to the clouds. It will be even worse talking to business executives like that who already have a preconceived notion that structure and rigid processes provide security and quality.

The biggest advantage I see in these frameworks is that it provides a more gradual transition path from waterfall to agile development. By implementing a more structures top layer (at portfolio or product line or business line level), they provides predictability and discipline required of public companies from the investor. That also gives more freedom to teams and business units to make decisions on lower level details.

It’s a balancing act. Just like one of my favorite quotes in agile, “take one bite at a time”. Doesn’t it make sense to approach agile at a large scale in the same way for some environments?

In a follow up discussion on this post, a number of very interesting points were posted here. Please continue reading the comments. The conclusion/ take away took a slight turn. Instead of evaluating the scaled agile frameworks, it is the detailed things we do and the ways we think that makes a difference. The frameworks, like a lot of other large frameworks, can be used as sounding board to reflect on our ways.