In software development, we deal with a huge amount of buzzwords. People hear about certain practices and then try to blindly apply them, without going too deep into what they mean.
I did that, too. And, at a certain point, I decided to stop. No matter how revolutionary a technology or tool is, it shouldn’t be used just because it’s bleeding edge. I learned in time that it is best to apply what is necessary, what solves the problem in the simplest, most elegant way.
I’ve always been in conflict with people who said that Agile is the best option for every project. Because I really believe there is no such thing as “one size fits all”. Actually, in my own experience, and that of many experimented engineers that I know, in order to successfully run many software projects that we’ve been working on, we had to take them into a minimum Waterfall sequence.
I realize that this is where someone might interrupt me and make the correct observation that for Office Timeline, the project that I’m currently pouring heart and soul into – and have been so for over 10 years, we do use Agile. Yes, that’s true. But it’s a very personalized Agile. And in order to personalize Agile, or anything else for that matter, you first need to know it inside out.
A bit of context
Since it emerged in 2001, people have written volumes about the Agile methodology and all its instruments. I cannot even begin to cover the subject extensively from a theoretical point, in this article. But a short definition, and a bit of context, may be of help.
In software development, Agile practices include requirements discovery and solutions development through the collaborative effort of self-organizing and cross-functional teams with their customers or end users, adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.
In 2001, seventeen software developers met in Snowbird, Utah to discuss lightweight development methods. Together they published the Manifesto for Agile Software Development. Based on their combined experience of developing software and helping others do that, the seventeen signatories to the manifesto proclaimed that they value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
So far, so good. There’s nothing to come in conflict with my own principles for a successful software development process.
But the problem with values is that they need to be accompanied by procedures and tools in order to be implemented.
For instance, any team needs to measure its productivity. In Agile, it is measured in story points per iteration, which shows the team velocity. For example, one team can deliver 10 story points per one iteration and another team only 5. But can we say with 100% certainty that the first team has performed twice better? Not always, because measuring software development work is not only a quantitative problem, but also a qualitative one.
As I mentioned before, for Office Timeline (OTL in short), we do use Agile and SCRUM. And we’ve been doing so for many years, to the extent that we came to a point where we considered that we can responsibly tweak some things that just don’t apply to us. Here are 7 ways in which we personalized our software development process in OTL:
#1 Assess the team level
A common sense rule is that you have to assess your team level first. The Agile methodology, and moreover the SCRUM framework, may help the dialog and feedback in certain types of teams.
In trusting that we work with people of certain capabilities, and a certain technical level, we also trust that people are able to collaborate beyond many of the Agile/SCRUM enabling techniques.
#2 Developer autonomy
So, now that you assessed the team level, the basic principle is that the developer should have as much autonomy as possible. In OTL, a developer receives the problem and is allowed to come up with a solution proposal. If the problem is a complex one, there may be more than one people designated to come up with proposals.
I can make an analogy with a concept that is used in the military strategy – the “spearhead” concept. The idea is to concentrate as much firepower into a small front as possible, so any defenders in front of them will be overwhelmed. As the spearhead moves forward, infantry units following in the gap behind them form up on either side of the line of advance in order to protect the flanks. In a software project, the idea is to allocate the best people that you have to find the optimum solution as quickly as possible, and then move on to the implementation phase.
That doesn’t mean that the spearhead always decides what the best solution is. For instance, they could come in front of the team and present the possible solutions and then we decide together. The collaboration is as flexible as possible.
#3 Fluid roles
If developers are permanently caught in a “two-week sprints / user stories” scenario, a certain type of anxiety may surge that they’re on a spinning wheel and there is no exit strategy. As a tweak, in OTL and more generally, in RomSoft, we are allowed to have fluid roles. I’m a principal design engineer. Up to a point it’s similar to software architect. But I’ve been through many roles. Build engineer, release engineer, support engineer, software developer, and even software tester for a very short while, due to a project emergency.
If you think about it, this kind of flexibility really is in the spirit of Agile. A spirit that sometimes feels that we are sacrificing for the sake of ceremonies and rituals. I think any project role can be beautiful, as I consider every one of them an opportunity to learn. And a bit of variation where you can gain a fresh perspective on the project, is also good.
Transparency doesn’t just mean open floor space and keeping people in close check at all times.
Sure, at certain times, you may have strong reasons to increase transparency from the bottom up. But at the same time, you should make sure to improve visibility from top – down, as well. What are the objectives? What is the greater purpose of doing things in a certain way?
You should maintain several communication channels opened and make sure that information flows freely as soon as it is needed. One side transparency will not work.
#5 Avoid cargo cult
There were moments at the beginning of my career when I fell victim to cargo cult. I read something in a book and, very proud and excited I tried to implement that solution in a project I was working on. As it later turned out, it was not the best solution for that particular project. And I learned from my own mistakes. Now, if I see this happening in a project that I’m responsible for, I intervene.
As a methodology that is used at such a global scale, Agile hasn’t been spared of this phenomenon – where it has been transformed in a religion and cargo cult.
For example, you cannot blindly implement the stand-up ceremony. It is a short meeting, a daily kick-off that should not take long. If there are more serious problems to discuss, they have to be transferred to a different environment.
The idea to stand up is to enforce in a way the short duration. But we shouldn’t implement it undiscerningly, as we work with smart people who are capable to organize themselves and respect a consensus. They don’t need to be tricked into it. We need to retain the essence of things in Agile.
#6 Pass on the information
What could be of more help than using tricks? Implementing some healthy principles such as a timely distribution of information.
For instance, if I solve an important problem, I don’t have to wait for the next day standup. Or if I have a problem that needs to be solved, and I know the person who can help me, I will choose the fastest channel – direct communication. These are common sense.
#7 Maintain the principle, allow the flexibility
Sometimes, it is more important to retain the principles of Agile, but to adapt them to the people you are working with.
For example, as much as we adhere to the principle to maintain iterations as short as possible, we don’t have a 2 weeks enforcement rule. And this kind of flexibility is allowed in other areas, too.
In another instance, we noticed that our new engineers experienced a very smooth onboarding process and they integrated quickly to the team. As such, we thought it didn’t make sense anymore to get them through those stages of forming a team from SCRUM, forming -> storming -> norming -> performing.
Last but not least, you should never have to be forced to hold a meeting if there’s no reason for it. For example, in OTL we have 30 minutes meetings – three times a week. But if before the meeting we realize that there’s nothing on the agenda, we ditch the meeting.
As a side note, this personalized system works best when people in your team are responsible, autonomous, guided by strong work ethics, and announce problems as soon as they appear.
The line in the sand
Agile is subjective. There will always be people who think it’s the Holy Grail of development process and there will always be people at the other end, who will think of it as the ultimate productivity killer. But I think moderation is key. And that the secret is in communication.
Taking a step back, I hope this doesn’t feel like I’m complaining. In IT we are privileged, and I feel that in the RomSoft – Office Timeline partnership, we have a superior set of privileges. We are lucky to work with a customer who is open to communication, and who would listen to anyone from the team, no matter their role in the project. People will always be heard. We have a flexible schedule. We have access to one of the best project infrastructures in the world, which is Azure, and we have extended support for continuous learning and professional development.
I just needed to make a point that no matter the technology, methodology or tool that we use, we should filter everything through something that we all call common sense.