Why is Scrum so widely adopted and so very dangerously deceptive
I was sitting in a meeting sometime ago with a company that was embracing Scrum like a ten year old being offered a warm plate of chocolate chip cookies. They were grabbing at it as fast as they're little hands could reach out and grab the goodies.
Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time with in budget. Over the past years they refused every single proposed process improvement recommendation made by dozens of consultants. They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. After spending some time pondering this and interviewing a few people I found the answers I was looking for.
Scrum was allowing them to preform the magic trick of perceived success better than they had ever been able to before just using the generic fake Agile process. A scary realization. This of course was not the fault of the Scrum process. It was the team's refusal to truly change anything except a few timelines, titles of individuals, and a few names like iteration to sprint.
First lets look at the developers. Scrum did not require the developers to change anything they were doing except code less in a given iteration (now called sprint) because the only required change imposed on them was shorter deadlines. They were still not required to adopt agile programming practices, because the scrum process they implemented didn't advocate for change at a developer level, only a middle management level.
No code reviews, no difference in testing, no difference in the use of patterns or TDD, no difference in anything except, now missed deadlines were written off to "we are not only agile we are Scrum, push it to the next sprint". Bugs… they don't exist, they are errors or simply new requirements that need new user story written for them. Of course their favorite part of the process they implemented is that there is no design or architecture involved. Just cowboy coding as fast as their little fingers can spew the crap out to the screen.
Project managers were renamed Scrum Masters. They were not given the responsibilities of the role of Scrum Master as defined by scrum. They simply changed role names and continued to project manage.
Upper management doesn't care. They are planning the same and paying the same prices for projects. They are getting reports that improvements are taking place, but don't bother to look at the bottom line which isn't actually changing.
None of the several projects run under Scrum have come in within budget, on time, or any less buggy. It just shows me that the same thing I have watch over the years is still happening with software development process. Most places are only pretending to adopt them. The same sad truth remains, that they actually usually think that they are changing. They are whole organizations in denial about their development environments.
Like I said above this is not the fault of Scrum. I have seen it make improvements, but only when change actually happens. It must happen at the upper management level, the project (middle) management level, and huge changes have to happen at the developer level. Architecture on any decent size project is just as important as it ever was, so to think you can do without it is naïve and shows immaturity. I have been seeing the Waterfall syndrome happening way too much with Scrum. People look at the picture and read a few lines of information about the process and think they got it. Waterfall was iterative, people simply did not read the entire paper behind the diagram. Scrum needs much more implemented than the time management aspects shown in the diagram.
Agile processes require agile development practices, which include architecture and design. Without them, you are only pretending to execute Scrum. I would recommend taking a look at the Scaled Agile Framework. Scrum is one small blip in the big picture of enterprise development.
How do you avoid this company's same fate? Bring in an outside consultant who knows software process engineering and put them in charge. Your team's best thinking have gotten them to where they are today, if that is not where you want your company to be, their best thinking won't get you anywhere different tomorrow. I have now seen Scrum transform one organization's development team and process, but that team brought in a consultant and allowed that consultant to lead the initiative. Although there was some resistance to the changes being made, because a majority of the team went along with them, the rest eventually followed.
I do not believe Scrum offers anything more than any other process including OpenUP, the Unified Process, RUP, XP, etc. Where the difference between success and failure lies is in the implementation of them, actually executing them with someone who has successfully executed them on multiple projects, and your willingness to take and execute their advice. That will mean change. Change in skill sets of your people, or change in your people, but to believe you can go from using no process to implementing any of these processes without help and changing is just naive and guaranteed to fail. That is unless you fake it like the company from this blog did and so many others I have seen do.
Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time with in budget. Over the past years they refused every single proposed process improvement recommendation made by dozens of consultants. They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. After spending some time pondering this and interviewing a few people I found the answers I was looking for.
Scrum was allowing them to preform the magic trick of perceived success better than they had ever been able to before just using the generic fake Agile process. A scary realization. This of course was not the fault of the Scrum process. It was the team's refusal to truly change anything except a few timelines, titles of individuals, and a few names like iteration to sprint.
First lets look at the developers. Scrum did not require the developers to change anything they were doing except code less in a given iteration (now called sprint) because the only required change imposed on them was shorter deadlines. They were still not required to adopt agile programming practices, because the scrum process they implemented didn't advocate for change at a developer level, only a middle management level.
No code reviews, no difference in testing, no difference in the use of patterns or TDD, no difference in anything except, now missed deadlines were written off to "we are not only agile we are Scrum, push it to the next sprint". Bugs… they don't exist, they are errors or simply new requirements that need new user story written for them. Of course their favorite part of the process they implemented is that there is no design or architecture involved. Just cowboy coding as fast as their little fingers can spew the crap out to the screen.
Project managers were renamed Scrum Masters. They were not given the responsibilities of the role of Scrum Master as defined by scrum. They simply changed role names and continued to project manage.
Upper management doesn't care. They are planning the same and paying the same prices for projects. They are getting reports that improvements are taking place, but don't bother to look at the bottom line which isn't actually changing.
None of the several projects run under Scrum have come in within budget, on time, or any less buggy. It just shows me that the same thing I have watch over the years is still happening with software development process. Most places are only pretending to adopt them. The same sad truth remains, that they actually usually think that they are changing. They are whole organizations in denial about their development environments.
Like I said above this is not the fault of Scrum. I have seen it make improvements, but only when change actually happens. It must happen at the upper management level, the project (middle) management level, and huge changes have to happen at the developer level. Architecture on any decent size project is just as important as it ever was, so to think you can do without it is naïve and shows immaturity. I have been seeing the Waterfall syndrome happening way too much with Scrum. People look at the picture and read a few lines of information about the process and think they got it. Waterfall was iterative, people simply did not read the entire paper behind the diagram. Scrum needs much more implemented than the time management aspects shown in the diagram.
Agile processes require agile development practices, which include architecture and design. Without them, you are only pretending to execute Scrum. I would recommend taking a look at the Scaled Agile Framework. Scrum is one small blip in the big picture of enterprise development.
How do you avoid this company's same fate? Bring in an outside consultant who knows software process engineering and put them in charge. Your team's best thinking have gotten them to where they are today, if that is not where you want your company to be, their best thinking won't get you anywhere different tomorrow. I have now seen Scrum transform one organization's development team and process, but that team brought in a consultant and allowed that consultant to lead the initiative. Although there was some resistance to the changes being made, because a majority of the team went along with them, the rest eventually followed.
I do not believe Scrum offers anything more than any other process including OpenUP, the Unified Process, RUP, XP, etc. Where the difference between success and failure lies is in the implementation of them, actually executing them with someone who has successfully executed them on multiple projects, and your willingness to take and execute their advice. That will mean change. Change in skill sets of your people, or change in your people, but to believe you can go from using no process to implementing any of these processes without help and changing is just naive and guaranteed to fail. That is unless you fake it like the company from this blog did and so many others I have seen do.
posted by tadanderson at 6:03 AM
0 Comments:
Post a Comment
<< Home