I just went to the weekly meeting where we discuss the Agile implementation and how things are going with it (the one in which I brought up the need for QA to get DB access again).
I am unhappy that the dogmatic tone that the trainers took about how to do Scrum has filtered down to some fairly senior and influential people. Basically, to do anything in a manner that is contrary to what was recommended by these trainers is being interpreted as "Scrum, but."
The effect of this is that instead of liberating people to find their own ways within their product teams, we're shackling them with executive fiats simply on the basis of "this isn't what the trainers said." And what is frustrating about that is that the trainers were just giving one flavor of Agile, in which every work item and every sprint MUST result in visible, executable code ... and be one month long ... among other pronouncements (my favorite being the one that everyone on the scrum team does ALL work, even though our company is not constituted of 100% developers but has project managers, quality assurance analysts, graphic designers and business analysts among other sorts of specialists - as well as Dot Net and HTML developers).
Now the team we have that's been doing weekly deployments for some ten months or so is getting pushback that they MUST be on a monthly release cycle, less we become "Scrum, BUT." And the team that does invisible infrastructure work is being told to rejigger all of their work so that their aim is to produce visible "slices" of product for every release. In essence, we're trying to fix things that aren't broken, and make them blindly adhere to process when there is no reason to do so.
This, to me, seems as profoundly anti-Agile as we could be. It's not about valuing people over process; it's about setting up process as a deity with commandments we must follow. And it's creating even more control from above rather than empowerment for those who are doing the work. It grates on every bone in my body.
In other work areas, the PMs are fighting like mad dogs to not let any of the QA people roll over to 100% Agile until the leftover projects get out the door. I want people to be doing their Agile work without interruption and finding their own rhythm, but I'm really unhappy about the state some of this code is in, and to me, while it's bad not to get Agile going on the schedule it's supposed to be, it seems worse to get things started by releasing code to live that's going to cause us to lose customers and have a never ending series of emergencies for two weeks. So while I want to run around and say, "No! How dare you take away the QA person's time from the Agile team! How are we going to make things work if we keep having our time nickled and dimed away like this?" On the other hand, the person that lives in me that hates seeing the quality of our live code get kicked can't quite overcome that other voice in me, because there's nothing I hate more than frantic phone calls from business owners telling us about what large account we're about to or have just lost because of a bunk release. So I'm keeping mum for now.
Subscribe to:
Post Comments (Atom)
There's absolutely no reason a release cycle has to be monthly. Weekly and fortnightly are common throughout the industry - I've used both in the past.
ReplyDeleteTo say "We must do Scrum EXACTLY THIS WAY" is to exactly miss the whole point of agility. You might as well just jump off the top of the waterfall.
Equally, to claim that everyone must be a generalist is foolish. Didn't Eric Doernenberg's talk contain stuff about specify / code / test cycles that gave each group their own time?