Does Agile Work?
I want to start this article by mentioning that, at one time, I was not a proponent of Agile at all. I worked on a number of projects, which were stalled or failing, called Agile projects. In short, they were really a warped perspective of "Agile", or what everyone thought was "Agile" tangkasnet. In reality, these projects were the same old Waterfall/ SDLC projects, using the meetings and terminology of Agile.
Does Agile work? Just like any tool, when implemented correctly it works. However, throughout my career, I have witnessed it being implemented incorrectly, whereby one environment after another had contorted the methodology to fit very outdated, inefficient processes, as opposed to re-evaluating the process to fit the methodology, which would have rendered an optimum result.
Will Agile work in our environment? Agile has been successful in numerous environments, large and small, including some environments with the most stringent standards; for instance, Healthcare, Banking & Finance, Insurance, Technology and Retail with Payment Processing, to name but a few. Agile isn't always a quick flipping of the switch, however. This is why I have coined what I refer to as my 35/35/30 rule. When implementing Agile, 35% of the group will jump on board with no question, another 35% will convert over after some period of time, and then there is 30% that will not move and will have to be, let's say, urged to move over. The biggest issue with the 30% is that they can drag down the other 70% if executives do not mitigate this challenge promptly.
With all of that being said, why is there such a big push towards Agile? I would have to say that the biggest advantage of Agile is Quick Course Correction. Agile allows businesses to make changes quickly, reach the market faster and experience a faster R.O.I. One of the aspects I like most about Agile is the transparency and inspection. Of course, depending on who you are speaking with, this may or may not be viewed as a strength of Agile.
Why are there teams that do not like Agile? Over the years, I have found that those who are very much opposed to Agile don't actually have a problem with Agile itself; rather, they don't like the visibility and accountability that comes with Agile. Personally, I have become a very big fan of the Scaled Agile Framework (SAFe) by Dean Leffingwell, because of its ability to scale into enterprise environments, while rendering almost immediate results. Much of this results is attained by clear process and accountability that once may have been missing.
What about those environments that are having difficulty with Agile and its implementation? In my findings, I have noticed a consistency among those having difficulty with implementing the methodology. Agile is a methodology that does require full commitment, or there will be issues. This is why these "Water-gile" or "SCRUM-afall" spin off projects are having difficulty in succeeding. Of all these Agile-like project leaders having problems, I found that every one of them had contorted the Agile methodology into a half-baked version of Waterfall and SDLC, methodologies which typically have less than a 34% chance of success (worse than Vegas Odds). The problems that plague Waterfall/ SDLC projects would be an insurmountable amount of overhead adding little or no value. They have extremely long discovery phases that produce documentation which is often left unread or maintained; documentation that will be out of date when the first revision of the software appears. There are also extremely long Quality Assurance cycles that choke the process even further. While many individuals feel that this is all necessary, the end goal is missed: producing a product. These "Water-gile" or "SCRUM-afall" projects produce countless documents and Q & A plans, but not one line of code is written, nor one piece of hardware put in place. However, they do have documentation, which would be great if that made the company profits, rather than costing the company money.
I find much of this interesting, because I remember a time when there was a developer and business unit representative, and that was all. Working, high quality software was produced at break-neck speeds. And if there were issues, they were dealt with immediately.
So, many may ask, "Why does the inbreeding of Waterfall / SDLC with Agile not work?" For starters, they are polar opposites. Using Waterfall and Agile together is like trying to go left and right at once, or up and down at the same time. If 50% of the team's effort goes left and 50% of the efforts go right, the sum gain is 0. This is why, when a firm goes to Agile, they need to go to Agile, and not shoehorn in a massive amount of Waterfall/ SDLC process and documentation into the methodology. This approach won't work; it will cost more and will increase the odds of failure exponentially.
Now, many of you may be thinking that you don't want to change too much, too soon; so that there is no culture shock. After numerous Agile transitions/ implementations, I can promise that there will be culture shock no matter whether you trickle in Agile or go full steam ahead. My advice is to always make the transition as fast and painless as possible, but avoiding a shock to the environment is going to be impossible, especially in environments that have been using Waterfall or SDLC for decades. If the goal is to cause the least disruption, then make the switch and be done with it, don't drag it out for years.
Do these Agile implementations stall or fail? I recall, not long ago, an executive with a firm (which I will leave unnamed) mentioned that they were tired of Agile. This person said it didn't work and was costing them much more than expected. After some investigating, it became clear that they were not doing Agile at all. They were doing Waterfall with Agile meetings. Not only did they still have the old expensive processes surrounding Waterfall, but they also had 70% of their team in meetings, almost all day long - and then they wondered why nothing was getting done! The other issue that plagued this environment was that there were a number of individuals who were sabotaging the Agile efforts to protect their own agendas. Now, many would say, "What kind of impact can a few people have on derailing an enterprise project?" My response would be to mention the Costa Concordia shipwreck, in which one individual's self-serving decision cost numerous lives and 100s of millions of dollars in damages. That was only one person and one decision. Just imagine the effects of numerous individuals making numerous poor decisions.
However, there are many who think that adding Agile and Waterfall/ SDLC together will offer the best of both worlds. I can't say that I have witnessed this work. I can personally recall numerous projects I inherited that were stalled and failing, in which more than half of the budget was exhausted, without one line of code or one piece of hardware being implemented. While these heavy processes were standard back in those days, they were counter-productive, riddled with bureaucracy, and bogged down with politics/ personal agendas and inefficiencies. For instance, there was an environment that took almost 27 individual steps to complete one User Story because they wanted to use Agile and Waterfall together - not 3 or 4 steps, but 27! Agile is about rolling up the sleeves and getting the work done. It is not about rolling up the sleeves and writing documentation that won't be read, sitting in planning meeting after planning meeting with no outputs or writing test cases for software that has never been written. As a matter of fact, heavy meetings and documentation are exactly what Agile is not about tangkas. This is why, when teams are making the move to Agile, I urge upper management to remove all the meetings from the calendars and replace them with SCRUMxp/ SAFe meetings. Then, add meetings back, as necessary and if warranted, but this should be a rarity. In my humble opinion, if the management is not monitoring meetings closely, then it is begging for huge productivity problems.
What else isn't Agile? "We can't do Agile here because our business is unique." As a consultant who has taken part in numerous projects with very strict governance standards, I have been exposed to almost every model in the book. Everyone wants to believe that their environment is unique. It gives them a feeling of worth to think that what they do is unique and nobody else can do it like they can, but in the end, they have tasks, deadlines and budgets just like the rest of us.
Does Agile work? Just like any tool, when implemented correctly it works. However, throughout my career, I have witnessed it being implemented incorrectly, whereby one environment after another had contorted the methodology to fit very outdated, inefficient processes, as opposed to re-evaluating the process to fit the methodology, which would have rendered an optimum result.
Will Agile work in our environment? Agile has been successful in numerous environments, large and small, including some environments with the most stringent standards; for instance, Healthcare, Banking & Finance, Insurance, Technology and Retail with Payment Processing, to name but a few. Agile isn't always a quick flipping of the switch, however. This is why I have coined what I refer to as my 35/35/30 rule. When implementing Agile, 35% of the group will jump on board with no question, another 35% will convert over after some period of time, and then there is 30% that will not move and will have to be, let's say, urged to move over. The biggest issue with the 30% is that they can drag down the other 70% if executives do not mitigate this challenge promptly.
With all of that being said, why is there such a big push towards Agile? I would have to say that the biggest advantage of Agile is Quick Course Correction. Agile allows businesses to make changes quickly, reach the market faster and experience a faster R.O.I. One of the aspects I like most about Agile is the transparency and inspection. Of course, depending on who you are speaking with, this may or may not be viewed as a strength of Agile.
Why are there teams that do not like Agile? Over the years, I have found that those who are very much opposed to Agile don't actually have a problem with Agile itself; rather, they don't like the visibility and accountability that comes with Agile. Personally, I have become a very big fan of the Scaled Agile Framework (SAFe) by Dean Leffingwell, because of its ability to scale into enterprise environments, while rendering almost immediate results. Much of this results is attained by clear process and accountability that once may have been missing.
What about those environments that are having difficulty with Agile and its implementation? In my findings, I have noticed a consistency among those having difficulty with implementing the methodology. Agile is a methodology that does require full commitment, or there will be issues. This is why these "Water-gile" or "SCRUM-afall" spin off projects are having difficulty in succeeding. Of all these Agile-like project leaders having problems, I found that every one of them had contorted the Agile methodology into a half-baked version of Waterfall and SDLC, methodologies which typically have less than a 34% chance of success (worse than Vegas Odds). The problems that plague Waterfall/ SDLC projects would be an insurmountable amount of overhead adding little or no value. They have extremely long discovery phases that produce documentation which is often left unread or maintained; documentation that will be out of date when the first revision of the software appears. There are also extremely long Quality Assurance cycles that choke the process even further. While many individuals feel that this is all necessary, the end goal is missed: producing a product. These "Water-gile" or "SCRUM-afall" projects produce countless documents and Q & A plans, but not one line of code is written, nor one piece of hardware put in place. However, they do have documentation, which would be great if that made the company profits, rather than costing the company money.
I find much of this interesting, because I remember a time when there was a developer and business unit representative, and that was all. Working, high quality software was produced at break-neck speeds. And if there were issues, they were dealt with immediately.
So, many may ask, "Why does the inbreeding of Waterfall / SDLC with Agile not work?" For starters, they are polar opposites. Using Waterfall and Agile together is like trying to go left and right at once, or up and down at the same time. If 50% of the team's effort goes left and 50% of the efforts go right, the sum gain is 0. This is why, when a firm goes to Agile, they need to go to Agile, and not shoehorn in a massive amount of Waterfall/ SDLC process and documentation into the methodology. This approach won't work; it will cost more and will increase the odds of failure exponentially.
Now, many of you may be thinking that you don't want to change too much, too soon; so that there is no culture shock. After numerous Agile transitions/ implementations, I can promise that there will be culture shock no matter whether you trickle in Agile or go full steam ahead. My advice is to always make the transition as fast and painless as possible, but avoiding a shock to the environment is going to be impossible, especially in environments that have been using Waterfall or SDLC for decades. If the goal is to cause the least disruption, then make the switch and be done with it, don't drag it out for years.
Do these Agile implementations stall or fail? I recall, not long ago, an executive with a firm (which I will leave unnamed) mentioned that they were tired of Agile. This person said it didn't work and was costing them much more than expected. After some investigating, it became clear that they were not doing Agile at all. They were doing Waterfall with Agile meetings. Not only did they still have the old expensive processes surrounding Waterfall, but they also had 70% of their team in meetings, almost all day long - and then they wondered why nothing was getting done! The other issue that plagued this environment was that there were a number of individuals who were sabotaging the Agile efforts to protect their own agendas. Now, many would say, "What kind of impact can a few people have on derailing an enterprise project?" My response would be to mention the Costa Concordia shipwreck, in which one individual's self-serving decision cost numerous lives and 100s of millions of dollars in damages. That was only one person and one decision. Just imagine the effects of numerous individuals making numerous poor decisions.
However, there are many who think that adding Agile and Waterfall/ SDLC together will offer the best of both worlds. I can't say that I have witnessed this work. I can personally recall numerous projects I inherited that were stalled and failing, in which more than half of the budget was exhausted, without one line of code or one piece of hardware being implemented. While these heavy processes were standard back in those days, they were counter-productive, riddled with bureaucracy, and bogged down with politics/ personal agendas and inefficiencies. For instance, there was an environment that took almost 27 individual steps to complete one User Story because they wanted to use Agile and Waterfall together - not 3 or 4 steps, but 27! Agile is about rolling up the sleeves and getting the work done. It is not about rolling up the sleeves and writing documentation that won't be read, sitting in planning meeting after planning meeting with no outputs or writing test cases for software that has never been written. As a matter of fact, heavy meetings and documentation are exactly what Agile is not about tangkas. This is why, when teams are making the move to Agile, I urge upper management to remove all the meetings from the calendars and replace them with SCRUMxp/ SAFe meetings. Then, add meetings back, as necessary and if warranted, but this should be a rarity. In my humble opinion, if the management is not monitoring meetings closely, then it is begging for huge productivity problems.
What else isn't Agile? "We can't do Agile here because our business is unique." As a consultant who has taken part in numerous projects with very strict governance standards, I have been exposed to almost every model in the book. Everyone wants to believe that their environment is unique. It gives them a feeling of worth to think that what they do is unique and nobody else can do it like they can, but in the end, they have tasks, deadlines and budgets just like the rest of us.
Comments
Post a Comment