Written by What is the pattern is all about? Something that repeatedly repeats in a given environment. From this, you know the opposite of this is an anti-pattern, so something should not happen. That usually happens all the time, given the kind of agile transformation. So what are some examples of anti-patterns? Again if you look at this scenario, let’s say I have a coach, and this guy is trying to give feedback on the daily stand-up. Then you know what happens that would be great, and then if you notice, this guy is telling you that I see some problems in your daily scrum. Then why are you not asking the three questions and everything, and then you know the client says that he feels disconnected? If you look at it, the coach tells you that you have to follow scrum by the book and have these three questions. So if I have to ask quickly, what this stand called is? Is this advising or a coaching stance? For me, it’s more of this guy trying to advise the client based on what he learned in a typical scrum class, and you know if you are the client here, how do you feel in this situation if this scenario is before you? More importantly, I see this situation repeating pretty often. Most of the time, we end up telling people, we end up advising people, and we end up consulting rather than taking a coaching stance, and that’s what I see in this scenario.
Burndown on the last day of the sprint
Now there are many behavioral patterns that I see here. For example, developers often want to work independently, and everyone wants to work on one user story. Then they sit on the user story until the last day of the sprint. You know that your burn down finally down, like spikes down on the last day. Now, what do you think about this pattern? This anti-pattern and for how many of you this anti-pattern is getting repeated? That’s what I’m more interested in knowing. How many of you have seen the burndown like this in your Jira or any tool you use? To me, using tools for burndown is one of the most and biggest reasons.
Why do I say this? When you use a tool or anything like that, most of the work usually happens in the last one or two days. Now, you know what the team is doing? So you should be fortunate to get one or two steps, and that also if you’re lucky. Only you will get it once in a while, So this is one anti-pattern where I see most of the burndown or spike down on the last day. If you are the scrum master, what is your approach here, and how do you deal with such a situation? How many of you have seen it, burn down or spiking down in the last one or two days, and your approach in such cases? The spiking down on the last day of the sprint is where I see a massive challenge in helping teams understand what they are doing in the name of agile. The shorter stories and frequent updates help, but even the update is also happening. There are so many reasons why a burndown will not spike down until a story is fully getting done, and this is something that I see pretty often. So one reason which I see is how do you control your work in progress? That’s one of the biggest challenges that I see with their teams.
Maximizing Utilization and reporting planned vs. actual hours
The next anti-pattern is also one of my favorite ones, so how about maximizing Utilization and reporting planned versus actual hours. So at the end of the sprint, the developers are often questioned on their hour variances. You planned a task for these many hours, and finally, it is exceeded by like 100-200 or whatever. It is so, and then project managers are often worried about keeping everyone busy until the end of the sprint, more output-focused and not outcome-focused, so what is your take on the situation? How do you approach this situation as a coach? It is also one of my most significant, exciting observations. Given the number of teams that I have seen in my career, this is a big what I call an anti-pattern where you try to do the same things in the same way and expect different results. You will never get a different result. So that’s something I learned over a period where people do the same things in agile and then want different results, which is also very time-consuming. At the same time, you don’t even understand where the real problems. So one thing which I learned was if someone is doing this, maximizing Utilization and reporting variances, they are creating a lot of waste, and you know what some of the ways are is in our ways of working, so that’s what I usually see as well.
Agile fixed-price contracts
It is an interesting one. So actually fixed-price contracts and one thing I repeatedly learned senior leaders say that agile is only execution and you write a traditional contract and execute it naturally again. It is one of the frequent questions that people ask me. So how do I do a fixed date, fixed scope, fixed cost, and at the same time welcome changes and execute them in Agile? It is like a question that comes up in every session that I do. So again, what is your approach to this situation? These situations are extraordinary, but at the same time, if you know what agile principle this situation is breaking? So there is a situation right, there is an agile principle, and this situation violates one agile principle. So if you look at it, the first principle, our highest priority is to satisfy the customer through early and continuous delivery of valuable software, which is breaking. The other thing is to deliver working software frequently from a couple of weeks to a couple of months, even getting broken here.
Scrum Masters have no idea of the scrum.
It is again one of my favorite anti-patterns, scrum masters have no idea of the scrum, and I see this again, and again many people ask me who is the best person for a scrum master. Well, is it a project manager or a business analyst, or anyone else? So many people ask me we already have many project managers, we already have business analysts; what should I call a scrum master? I usually say that scrum masters are someone who is real experts in the scrum. But nowadays, if we look at many job postings in the market, we need seven-plus years of java scrum master. What? Nowadays, scrum masters know everything except scrum. So one of the major reasons why scrum implementations don’t kick off in organizations is because scrum masters are one of the weakest links in the node. Scrum masters do not know what scrum is, cannot clearly articulate the benefits of scrum, and I see this repeatedly. We always have many challenges understanding the scrum master role because many people do not go to the same school of thought. All they have a varied understanding of what is a scrum master? As a result of this, many people think that scrum master is a part-timer, scrum masters are there to facilitate many meetings, or many people say that what work is scrum master has for eight hours a day. The job of a scrum master is to schedule outlook meetings and book meeting rooms. It is what many people tell me the job of a scrum master is all about. But honestly, they have no clue what Scrum master is all about? So some of the anti-patterns of scrum master that I have observed are the most. I mean, he’s the most inexperienced developer in the team who is trying to play the role of a scrum master without knowing what it is. We saw it again and again; the scrum master is more of a rotating role where people take turns to play it. On Monday, one scrum master, Tuesday another scrum master, Wednesday, another scrum master. I have also repeatedly seen that scrum masters are not empowered; scrum master, you shut up, I do it my way. I’ve seen managers telling scrum masters like this. Then scrum masters report to managers and take all the delivery responsibilities—the deadlines and all, now with the scrum master and then designating leftover people. You know so many managers who don’t have work, or also I have seen many times who don’t have any work okay call him a scrum master from tomorrow. You have seen that tester, this guy is not at all occupied, let him play the scrum master role from tomorrow, and this is what I see day in and day out because of which the scrum implementation doesn’t take off well and then scrum masters don’t know how to train people on scrum. Scrum masters couldn’t identify the impediments, or they become an impediment with their personality. The majority of the people don’t have the nature of becoming the proper scam masters. Nowadays, BA is used left and right sometimes become the scrum master, sometimes become the product owner, what not I have seen everything in the name of agile. So this is one exciting thought that I’ve come up with where if you cannot get the right person, in the proper role, as a scrum master, probably your future will not be very bright; that’s what I learned.
Senior leadership undoing agility(maybe unintentionally)
The next anti-pattern is senior leadership undoing agility, not intentionally. Senior leadership is not aware of it, but some of the bullet points that I have come up with leaders asking for traditional reports and metrics. Leaders are mostly output-focused. Leaders encourage rewards like the star of the month or a hero of the month, or whoever you wanted to call them, and leaders of the opinion that agile is only for teams and not for me so the whole organization, the teams underneath should be, but I behave the same way. Our leaders stopped learning long back. They want to get it right the first time, instead of a continuous learning environment, with no common purpose or alignment between the teams, and then create systemic dysfunctions that unsettle the goal of agility and then governance models that undo everything. There’s a lot of governance models. When you look at it, most of these governance models are not complementary to agility. They act in the opposite direction, and I don’t know what more you have on the list. But it is what I have seen. Primarily on my list where I saw in organizations most of the time, leaders are playing their part in undoing agility, and that’s what I said. Many of these leaders are not aware of it, and they don’t attend training today. Most leaders, by default, have an apprehension that they know everything, and this is what I have seen most of the time.
Product owner for teams
Next, anti-Pattern is the product owner for the team. One is to one mapping between the team and the product owner. One team-one product owner and then renaming business analyst overnight into product owner and product owners are not empowered to make decisions. They are meant for writing user stories. So many people ask me who will write user stories? Who will type user stories? The best typist in the world will type it up. But they’ll be so offended if I say the development teams usually write the majority of the user stories. When the team writes user stories, they have more understanding of user stories. Still, many people say how does the team know it, so now the conversation goes in a different direction, but the idea was straightforward if the team starts writing user stories with the help of the product owner. They develop more understanding of the user story, but at the same time, if the team doesn’t write user stories well, it’s like, tell me what you want me to do? So that’s it and then creating many intermediaries as proxy product owner, technical product owner, offshore product owner, you name it people do all the sins in the name of agility. That is how things shape up, and I have seen these things happening often. At least, based on what I have seen, most organizations are primarily project-based organizations, and this change is such a significant change for many organizations. They struggle with it, and that’s what I learned with a lot of examples.
Blind Scaling
Blind scaling is another thing, so a team that struggles to integrate their code and are now scaled applied. You impose any framework, any scaling frameworks on them, and then you know what happens now. It will be scaling your problems. You are not scaling scrum or actual or any framework, and that’s what I have seen, and it’s such a difficult situation for teams. Suppose you apply blind scaling on them, especially the teams with massive technical debt. They’re already slowing down, and this imposing scaling framework will create a nightmare for them, and that’s what I learned over a while. Most of the time, scaling needs to be; I would want to call it a yardstick that needs to be carefully applied and only when needed. Sometimes you have to descale to simplify your problems, and that’s what I believe that. Most organizations take pride in complexity so, and that’s why sometimes, to simplify your problems, you have to simplify your organization, and that’s what I learned over a while. You cannot operate with a lot of chaos in and around. For example, one of the banks that I was coaching they have a huge technical debt. They have around 242 defects, and then they call all these defects minor defects. Their unit test coverage is at like 60. They don’t write a single automation test, and because of which you know what happens, now they wanted to, I mean a scaling framework has been imposed. Now you know the situation is terrible for these teams where they cannot carry their load. Now they have to scale with eight other teams. They have to integrate their piece with eight different groups, and to me, that’s one of the biggest challenges this team is trying to face, and I see this often and often. So it would be best if you were careful with the scaling; otherwise, instead of getting the benefits of scaling, you end up creating more problems for your teams, and the problems usually become more extensive, and that’s what I learned about scaling.
Common Smells
Now let see some of the familiar smells. You know, sometimes we feel lazy not doing retrospectives. Sometimes the majority of the teams don’t even show for retrospectives. Sometimes people don’t come up for daily scrums because they don’t see value in that. I would look that the scrum master to help the teams and understand the value of each of these meetings. There’s a purpose for each of these, and there will be a serious challenge because of which. They end up attending these events half-hearted or don’t even show up or often feel that these long meetings are boring, monotonous, and keep doing the same thing and then, for example, one of the reasons I was talking to a developer. This guy is a senior developer with ten years of experience. He told me that, you know, I used to attend the retrospectives for the last two years, we write many action items out of this retrospective, but no one even here cares to act on these action items. No one even bothers, so now what do you understand out of it? This guy does not see any value out of such kind of retrospective. He was doing the same thing for review also. So yes, one or two people throughout their view attend the meeting while most of the other team members end up like I’m going to sleep at some point of time I’m going to sleep. So if people are not involved, if people’s opinions have not listened to, they don’t love your meetings if people are not engaged. They don’t want to come to your sessions. If you look at the majority of the retrospective meetings, also there are one or two dominant speakers who do a lot of talks, and everyone is looking at him. Why am I even here? And this is the way how retrospectives usually happen. Sometimes you skip retrospectives, sometimes you skip planning meetings, and sometimes I have seen some scrum masters extend the sprints, and all I’ve seen this happening again and again where the sprint gets extended and they say that my manager asked me to extend it. Because of it, sometimes some parallel sprints are going on for the same team. So I mean, if I write the list, the whole slide is not sufficient, and sometimes in the parallel sprints, one team working on two parallel spreads. You imagine what not happens in the name of the scrum.
Technique to coach – Team level anti-pattern
My techniques are not very comprehensive, but I’m going to give you a high-level idea of what worked for me, what did not work for me, so that’s the way how I see it so. Now I think everyone here knows doing a doctor job so like a symptom let’s say you have a cough and go to a doctor. The doctor writes a diagnostics test and then identifies the root cause of the cough, and then he’ll give you medicine. So without doing a diagnostics test or any tests, if the doctor started giving medicines, he was doing trial and error on you. I suspect it could be a viral cough, or imagine it could be a bacteria cough or something like that. So they make a lot of trial and error, and we don’t even know which will work, which will not work, so that’s what I see over time. So symptom root cause solution is one technique that worked for me in the past.
With this, you are trying to expose the systematic issues that lie, which are the frequent underlying issues you are trying to tell and see how it works, such as one of the things that happened to me. My senior leadership says that everyone in the team is a great developer and has sufficient competency skills. So to take up any challenge that was the exemption and then when we start working around with the few teams what we found was like 60 of the developers, let’s say with four teams if you start working with four teams and then let’s say four teams have like 10-12 developers in them. Sixty percent of their developers based on their day-to-day job. They force for doing a simple, for example, a bubble starting the algorithm. They do a google search to find out how to write an algorithm, so what does that tell you? So people feel not at all safe to say that they need some support. They need some training or whatever mentoring or at least need to pair up with a senior developer, so they don’t do it.
The exemption on the top was different, and then the underlying reality was different. So as a coach, I try to expose some of these. It is the positive interest, not in the negative in the positive intent where these guys have to get some support. They should feel safe to ask. I need some help. If you’re not helping me, it will probably impact you in a longer time, so that’s why I usually believe in exposing whatever the underlying issues are rather than trying to hide everything under the carpet. That is what worked for me in the past. I know it was a little painful at the beginning. Still, as we start making things transparent, you know the benefits of transparency pay off in a longer round. Because everyone here knows what are the problems? How can we help each other faster? That’s the intent rather than what others think about me if I say that. I don’t know how to write this piece of code or something like that, so I see this repeatedly. Most of the time, you also see people say yes before their manager, and then they come back and say that you know what, this guy is terrible. They take us behind the back, and that’s also something an anti-pattern where people don’t feel safe to ask for help, which is one of the behaviors that I have seen.
The next technique which I wanted to put before you is doing an organizational retrospective. It is something precious and for which I like Jutta Eckstein’s techniques to coach that worked for me in the past. It is like, “What now, what so, what so kind of, a feedback loop. So what is the current situation? Now, what should we do? And, how can we improve? So that’s to me, is valuable. These cycles give us excellent insights into most of the problems we have and wanted and what experiments we wanted to perform. That is something I allow over a period where I’m doing many retrospectives, doing retrospectives with the best intentions to improve. That’s something which you can try and see how this will work for you and let me know how this is working? But this is one of the most powerful techniques now which take us forward. So that’s a small set of actions that we do and see based on this. What did we learn and this is also I call it one of the continuous improvement frameworks, which I enjoyed doing. The other thing is you can try some of the coaching techniques. For example, many of you know the ICF coaching competency model or ICF core competencies. It is something which we can enjoy, and it is a great study by itself. Several months people study all these competencies and then pay for it, so someone who wants to fix some of these anti-patterns tries some of these coaching techniques. They then grow model, a famous and Marshall goldsmith executive watching if someone is not familiar with it. There is something like Marshall gold smith’s stakeholder-centered coaching. It is a lot to learn from it, so how do you help your leaders continuously improve if your leader genuinely wants to improve. Let’s a leader say that I have a serious problem delegating tasks, for example, delegating tasks, so that is one improvement. A leader wants to improve upon, so how do you deal with it? So this is one area where you can try it. It is an excellent course by itself, but I learned a lot from Marshall gold’s mistake holder center coaching many YouTube videos to explore it. Now try systemic systems thinking and explain the cause and effort. Cause and effect techniques this is something which I took an example of higher velocity, and then you see what happens with a higher rate, so this is one technique where you expose a system again if you do this you will get this. So, cause and effect system thinking will give you an excellent idea of, if you do this, you will get this, or if you do this, you get it. How are the connections? How everything in the system is interconnected to each other is what system thinking will give you, and I love this technique from the time I learned this. I wanted to know more and more. I wanted to practice more and more, so this is an excellent technique to expose a system, and this is something which I would recommend everyone to try. Some of the other facilitation techniques I don’t know how many of you have been to an open space world café. Open space agility is also there. There is an open space agility framework to maximize the engagement where we can listen to everyone and then see how we can maximize the engagement. That fits into everyone’s plan, so I always believe in making it their agenda rather than your agenda, so I usually enjoy making your team’s agenda rather than your agenda. With that, you increase a lot of engagement, and now I wanted to tell you a fun therapy technique to change behaviors. Learn about this on YouTube. You would see that by using fun therapy, you have improved the behavior of others without any resistance.