4 Thoughts about Agile

I have some thoughts about Agile that may not be popular (yet), but I think they are logical. Let me drop 4 since it's the 4the article in a series of 4 articles.

1) I don't believe the entire project can be Agile.

I feel Agile is a way of working but not a method of total project development. I know that the Actual Agile isn't like this, but I've encountered it enough in the wild to say trying to get completely away from anything that looks even sort of like waterfall isn't rare. Agile shouldn't be a synonym for ad hoc. You need to know what you're doing in general just like a house. You can't build a roof two walls and then decide on the foundation. You can't put the pipes in a foundation if you don't have a plan for where the pipes will go. Where you put a light switch is less a concern than where to put a bathroom. It's not waterfall where everything is decided ahead of time but it's also not anarchy. Delivery is incremental and progressive which is the best part of Agile compared to other methods. When you work exclusively Agile you get the Winchester Mystery House . There is a lot of software that's a very close approximation to that famous house. How often do you encounter things that you can't explain in software and realize it's probably a user story that didn't really work but got to the halfway point. You can't account for every feature, which is why we have Agile but we do have a general plan and a backlog to plan for everything else. There's a lot of room to work in Agile steps based on feedback but some changes are so significant there's just no way to do it without significant rework and a matching significant cost.

2) Agile sizing should be correlated with time.

I've been told so many times things like

• Points aren't time
• T shirt sizes aren't time
• You can't get a time value from an estimate.

I disagree entirely with this premise. Unless you pay people by the point, task or story you have to figure out what the cost per point is. I've never seen a SOW that had an engagement in points. If they're paid in hours and the client is billed in hours, then it makes sense that work would be done in hours. If this is some sort of way to get more work than you pay for it's going to lead to diminishing returns. You can't sprint forever, and work life balance isn't a bad thing. You can't say a single developer should output 30 points per sprint, but a point isn't 2.67 hours. Unless you can divorce the billing from the points, I don't see why it's a big deal to just admit that a point is about 3 hours. Time must be money. Additionally, if you don't do this you can end up with these stories that aren't broken into reasonable tasks that show progression. I don't often find that people work on a very specific story for multiple days that cannot be broken down into tasks showing milestones that will allow the task to be completed. If you break it down small enough, you'll get the repeatable tasks that make velocity increase. Once you have those you can likely estimate close enough to bid.

3) Unplanned and unscheduled work isn't really unplanned.

Once is an exception, twice is a habit... If you're going to take on unplanned unscheduled work, you should just account for it in your sprint. If your team will be stuck fixing things that break why pretend it won't happen. If you have a lot of tech debt, then you're going to have a lot of problems. Add this to your firefighting work type and try to do things that reduce it. If you book a full sprint and half of its spent firefighting, you're not being honest to the sprint plan. If you aren't documenting unplanned and unscheduled work in the sprint, you're just killing your velocity and it's not going to be clear why. Look for that end of sprint burndown vertical and explain it. Ideally you take something in you should push something out of the sprint, but I find more often than not that's not what happens. Sprint planning becomes an initial suggestion, and a lot of the work comes later.

If you're struggling with unplanned work, I'd consider changing Scrum to Kanban or maybe even Scrumban until you get control of the unplanned work and sprint goals. This is the grounds for number 4.

4) The framework/tool matters a lot less than the process

I've seen people say "we're using Agile and struggling with it. To me if it's not working, change it up until it is. I'm a big fan of the idea that process makes the product. If the process is suboptimal then the product will be also. You can use the sprint process to your advantage by choosing what makes the process best for you. The goal should be progress, output and efficiency not using one method over the other. Agile Scrum is just a tool like a wrench. One agile team in an organization or even worse a vertical doesn't seem to make for the simplest work environment. If your work is highly interdependent on other teams and they are Kanban or simply firefighting, getting their time and attention might require a lot more coordination than a group of agile teams working in a similar flow. Change management and documentation also play a massive role in success.

This is a sprint map that I've used in the past. A junior team working through new things every week. We also should have had better backlog grooming, but this allowed the team to make good progress, get in documentation time, work through the cross-team issues and achieve. There are as many valid maps as creators. I just like having one that I can point to for goal setting.

This also leads me to the concerns about Tuckman's Model (Forming, Storming, Norming, Performing, Adjourning). I think that you can use this model to your advantage and mix up your individual scrum teams to get a larger team with more interchangeable people. Example you have 5 teams of 5 engineers. If you rotated people in a star pattern you could potentially have a 25-person team performing instead of 5 teams as constant risk of headed back down to forming/storming. This may not work but it depends on how your articulate your goals. In the Army a platoon can be somewhere around 50 people and they have success with this model to get highly performing teams. Not everyone is the same and we can gain great strength from diversity of people, thought and working style.

In Summary:

1) I don't believe the entire project can be Agile.

2) Agile sizing should be correlated with time.

3) Unplanned and unscheduled work isn't really unplanned.

4) The framework/tool matters a lot less than the process

I feel that we can do so much more with Agile Scrum than with other methods. However, it's not working in a vacuum. It's a tool and how you use it makes all the difference.