Thursday, March 09, 2006
Agility in Large Enterprises
Figured I would jump onto the conversation between Redmonk Analyst Cote and one of the most brilliant architects in the blogosphere: Scott Mark and bring my own perspective of agility in the enterprise...
It is somewhat useful for me to tell a story on my first conscious decision to embrace agile approaches. I remember back in 1998, I was assigned to work on a project for a large bank via a consulting firm in the area whose claim to fame happened to be quality-oriented processes and had a team of individuals assigned to ensure consistent process. Many of the folks at the firm were familiar with all of the wonderful work put out by the Software Engineering Institute on this topic.
I remember sitting in an executive's office who happened to have literally been a rocket scientist in India who asked me to go over the proposed software architecture. In this meeting, he also had not one but four different quality process people attend the meeting. I knew in advance that no one was actually technical so I would have some fun with it. I could almost count on the fact that those process folk would sooner or later jump into their own insular babble and that it probably didn't matter much what I presented as long as I presented something. Of course, I believe in doing rigorous software architecture but instead decided to print out all the sample models from Rational Rose and their representative UML for a fictitious bank and presented them. They knew I was describing a bank but didn't even know the problem-space in which I was supposed to be coming up with a solution...
In another part of my career when I was consulting, I had the privelege of working with some wonderful consultants that worked for McKinsey and remember having to deliver two different systems by a specified date. At the time, I had declared that I would take responsibility for one and needed a peer to own the other. When it came time to present our work, my peer unfortunately fell sick and I ended up covering for him. The system under my responsibility worked and was of high quality. The system under his responsibility didn't.
Anyway, he had asked one of his developers to document what was done to date and we would use this to present. I had reviewed this documentation the previous night and found it to be of such low quality. The next morning I caught the earliest flight to the client site and actually wrote the documentation for my peers system based on what I knew in conversation on the fly and drew up lots of pretty diagrams that kept everything at a high level.
When it was time to present, I of course presented the actual working software and showed the documentation related to it later. When it came to my peer's system, I presented to them the high-quality documentation I made up on the fly and they liked it. The scary thing is that they liked my BS more and chewed me out for the documentation I had produced for the system that actually worked.
One can become jaded based on experiences of the past. The key to agility is learning what went wrong in the past so that one can address it in the future. If I had to apply anything from my own experiences to leveraging agility in large enterprises it would be to acknowledge upfront that most people really don't understand...
The masses in large enterprises don't really understand software architecture, agile methods, SOA, UML or most things with a level of rigor. This of course, has resulted in enterprise architecture incorporating the notion of buy-in vs. doing what is right, questionable governance practices and for the most part blown IT budgets that have resulted in tons of Americans watching their jobs go offshore.
I originally started in IT in 1984 (high school) and worked at Cigna in a department named Application Field Services and had the most wonderful boss (Hi Michael) whom was not only a director but extremely technical. In fact, I remember him introducing me to his boss and bosses boss who were also very knowledgable about IT. I think this was the defining moment for me wanting to become an IT professional.
Essentially, when I started in IT, 95% of all folks either understood coding or some other aspect of technology. Over the long haul, the word IT morphed from a discipline to an organizational structure which non-technical resources to call themselves IT professionals. During this trend, IT as a profession also grew in importance and it meant that folks needed to put butts in seats. The phrase saying that as long as someone is a good manager, they don't need to know technology started to appear and the number of folks in IT that actually understood technology started its rapid decline.
Fast forward to 2006, there are folks asking about applying agility to large enterprises. The best we can hope for is to gain approaches where it is done in small pockets. Regardless of what anyone writes in any magazine, agility in large enterprises is not happening in any meaningful way. Acknowledging the fact that at best, maybe 25% of the folks in an IT shop nowadays are technical, agility simply offers zero value proposition for the masses. The masses cannot participate so agility can never prosper.
The one thing that I do hope Cote can uncover is not stories of agility and minor success stories done in enterprises. After all, this is just a positive spin on mediocrity but the root cause as to why more folks aren't embracing it. Agility can become a counterbalance to outsourcing and allow an enterprise to not only acheive the cost savings they seek but to also be community-oriented and patriotic in the process.
I had the idea that at least I could do my part to encourage agility in large enterprises but am close to throwing in the towel. Awhile back, I wanted to propose a panel for an industry conference in which I would moderate the topic of Agile Software Development in Large Enterprises. I wanted my panel to be solely comprised of architects that are full-time employees of Fortune 200 enterprises whose primary business isn't technology. I had enlisted the help of other agilists and actually found that many of them also practice a sinister form of command-and-control. None of them were interested in even presenting the idea to their clients as they felt they would lose control. It shocked me that they weren't interested in promoting agility to the masses but wanted to keep exclusivity within their own hands.
You may have noticed a somewhat inner-circle mindset within the agile community that could become borderline dangerous over time which even makes me sometimes hesitant to encourage my peers in other enterprises from walking down this path. Many enterprises have embraced other emerging methodologies such as Six Sigma. I bet you that none of the enterprises walking the Six Sigma path can tell you who even the founding members of the movement were. Six Sigma has grown immensely because the founders let it grow beyond them.
Open source is no longer about Eric Raymond, Richard Stallman, etc because they were wise to let it grow and flourish. In the agile community, this simply hasn't happened nor do I think it will. Maybe, Cote should explore this dimension?
| | View blog reactionsIt is somewhat useful for me to tell a story on my first conscious decision to embrace agile approaches. I remember back in 1998, I was assigned to work on a project for a large bank via a consulting firm in the area whose claim to fame happened to be quality-oriented processes and had a team of individuals assigned to ensure consistent process. Many of the folks at the firm were familiar with all of the wonderful work put out by the Software Engineering Institute on this topic.
I remember sitting in an executive's office who happened to have literally been a rocket scientist in India who asked me to go over the proposed software architecture. In this meeting, he also had not one but four different quality process people attend the meeting. I knew in advance that no one was actually technical so I would have some fun with it. I could almost count on the fact that those process folk would sooner or later jump into their own insular babble and that it probably didn't matter much what I presented as long as I presented something. Of course, I believe in doing rigorous software architecture but instead decided to print out all the sample models from Rational Rose and their representative UML for a fictitious bank and presented them. They knew I was describing a bank but didn't even know the problem-space in which I was supposed to be coming up with a solution...
In another part of my career when I was consulting, I had the privelege of working with some wonderful consultants that worked for McKinsey and remember having to deliver two different systems by a specified date. At the time, I had declared that I would take responsibility for one and needed a peer to own the other. When it came time to present our work, my peer unfortunately fell sick and I ended up covering for him. The system under my responsibility worked and was of high quality. The system under his responsibility didn't.
Anyway, he had asked one of his developers to document what was done to date and we would use this to present. I had reviewed this documentation the previous night and found it to be of such low quality. The next morning I caught the earliest flight to the client site and actually wrote the documentation for my peers system based on what I knew in conversation on the fly and drew up lots of pretty diagrams that kept everything at a high level.
When it was time to present, I of course presented the actual working software and showed the documentation related to it later. When it came to my peer's system, I presented to them the high-quality documentation I made up on the fly and they liked it. The scary thing is that they liked my BS more and chewed me out for the documentation I had produced for the system that actually worked.
One can become jaded based on experiences of the past. The key to agility is learning what went wrong in the past so that one can address it in the future. If I had to apply anything from my own experiences to leveraging agility in large enterprises it would be to acknowledge upfront that most people really don't understand...
The masses in large enterprises don't really understand software architecture, agile methods, SOA, UML or most things with a level of rigor. This of course, has resulted in enterprise architecture incorporating the notion of buy-in vs. doing what is right, questionable governance practices and for the most part blown IT budgets that have resulted in tons of Americans watching their jobs go offshore.
I originally started in IT in 1984 (high school) and worked at Cigna in a department named Application Field Services and had the most wonderful boss (Hi Michael) whom was not only a director but extremely technical. In fact, I remember him introducing me to his boss and bosses boss who were also very knowledgable about IT. I think this was the defining moment for me wanting to become an IT professional.
Essentially, when I started in IT, 95% of all folks either understood coding or some other aspect of technology. Over the long haul, the word IT morphed from a discipline to an organizational structure which non-technical resources to call themselves IT professionals. During this trend, IT as a profession also grew in importance and it meant that folks needed to put butts in seats. The phrase saying that as long as someone is a good manager, they don't need to know technology started to appear and the number of folks in IT that actually understood technology started its rapid decline.
Fast forward to 2006, there are folks asking about applying agility to large enterprises. The best we can hope for is to gain approaches where it is done in small pockets. Regardless of what anyone writes in any magazine, agility in large enterprises is not happening in any meaningful way. Acknowledging the fact that at best, maybe 25% of the folks in an IT shop nowadays are technical, agility simply offers zero value proposition for the masses. The masses cannot participate so agility can never prosper.
The one thing that I do hope Cote can uncover is not stories of agility and minor success stories done in enterprises. After all, this is just a positive spin on mediocrity but the root cause as to why more folks aren't embracing it. Agility can become a counterbalance to outsourcing and allow an enterprise to not only acheive the cost savings they seek but to also be community-oriented and patriotic in the process.
I had the idea that at least I could do my part to encourage agility in large enterprises but am close to throwing in the towel. Awhile back, I wanted to propose a panel for an industry conference in which I would moderate the topic of Agile Software Development in Large Enterprises. I wanted my panel to be solely comprised of architects that are full-time employees of Fortune 200 enterprises whose primary business isn't technology. I had enlisted the help of other agilists and actually found that many of them also practice a sinister form of command-and-control. None of them were interested in even presenting the idea to their clients as they felt they would lose control. It shocked me that they weren't interested in promoting agility to the masses but wanted to keep exclusivity within their own hands.
You may have noticed a somewhat inner-circle mindset within the agile community that could become borderline dangerous over time which even makes me sometimes hesitant to encourage my peers in other enterprises from walking down this path. Many enterprises have embraced other emerging methodologies such as Six Sigma. I bet you that none of the enterprises walking the Six Sigma path can tell you who even the founding members of the movement were. Six Sigma has grown immensely because the founders let it grow beyond them.
Open source is no longer about Eric Raymond, Richard Stallman, etc because they were wise to let it grow and flourish. In the agile community, this simply hasn't happened nor do I think it will. Maybe, Cote should explore this dimension?
