Probably the most interesting part of being the point-person for a pilot project at this large, slow moving organization is the extent to which everyone expects to be consulted before anything happens. I spent several days this week running from one office to the next trying to assuage concerns that we were running off half-cocked without talking to all the right people.
I spent a lot of time last week talking to folks from one of the business analyst/testing groups to make sure they were properly consulted and will continue to be consulted moving forward. Of course, the VP was just upset that she was not consulted when it was clearly relevant to her. She needed me to talk to her team. I talked to her team, and they’re all new to this company and passably familiar with Agile process. Their concerns are largely that they’ve been tooling up for a heavyweight waterfall shop, and that isn’t the same approach/skillset necessary to handle analysis/testing for an Agile shop.
I said … it’s only a pilot…you have automated testing, and that’s real important. And we’ll keep you in the loop. That seems to have been a sufficient answer. No one is upset as far as I am aware of now.
Wednesday, July 30, 2008
A Training Class
Several days of mad scrambling, and we got a training class. Advice to the reader: don’t look for an Agile training on short notice immediately before the Agile conference. It doesn’t tend to work that well. A couple bounces worth of communication from people who were not available, a whole lot of tussling with administrative overhead at my company, and we got a trainer.
Mitch Lacey came in and gave us a Scrum/XP overview with a bunch of worthwhile exercises, on a day and a half notice. We signed papers Wednesday evening. He taught a class all day Friday. His final planning game exercise was especially useful, and both the more experienced folks and the newbies got a bunch of useful information from the class. Probably, the funniest piece was the experienced Project Manager who wasn’t consulted in the decision to try this, and who is committed to trying to eventually take over my scrum-master role. His email to me on his way home was: “grey matter everywhere…not pretty”. Quite a bit of information overload for him.
Unfortunately, the IT Manager, and the business manager were not there, but we have a lot of support from both of them.
Good exercises from Mitch on learning curve, multitasking, responding to changes, and especially how planning works in Scrum/XP. We start rolling with a sprint zero on Monday, July 28, 2008.
Mitch Lacey came in and gave us a Scrum/XP overview with a bunch of worthwhile exercises, on a day and a half notice. We signed papers Wednesday evening. He taught a class all day Friday. His final planning game exercise was especially useful, and both the more experienced folks and the newbies got a bunch of useful information from the class. Probably, the funniest piece was the experienced Project Manager who wasn’t consulted in the decision to try this, and who is committed to trying to eventually take over my scrum-master role. His email to me on his way home was: “grey matter everywhere…not pretty”. Quite a bit of information overload for him.
Unfortunately, the IT Manager, and the business manager were not there, but we have a lot of support from both of them.
Good exercises from Mitch on learning curve, multitasking, responding to changes, and especially how planning works in Scrum/XP. We start rolling with a sprint zero on Monday, July 28, 2008.
My Agile Project's History
I’m a developer-type who’s been consulting for most of the last 10 years, but who recently (a year back) took a job at a large-ish firm of about 20,000 employees, and for whom about 4,000 are somewhat involved in the development process, including testers, Business Analysts, developers, hardware folks, etc.
When I joined the company, they were in the middle of the transition from a cowboy-coding shop to a heavyweight waterfall process, in order to comply with audit requirements (SOx, here we come). Unsurprisingly, the transition has been having some pain points. I can’t say I’m a supporter of heavyweight processes in the first place, but heavyweight processes just getting started, over-engineered, and for the purpose of compliance rather than effectiveness would be difficult to live with for anyone.
I’m a Java guy, brought in for my expert fu, and so I was somewhat shocked that we are in the process of adoption of such a methodology, when I thought waterfall died in the 90s. So, using all the persuasive powers I could muster, and a tremendous quantity of powerpoint presentations, I laid siege to the methodology. 52 weeks after I arrived, and about 50 weeks after I started talking about methodology and best practices, we have an Agile project to pilot.
The project is a rewrite of an existing system, with some enhancements, to be written using Java portlet technology (on Websphere). The project has a dozen developers, 3 business groups, a testing team, an architect, a process / documentation requirements guy, a project manager, and me…the agile guy/Java expert.
We’ve obtained buy-in for this pilot from several VPs, the whole IT management side, the process guy, the architect, and the business management team. Belatedly, we also asked the Dev team, and they seem to be onboard as well.
We have, on the team, several people with Agile experience: Myself, the architect, the process guy, the IT Big boss, and a test-lead.
The approach I have proposed using is an out-of-the-box scrum/XP, for a pilot, even though we all know that XP will under-produce documentation. Since we have the process guy onboard, we’re not going to have to get a blocker, or a tech-writer to chase us and write our docs for us, but we will likely have to produce more documentation than we otherwise would for a more pure XP-style project.
Also, as good news, we’re under high scrutiny, and pursuing a project that was looking like it would come in late/over-budget if a traditional approach was followed. That’s great both for justification reasons , and because we’ve already done a lot of estimating which we can compare ourselves to.
I’m most comfortable as a theory guy, though I also think that if theory doesn’t work, then you have bad (or inapplicable) theory. And my theory comfort-zone is an Agile start-point drifting towards lean process improvement.
Having wanted to be blogging to improve my written communication skills for some time now, I now have something to say that is very useful to do as a conversation. I’m starting a pilot agile project… something that an awful lot of folks have wanted to do, and will continue to want to do. This is, among other things, intended to be a chronicle of the process of taking a team that doesn’t speak agile, and moving them into an agile development world. With any luck, the expected successes in terms of productivity, cost, time-to-market that are well known as agile
When I joined the company, they were in the middle of the transition from a cowboy-coding shop to a heavyweight waterfall process, in order to comply with audit requirements (SOx, here we come). Unsurprisingly, the transition has been having some pain points. I can’t say I’m a supporter of heavyweight processes in the first place, but heavyweight processes just getting started, over-engineered, and for the purpose of compliance rather than effectiveness would be difficult to live with for anyone.
I’m a Java guy, brought in for my expert fu, and so I was somewhat shocked that we are in the process of adoption of such a methodology, when I thought waterfall died in the 90s. So, using all the persuasive powers I could muster, and a tremendous quantity of powerpoint presentations, I laid siege to the methodology. 52 weeks after I arrived, and about 50 weeks after I started talking about methodology and best practices, we have an Agile project to pilot.
The project is a rewrite of an existing system, with some enhancements, to be written using Java portlet technology (on Websphere). The project has a dozen developers, 3 business groups, a testing team, an architect, a process / documentation requirements guy, a project manager, and me…the agile guy/Java expert.
We’ve obtained buy-in for this pilot from several VPs, the whole IT management side, the process guy, the architect, and the business management team. Belatedly, we also asked the Dev team, and they seem to be onboard as well.
We have, on the team, several people with Agile experience: Myself, the architect, the process guy, the IT Big boss, and a test-lead.
The approach I have proposed using is an out-of-the-box scrum/XP, for a pilot, even though we all know that XP will under-produce documentation. Since we have the process guy onboard, we’re not going to have to get a blocker, or a tech-writer to chase us and write our docs for us, but we will likely have to produce more documentation than we otherwise would for a more pure XP-style project.
Also, as good news, we’re under high scrutiny, and pursuing a project that was looking like it would come in late/over-budget if a traditional approach was followed. That’s great both for justification reasons , and because we’ve already done a lot of estimating which we can compare ourselves to.
I’m most comfortable as a theory guy, though I also think that if theory doesn’t work, then you have bad (or inapplicable) theory. And my theory comfort-zone is an Agile start-point drifting towards lean process improvement.
Having wanted to be blogging to improve my written communication skills for some time now, I now have something to say that is very useful to do as a conversation. I’m starting a pilot agile project… something that an awful lot of folks have wanted to do, and will continue to want to do. This is, among other things, intended to be a chronicle of the process of taking a team that doesn’t speak agile, and moving them into an agile development world. With any luck, the expected successes in terms of productivity, cost, time-to-market that are well known as agile
Introduction
I'm hopping into the blogosphere now after watching for several years.
Focus should be all over the map.
Some politics, some agile/lean software, some education, among other things.
Focus should be all over the map.
Some politics, some agile/lean software, some education, among other things.
Subscribe to:
Posts (Atom)
Posts
