“I have no time to do Agile Scrum” a manager yelled at the conclusion of a long crisismeeting.
This example is about a manager (could be any kind of manager like a CTO for instance) who started a the company way back and was also still a programmer and responsible for plus minus 75% of all the software still written in old unsupported code (for instance VB6). This is a common scenario at software companies that grew from 2/3 guys. All these years (10+ years) this manager a lot of times does not find the time (apparently) to transfer large chunks of functionality to his other (.NET) developers.
And now some parts of the system had reached critical mass and customers were unhappy with the fact the problems did not get fixed fast enough! You see this happen a lot of times.
Doing it the wrong way
This manager did not have time to listen better to suggestions because he was running from fire to fire to put them out. He worked 80 hours per week trying to find the root of a certain problem and then write code hours on end to fix it. And when he was done he deployed it to the customer. You read that correctly, the manager releases software. Often nobody in the company knew when he would release something, or heard it just a few days in advance. And the people who usually tests stuff would often be caught off-guard by a sudden release and too swamped with other work to catch on. “No time to properly test it. Just see if it works!” Could be a phrase often heard from this manager.
The result was that the code came back quicker than a boomerang. Why? Apparently one of the things that happened is that the alleged root of the problem was in fact nót the root and he needed to dig further. Another problem was that workarounds were not adequate, as you could see them peel off the wounds like a wet bandage. Years of Technical Debt started piling up now, because testing was never a main concern. And without time to properly document the fixes there was nobody else expert enough on a certain problem, but that same manager. So he continued to be solitaire in his efforts to restore the system to its former glory.
Doing it the right way
The suggestion (at the aformentioned crisismeeting) was that he should start doing Scrum asap. That he would simply form a minimal team of 3 people. He himself, a second developer (who is more than willing to help out) and a documentalist/tester. Then have a Product Owner feed this new-born team with a properly formulated and prioritized backlog. And last but not least a Scrum Master to remove impediments and get this team pumping.
Of course this is not an ideal team, because you have a developer (the manager) in there who outranks the other team members. But if he would be able to switch off his manager thinking cap during development work within the team he would have himself and an additional developer analysing the problems and coding solutions simultaneously as the 3rd team member continuously tests and documents the coded solutions.
The following results are expected:
- Peer code reviews by the other developer on the code of the overworked manager which will reduce mistakes (overwork inevitably leads to mistakes);
- Two developers working on problems is like going from a single core processor to a dual core processor (in other words it goes faster), which will prevent overwork;
- Code which is tested all the time by the 3rd team member leads to less mistakes, which will mean the operational code doesn’t get thrown back to the drawing board all the time;
- Documented solutions/workarounds by the 3rd member will make sure support can provide customers with valuable information (they are often now left in the dark)
- A prioritized backlog will make sure that what gets done first is what is most important to the customers (making them smile again), of course the PO needs to work together with the Support department on this though.
This example is overly dramatized ofcourse for emphasis. But it’s not an uncommon case in which a company of just some developers started out in their basement or something and then grew to 20, 50 or a 100 people. If the organisation does not accomodate to support these changes, all kinds of bad things happen.
In my opinion saying that you “do not have time to do Scrum” is one of the funniest things I have heard in a while. Is it easy? No. Is it hard to do? Absolutely, because it takes commitment. Is this the best possible situation in which an organization can adopt Scrum? Absolutely not! It is one of the worst situations possible in fact.
But the suggestions were done in the utmost concern that the jumping from fire to fire would just continue endlessly. The cycle could’ve been broken by wrapping a team of other experts around the manager, making him supported by other smart people and solving the problems quickly and effectively together. But alas, there was no time, because of the jumping around and all.
I am interested in what other people think or their experiences. Don’t be shy and leave a comment on this.