Thursday, June 15, 2006

Flavor Of The Month - Part 2 (Agility with Agile)

At the same company that never got off the ground with Six Sigma, though we had a pretty efficient cappacino process, at some point someone got tuned in to Agile.  This time we had a meeting between the VP of Engineering, the President of the company, the Dev Director, the Architect (who became the other Dev Director...long story there) and me (the QA Manager).  We sat and discussed it, the benefits of it, then with the Cockburn Agile book in hand went off to read about it and see what we could do about implementing the process.  The system was nice, QA and Dev working together, with PM to get the projects completed on time.  This was all done because we were consistently late with the projects, requirements changed during the development and test cycles, often times at the last minute, while also trying to do these ambitious projects in short cycles because "we were the best!".  You can probably guess what happened.

After a couple of days of discussion we broke it to the teams, they would get broken up into 3 groups, each one focused on a different product the company provided, and they would all sit in the open areas designated for the groups.  QA moved out of the QA lab (which I will admit was pretty noisy with the 20 or so computers and video hardware) and into the Agile Groups; which I will call Groups 1, 2 and 3.  Furniture was arranged, the spaces were broken up with help from everyone and the stuff was set up over the weekend so that on Monday morning everything was ready to go.  Here's how it all broke down...goes to show, even with good intentions if the entire business process doesn't change nothing will really get fixed.

Group 1:  This one I called the "Puppy Pound", mostly due to the half walls ringing the space outside my office, there were about 16 desks around the edge where everyone sat; reminded me of a puppy pen in a pet store.  This space was also on the way to the kitchen from the rest of the company, so the opening that let people walk though was closed off at one point to keep the noise down; didn't do anything about the noise in the kitchen though.  The group worked together fine, QA had two members with about 12 developers, one doc person (who was never hired) and a PM delegate (who surprisingly worked on maybe half the projects until she left).  The Team Lead was constantly called into fixing legacy issues on the core product, items that were always pushed off to be fixed in the next release because our DB was overtaxed and constantly being updated without enough testing to all the components, plus we had excessive amounts of data; we tried to manage the changes in testing but sometimes failed - though we did know all the changes happening.  Another member on the team worked with the Architect on special projects, that were supporting the core product, but he was distracted.  So the team while being together did what they could, but did not do a lot of new stuff, they ended up being a sort of triage and special projects team; my personal view.

Group 2: This was a group that was a bit smaller but had more PM and Doc people, including a UI person!  They had really high walls around them on most of the sides, they did the next generation project and were overseen by the Architect who sat in the next room.  They did ok, but they also had a lot of turnover, the project they were on was behind for months, and had extremely tight schedules, which I disagreed with but attempted to work out anyway.  This group was the unfriendliest group, they never really talked as a team (you'll soon see why), and even by sitting next to each other, the QA members sometimes had no idea what was going on.  The Architect never managed them effectively, and the dates slipped because what oversight there ended up being was minimal, turned out when one of the DB guys left he hadn't done work for quite awhile and no one seemed to have noticed.  Apparently the Architect had also told the Developers on the team to not really mix with anyone else, they didn't, but a few of them talked to the other members in the group but it was nothing constant.  I kept saying the dates were in danger, but the Architect claimed it was all under control, as he was a coffee buddy with the VP I was ignored (the two of them beat anyone into submission who disagreed with them), eventually I left because it was not worth my time to deal with someone who was not going to listen.  The product went out a little late, and much scaled back, and took months to work out the kinks.  From everyone I talked to about the project afterwards, it was a shambles.  Did I mention the schedule for this was decided upon by the company officers at a meeting in the Spring, for a Winter release, without knowing the technology or talking to anyone who might work on it?  Did I also mention that the main database and software we were using to base this work on, was from a release that the company which created it was no longer developing, or supporting, after our initial release date?  Oh yeah, those are kind of important.

Group 3: This one personifies my personal belief in geography killing team work.  This one had an area that snaked along the wall, with one of the main doors in the middle of it, the QA and Dev members gravitated to one side, PM and Doc on the other.  Never the twain really met.  They pushed hard and got a lot of things out on tight deadlines, the Dev Director was totally involved in this and often was seen coding with the rest of them.  Dev and PM rarely seemed to talk.  There was some change as things went on, and a reliance on technology from a company in another country, that constantly claimed to do things that it did not.  When they were on site they would tweak and fix things for us, but never trained us on everything they were doing, though we tried and did get some training by watching them over time; even getting friendly with one or two who helped us out by showing us some tricks.  The weakness here was a reliance on technology we had no control over, which was being pushed to the edges of what it was claimed it could do, and be on a schedule that was totally unrealistic.  Items Agile was not going to solve.

The company is in the process of being liquidated, right after I left there was a mass exodus, which was not my intent I actually did leave for personal reasons.  Still much here is my view and from discussions I had with people who were still here, if you worked at this place (and I am sure you will know it) then take this all with a grain of salt.  We were doomed from the beginning.

No comments: