Agile Is Not Heavy

?I have started to hear the comment both inside and outside my company about how “Agile is heavy”, how all the meetings and ceremonies are eating away at the productivity of our teams. Here is the problem with that statement; Agile is not a set of rules for all to follow like the Hammurabi Code. It is just a framework, a guiding principle, and how we follow it, and what we do with that it is up to us. How we mess it all up is up to us as well. The problem isn’t that Agile is heavy, the problem is that Agile has slammed up against corporate needs and wants and its need for plans, metrics, and uniformity.

Ceremonies take to much time away from productivity: Then you have turned them into waterfall meetings and have gone away from Agile ceremonies and Agile principles. Standard sprint length for most companies these days is 2 weeks, so assuming that, how much time on ceremonies? 15 minutes a day for standup, 1 hour a week on grooming, 1 or maybe 2 hours if you have a larger team for Sprint Planning, half hour or maybe an hour for retro. Then an hour for a team demo, maybe. That works out to about 5 hours a week. Now think about that; now ask yourself the question of how much time does your teams spend in other random meetings outside of that list? Are the ceremonies really the problem? “But we spend a lot more time than that in our ceremonies”. Then you are not following the framework and you a probably just doing waterfall with standups.

• Standup: 15 minutes, AT MOST. “Well, we have a big team, and we have a lot to talk about”. No, you don’t.?What did you do yesterday to help meet the Sprint goal? What are you going to do today to help the team meet the Sprint goal? Any blockers? ?Example: Larry “I finished that story Bob was waiting on and I am going to start Defect 123, but Jenkins appears down right now”; Scrum master “Is someone working on the Jenkins issue?”; “No”; “Okay lets you and I stick around after standup and figure out who we need to reach out to for Jenkins problem”. Done, next person.?Susan “I am not sure how best to solve the problem in Story 123”; “Okay after standup anyone who has any ideas or opinions to help Susan stick around and try to help”; next. Then standup is over anyone who needs to stick around to talk about the Jenkins or has ideas to help Susan stays, the rest go on with their days. But you only stay because there is a need and benefit for you to stay, you don’t stay, just because, or because “we are a team, so we do everything together”. or “I might miss something important”. If something important comes out of the post standup conversations, then that needs to be disseminated as such to the whole team.
• Grooming and Planning: 1 hour, each; REALLY 1 hour; and no homework, prework, post work except for the Product Owner. Grooming, Product Owner “Here is Story 123, this is the user’s problem, this is the acceptance criteria that says the problem is solved”. “Does everyone understand the problem and the acceptance criteria?” If not, they ask questions, and the Product Owner clarifies. Then we size the user’s problem compared to other problems we have already solved. THAT’S IT! We are not tasking, we are not architecting a solution, we are not defining test cases. If the conversation around understanding the problem and acceptance criteria goes more than 10 minutes, then it gets shutdown, and the Product Owner needs to revisit the Story because it is not ready yet for the whole team. How about Sprint Planning? How much work are we going to take in? What are our top priority items that are ready to be worked? What of those are we pulling into the Sprint? Then we put some basic tasking into it; We have a UX Task, a Server-Side Task, a DB change, need to review with UX, etc. Same with test cases, just high-level items. There is no need for a deep dive here. Let the engineers who are going to work it decide and converse about the details. Think about this all in the big picture; for both grooming and planning let’s say you have a team of 9 members, when you work a Story let’s say you have 2 engineers work Tasks on that Story and then a QA person tests it (yes, I know there are no roles in Agile but in most cases that is just not fact). That is only 3 of 9 people on a team. If a Story takes more people maybe the Story is too big. ?So, if you spend an hour talking about that one Story between grooming and planning you are wasting an hour of 6 team member’s time. Don’t get me wrong, the deeper conversation needs to happen, it should happen, but those 3 people can have that deeper conversation when they are ready to do the work, as they do the work and others who have thoughts or ideas can be included but when we are almost ready to actually do the work, not a week, two weeks, three weeks, before the work will be done so the conversation is all but forgotten and needs to be rehashed later. It does not need to be a formal meeting, or it can be, but then just include everyone as optional, the other 6 team members can decide if they can provide value or garner value from it and choose to attend or not. ?
• Retro: Thee most important ceremony of all but usually the first one eliminated for time because “Agile is heavy and we are not getting much out of it”. This is where the team needs to talk openly and honestly about what they need to change and what they need to do better. How to deliver more value faster. But it needs to be focused on actionable items. Venting of frustrations is very important for a team and imparts team building, but not Sprint after Sprint. After retro look at the list of action items from it, don’t have one? You need to change your retro. Have a list of action items? Look at the list, was most of your retro time spent talking about those items? Or was most of the time spent talking about other stuff, if this is the case then you need to change up your retro. If you are not discussing things you can change then you are not getting any value from it.
• Demo: This is a simple one. Do the teams get value from the demo? Should it be on a team level? Should it just be a one on one with product? Is it a big room demo? The answer is what gives the most value to the teams and to the users. The purpose of a demo is to show Product and Stakeholders what the team has done and to generate ideas for future value delivery. If it is a big room demo where everyone is going through the steps and little to no discussion, no new ideas coming out of it, then what is the value? But if the Product person does not want to see the done Story then was there even value in doing the Story??

