The bad habits of “agile”
I’ve worked at different companies in disruptive projects that demand a change in the vast majority of the architecture, infrastructure, team organization and also a big budget.
The process is very similar and basically starts like this:
- Project idea to replace the systems the company uses because the IT team detects that the whole infrastructure is a mess.
- Project planning and conception involving these main additional resources: more developers, testers, PMOs, new and modern technologies, a new methodology, and money investment including that hard part of convincing board members.
So after they’ve told the board members that after this project EVERYTHING will be flexible, nice and it’ll help reduce costs, it sounds spectacular. It promises to eliminate the legacy systems that were made long years ago which are difficult to maintain or maybe they have a bought system that is getting high up in costs every year and it’ll also get replaced, IT long delivery and bug fixing times will cut down.
Okay, the project then gets approved because IT knew how to sell it and everybody is happily motivated to take on this journey.
I could talk about many things that go wrong on these types of projects including from their very conception, but I’d like to focus on how they approach workflow. They decide to hire people that would create their big and perfect system to which they’ll have absolute control. The newcomming developers get instructed to deliver in an “agile” approach.
I’ve seen companies try to implement Scrum but I tend to see the same problem, which is trying to be agile and adopt a new way of developing software but at the same time sticking to old bad habits.
Let’s put an example with “Daily Scrum”. It’s meant to be for every person directly involved in the product development to answer only three things: “What was done yesterday?”, “What will be done today?”, and if there is any impediments or stoppers in order to continue on with the activities.
Daily Scrum is meant to be quick and limited to that scope. But, I’ve heard managers say:
- “15 minutes is not enough to get a view of what everybody is doing”.
- “Let me tell you what meetings I had yesterday and what I’ll do tomorrow..”
- “I created a database design, which includes these tables, these relationships, these columns…” and keeps explaining everything in detail including how to get information out of it.
First of all, the managers shouldn’t participate in these activities other than to listen to what the team has to say. It’s supposed to be only the people that are directly involved the ones that should talk, everybody else is a listener. Having people standing and venting for an hour is not agile. They shouldn’t call it Scrum just because you have people standing. It’s hard to stay concentrated if you’re standing up listening to two people discuss a specific topic just to say at the end, “Let’s discuss this in a meeting later”.
This is all due because nobody seems to stick to the 3 questions they should answer (What I did yesterday? What I will do today? If I have any impediments). If you have any particular topic to discuss with another member(s) of the team, do it in another session.
Having an agile team means a change in the way they behave and it is really influenced by people’s culture. If the cultural habits invade your professional activities of having traditional long follow up meetings only once a week, just to figure out that everybody is behind and that the impediments weren’t even noticed until now.
What I want to transmit is that many of us, including small teams, misinterpret the “rules” that scrum and other frameworks provide in order to achieve agile. At the end of a sprint, they might finish the spec but don’t deploy it to production, I’d ask, why not? The sprint’s product scope should be a working, usable deliverable, why wait until another sprints finishes and state that your doing Scrum?
Perhaps if teams would concentrate on smaller goals, if they’d stick to the procedures they’ve agreed to follow and not customize them in order to complement the framework, only then they’ll achieve better results. That way they can convince the board members that the investment made was really an investment and not money thrown away. So you won’t have them threatening you that the project will be thrown back. Plus, the team would stay motivated because they’re being productive and their job is more stable. Let’s avoid insanity.
Insanity: doing the same thing over and over again and expecting different results.
Read more at: https://www.brainyquote.com/quotes/unknown_133991
