I have no time to do Agile Scrum!


“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.


About Danny

Bachelor in Commercial ICT MCTS Winforms .NET 2.0 MCTS ASP.NET 3.5 PSM I
This entry was posted in Agile Scrum and tagged , . Bookmark the permalink.

10 Responses to I have no time to do Agile Scrum!

  1. tisquiiirrel says:

    That is a great post! “I have no time to do Agile Scrum” – I have heard it so many times! Also my colleagues PMs told me that Scrum meetings take too much time, developers need to work, not talk. The fact that we loose so much time because of miss communication was not an issue to them, Scrum meetings which lasted 10-15% of the sprint time – were a huge one.
    That’s why we need to start from the philosophy and the values of agile first, as implementing just a “rituals” have this “We have no time for that!” response. Because they don’t understand why they need it.

  2. Gijs Linssen says:

    In Infrastruture I have found the same issue. one of the technicians who also does standby and is also the architect. So we have a company hero who has to report to him(her)self and adjusts the architecture to the solution. His/Her documents are updated in their heads, but are too busy firefighting to share knowledge. When someone new joins and asks stupid questions for example, who is your backup or who reviews the architecture, why is tyhe documentation not updated in the last 5 years, that person has a short ended career.
    This company hero will reject Agile Scrum, with explanations which show a lack of knowledge and fear; “it’s for software development, not for “. Or my favorite “It can’t be done because everything is connected and we have to deliver the whole package two years from now”, as if developments don’t occuer the next two years.

  3. Did the manager finally have time to do Scrum and embrace Scrum?

    • Danny says:

      Nope, as the article insinuates, he/she kept chasing fire after fire to put out. 😉 Thank you for reading.

      • Does that mean the team just do Agile/Scrum without management blessings/engagement? How does it work so far?

      • Danny says:

        Well, to go into details, the company was fortunate enough that it could split off a team of developers to build brand new software. This team does Agile Scrum with the manager as an internal stakeholder and a PO in between as a buffer. The manager was left to do as he has always done basically and maintain legacy code. It doesn’t work optimal, it is better to have the entire organisation adopt Agile Scrum. But sometimes you make do with what you have.

      • Thanks for sharing Danny. Really appreciate it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s