Team Uniformity: “In order to manage our teams properly all our teams need to be working the same way.” Then why are we bothering with retros? Basic principle of Agile; Shu, Ha, Ri. ?To start the teams should be aligned with the framework and with the corporate “way to do things”. At this point it is “follow the rules” but as the teams mature, as they grow, as they really learn the why you do, you care less about the how and just let the teams go and work the way that works best for them. The point of the retrospective is to allow the teams to talk about what is holding them back, what is taking away from their ability to deliver value faster, how can they deliver more value faster and change how they work to do just that, deliver more value faster, the core purpose of Agile. But now in many companies the retrospective become pointless because it becomes, “we can’t change that”, “we are not allowed to change that”, “all the teams need to do that the same way”. If you have no freedom for the teams to do things how it works best for that individual team then you have no agility and not faster value delivery will come from it. One side item to this is use lessons learned, “hey team A tried doing this we so we should have all teams give it a try see if that helps them” this is a good thing, as opposed to “team A tried doing this and it worked for them, so we want everyone to do it that way”. ?Not good, things forced down teams’ throats never go well and rarely provide value to users. What works well for one team may not work well for another team, and you may be forcing them to deliver less user value.

Metrics, Metrics, Metrics: This is usually very closely related to the previous topic. I am a data nerd, I love data, I love looking at charts and graphs, my Instagram feed is not filled with pictures it is filled with maps and charts, I want metrics. But metrics need to benefit the teams. Metrics need to benefit the user. They need to show the teams how THAT INDIVIDUAL TEAM can change to be better. Making teams change how they work in order make nice pretty rolled up metrics that can measure all teams, on all trains, on all products, across a whole corporation is just going to slow the teams down and are probably not really showing what the teams are doing anyway. Time that could be spent on value delivery to our users is being wasted to make sure the metrics that deliver no value to our users are correct.

DevOps is not a part of Agile: DevOps and maturing DevOps is very important for any development team and any development platform. That said we should not be adding complexity and documentation to Agile for DevOps. A user story is based around one thing and one thing alone: the user has a problem, this is the problem, fix the problem.?Even technical stories need to be focused on a user and the problem that user is having. Writing, formatting, or breaking down stories to make our DevOps better is taking away from our users’ needs and is wasting time and effort for DevOps related paperwork and lessening our value delivery. A Story is focused on the user and that cannot be altered or tweaked.

Sizing and ROM’s: I am a huge advocate for the Weighted Shortest Job First model of Feature prioritization, and to do that you need two items, estimated Feature value and estimated Feature size. But that size component is intended to be a comparable between items, this is bigger than that, this other thing is really small compared to the first two. Tee shirt sizes work great, if this is a small then that must be a large, and this must be an extra small. The problem lies is have this all tie back to actual timeframes, at that point things quickly fall apart and we have massive waste. The reason for tee shirt sizes started to be used, the reason the whole Fibonacci scale was started, is because the human species stinks at estimating time. How does this hurt teams value delivery and productivity? You ask a team to give it a rough tee shirt size compared to other Features it will take x amount of time. Quick conversation to judge them against the others and then Product has data to start to judge priority order. These deliver less value, but they are sort of quick hits, while that is a lot of work but also has lots of value; how do we want to do this? Big bang first or maybe the real quick hitter first then we do the big bang. But when we start to assign time to the sizing that x amount of time starts to grow exponentially because people know if they are asked about time then they on some level they will be held accountable for the time they have given. So now they start researching, they start breaking things down, they start architecting how they might solve things, how much do we want to pad it? Suddenly a quick conversation is hours and hours of time all for a Feature they may or may not be done. This can add up to massive, wasted effort which becomes a massive loss of value delivery.

The value delivery question needs to be had at all levels of an organization and all levels of development, every time we want to make a rule, a metric, a standard, a team guideline, a grooming checklist, a process document, we need to ask the question; “How does this help us deliver value to our users?” if it doesn’t then understand it is then costing value delivery. It may still be wanted or needed but then you cannot blame it on Agile. Additionally, keep in mind that if you need to become a contortionist, or play the game “6 degrees to find value”, to answer that question of “How does this help us deliver value to our users?” then you are kidding yourself and you are just making stuff up. Agile is not heavy, it is the definition of lean, we make it heavy, and we need to stop.?