The discussion about software methodologies is not over. Agile did not win, nor did any other methodology. I’ve never worked in a team that hit the right spot in team dynamics and was as effective as possible, whether using incremental development or not. I think I’ve figured out what it is that still needs work in that area.
Most discussion about methodologies is about trying to find an ideal one. Should it be more structured? Less structured? How many meetings are we doing? You try a bunch of recipes such as scrum, kanban, waterfall; sometimes they work, and sometimes they don’t. It’s like aiming at a moving target.
The problem is not which recipe to use, it’s being aware of each one’s strengths and weaknesses. Teams need to know when structure is beneficial and when it’s not—and realize that achieving good team dynamics is a skill to be honed. You can’t write down a process plan and expect everything to magically be smooth sailing from then on because project requirements vary in many ways that sometimes aren’t self-evident.
Even throughout a single project, using a single methodology is far from ideal. For example, are short iterations a good fit for a project that needs big design up front, no matter what? And if you use long iterations, what happens later when you realize your design is lacking in a specific area?
Looking over these issues, I'm going to make a case for why:
- Being agile and working smart are not always the same thing.
- An adaptive mindset means knowing when your methodology helps/hinders you.
- Office life and daily issues can completely change the effectiveness of your process.
How development focus changes throughout a project
In a large project, the team's focus is constantly changing. When development begins, you might split the project into modules, with strong code ownership rules and laser-focused development.
Later on, when most modules are going through a debugging and testing phase, code ownership gets in the way. At that stage, it’s more productive for developers to go through their own short testing/debugging cycle and be able to fix bugs anywhere. Excessive communication would slow them down considerably. Although someone with more knowledge about a module will be more productive when working on that part of the code, on the other hand, more eyes on the same piece of code will lead to fewer defects.
Perhaps the realization that things change constantly is what brought us to have more granular methodologies such as RUP, with its bazillion roles and artifacts. A highly dynamic methodology such as RUP requires people to learn new habits constantly. It’s hard to even get people to make a stand-up last 15 minutes. I don’t want to know what happens when you make them jump through 10 times as many hoops.
More structure means more concepts to learn, a higher cognitive load, and a harder-to-apply methodology. If the question is how to make the work flow as smoothly as possible, then jumping through more hoops is not the answer.
Is it right to use agile everywhere?
Agile is lightweight and easy to implement, and the project’s direction can be adjusted based on completed work, not on speculation or predictions. It can adapt better to changes, but sometimes it prevents you from going where your project needs you to go. Here are a few cases where its iterative process doesn’t work so well:
- You need a big design phase up front. You need precision and don’t care so much about development time. Anything NASA does would fit here.
- Your business has a high cognitive load. It’s hard for users and/or developers to get it, so you need a lot of well-organized documentation. Enterprise and financial software are sometimes examples of this.
- You’re doing a complete rewrite of your software, so your team already has a clear idea of where to go. Requirements are clear, and there’s not much need for course correction anymore.
There is a lot of focus right now on getting the kinks of agile just right, and it’s a productive mission, because most teams don’t get it right. On the other hand, to realize the full potential of your team, you need to know when to switch things up and when agile is holding you back.
Besides those specific cases, it’s a good idea to always keep in mind the disadvantages of agile:
- It requires high customer commitment. Some customers are too busy for that.
- It requires constant and/or automated testing. Some customers don’t want to spend money on that.
- There is a huge communication overhead for remote teams. Prepare to spend more time setting up WebEx/Skype and working on IT issues than actually writing code.
These problems are responsible for the fact that most companies today are applying some kind of hybrid agile process rather than staying true to its principles. But it’s important to know why agile exists, what problems it solves, and when to stick to the core agile principles. This is why I said that achieving good team dynamics is a skill.
When to make changes to your team
Typically a team stays mostly the same throughout a project, but as the project progresses, it’s unlikely that everyone’s strengths are being leveraged at all times. People are good at different things.
Generally speaking, more experienced team members are better leveraged by having them use their experience more than their mechanical skills. The inverse is true for the least experienced.
If you were to make both experienced and inexperienced developers solve a coding challenge, the more experienced ones might do it slightly faster by calling a specific library that a less experienced developer won’t even know exists. That difference in experience may well be where the “10x programmer” expression comes from.
One of the main focuses in modern software development has been in reducing cycle times, but they are an incomplete measure of team productivity. Getting stuff out faster will let you adjust more often, but that won’t help you if you’re not willing to use the right people for each problem by taking their specific experiences into account. Familiarity with a problem is a huge leverage point, and modern methodologies throw it under the rug when they turn the whole team into numbers, each one with identical weight.
Adapt your daily routines to your current team
The final aspect you have to look at when you want to be a fully adaptive team is the details of your daily routines. These can make or break your methodology’s effectiveness.
I remember being in an agile team where the daily stand-ups were contributing almost nothing due to several factors. You might have seen it yourself—when no one has anything to report in the stand-up for days in a row. The thing that still made stand-ups effective for me in that case was the fact that my desk was literally two meters away from where we would meet every morning. The effort to get there was so small that it didn’t matter.
A poor implementation of a methodology can still work if the specifics are adjusted to make up for the issues.
I’ve also seen the opposite situation, where you have a well-applied methodology that is made worthless by the accumulation of small daily issues, such as videoconferencing software that never works and poor hardware or infrastructure.
The bottom line is that to make your development process work, you have to take a hard look at whom you’re working with, how they like to get things done, and what resources you have at your disposal. Then you should make every effort you can to help your team stay in the zone. Make the working environment comfortable and effortless, and the work will flow.
If your team members have lots of experience, trust them, and help them enjoy getting things done. Don’t undermine the relationship by requiring them to jump through hoops to get work done.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
