When your CIO thinks everything is fine, but you know it isn’t.
(How many times have we all seen this or experienced this situation?)
Agile allows everyone to win.
John the CIO thought everything was running smoothly, not perfectly but customers had stopped complaining and products were shipping on time for once. Re-org after re-org had finally brought some results. The developers/testers/project managers and business analysts were happy, or so he was told by the V.P. of Development to whom all departments reported. Everyone was solving problems and working together in the open and bright space. Disciplined process and structure were in place and demonstrated during executive and shareholder meetings using sharp power point presentations. Documentation, process and procedures were stored in shared repositories for all to see. More eloquent documentation you could not find.
Everyone agreed improvements needed to continue but the executive management team was elated.
While it was true, products were shipping, what he didn’t know is that people were working in excess of 50 hours per week and more. They were now working nights, weekends and sometimes over night. He heard about the video games, pizza and food being brought in so he assumed, everyone was being taken care of. What he didn’t know…Changes were made hours sometimes minutes before going to production completely bypassing the QA team and being looked over by the B/A’s or sometimes just the developer. Negotiations with clients were made on features so what he thought was being delivered months earlier according to a ppt presentation really wasn’t but the VP had already smoothed that out with the client. To those above, it “appeared” that the team shipped all features, defect free, on time but what the teams knew, particularly those closest to the code and deployments, is that they shipped some of the features, not well tested, and held their breath followed by other negotiated smaller production deployments all without the CIO’s knowledge! Everyone knew what was going except for management that was carefully “managed” out of the information loop.
While people on the teams knew what was happening, bringing it up to the PM’s or VP singled them out as non-team players and before they even knew what had happened, they were removed from the teams. Eventually, everyone stopped talking and trying to make things better. It was easier and less risky to simply comply and stop pointing out the obvious flaws and potential serious harm this vicious circle was causing. The risks the company was taking without knowing it as well as the clients. Employees observing this were losing respect for management and the prospect that things would get better. There was a growing concern that it was important to keep up the illusion of success. Technical debt was building and building to an untenable point until products completely failed to be deployable without multiple code patches and increased manual testing cycles. Eventually it was not possible to hide the crumbling product infrastructure. Regardless of how hard people worked, how fast the coding went or how much the testers tested, the product could not be stabilized and it was not scalable . Nobody wanted to hear, we told you this would happen a year ago or even last month. The CIO stood up and took notice but wanted action, not excuses. Again people rushed to FIX IT instead of stopping to figure out, what caused this problem and again, went into the immediate hectic circle of HURRY, WE HAVE A PROBLEM, FIX IT, TEST IT, SHIP IT, HURRY, FASTER, FASTER, And FASTER.
Oh problems were identified; you know the story, the usual ones.
· The project managers, were not quite right for the team but instead of removing them, we’ll just add more
· Testing is too slow and it’s all manual
· We need to split development into maintenance and new development
· We need more people in general, that’s it, we’ll put a few senior people on the project and several really expensive consultants, they’ll fix it right up and kick everyone back into shape.
· Oh it’s just the testing teams fault anyway, lets fix the testing process by designing process flow diagrams and making lots of templates. They are supposed to assure quality right?
Needless to say, nothing changed. But the CIO thought it was all fixed up because the product started shipping again. Hmmm.
The team became fragmented and completely demoralized having been told everything was better. Nothing changed. The patterns of behavior that caused the problems simply repeated but the appearance was that the product was “stable”.
To the teams, nothing changed except they now had to report status to more people and defend their efforts instead of improving the process. Because the teams were split into maintenance and new features, they now had less people doing more work and the code defects increased thus increasing testing time.
People started to leave. Those who stayed dragged themselves in. The team had no spark and no reason to go above and beyond.
What agile could have done for this team?
Rule 1. Agile really does require top down support. Whether it’s the CIO or the SVP, it requires the most senior sponsor to support it completely.
Rule 2. Agile is transparent and as we all know, you have to face the ugly and deal with it, as Brian wrote, Step 1, Accept that you have a problem and be ready to deal with it, not cover it up or call it something else or “redefine success”.
Rule 3. Do not lie to upper management. You are not helping your CIO you are hurting your CIO and everyone else around you as well as destroying your credibility. Once people lose respect for you, it’s unlikely you’ll ever win it back.
Rule 4. People write software, test software, and organize plans. People are not resources, fte’s and contractors. Treat them like the people you thought you hired. They have brains, let them use them. Expect them to be brilliant and let them surprise you.
Rule 5. Stand up and say no. Not now, next iteration. Or, choose this OR that.
And many other basic concepts that Agile principals bring to the table.
People say Agile isn’t for everyone. But I wonder about that. Agile principal concepts are common sense principals that benefit everyone and every organization at every level. The fundamental guidelines bring out the very best and yes, not so great but gives everyone a chance to adjust. You find out quickly if you are doing the job you love or not. You’ll probably find that you’ll love your job more. Imagine bouncing into work pretty much every day so happy just to be there, with people you really like working with. Every day, just imagine…
And how much happier your clients would be and how much more productive the department would be.
And for executive management – imagine if you would, increasing your profits while driving down expense instead of spending more money to make money. Or instead of laying off people during a down economy keeping them.
