The idea of this post came from a debate in LinkedIn about the role of the Scrum Master and whether it’s similar to a soccer coach or not (no, this post is not about Scrum or the role of the Scrum Master) and whether the Scrum Master has to know how to build software or not. To be honest, to me the idea of a Scrum Master being like a soccer coach, giving orders from the bench, deciding who is going to play and who isn’t, setting the strategy, etc. is not my idea of Agile. Of course someone has to make decisions but in my opinion that person could not be always the same and should be someone working “from (inside) and for the team” instead of “just for the team”.
I realized that there is no shared vision about Agile and how it’s applied to build better software. And I also realized that, sometimes, there are different goals depending on the roles:
- One, focused on applying the full process (Scrum, SAFe, Less, …, whatever) and lead by the “agile team”
- One, focused on trying to build (not to deliver) the software required and lead by the “dev team”
To me, there should be a common goal: delivering good software when it is expected
I have to say that I’m not a professional “Agile Coach” although I got some agile certifications and I like so much “the methodology part” of building software. From my experience building software for many years, I think we should return to the basics, “The Agile Manifesto”, and put the focus, again, on building software instead of just following a method.
Return to the “The Agile Manifesto”
I’m not going to explain what “The Agile Manifesto” is but I recommend you to read it again. From this manifesto, I just would like to highlight some points:
-
The title is “Manifesto for Agile Software Development”, so it a manifesto from developers to people working in software.
-
The authors (17) are software developers (although not all of them studied a grade in computer).
-
The first value is “Individuals and interactions over processes and tools” and all of them agreed to put it on the first position.
-
Besides reading values and principles, read also the history. I like this paragraph:
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance.
We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.
OK, I get to the point. If the question is: “Should an Agile Coach/Scrum Master, working with development teams, have built software before?”, in my opinion, “yes, it should be necessary”. Why? Because building software is different from build houses, cars or whatever…. if you want to help someone to improve the way she/he pilots a plane, you’ll need real practice and not only working in the simulator in order to give her/him better advices.
For instance, someone with no experience in building software, can not go to the “Agile School”, getting a title to afterwards say how a development team has to work. To me, the path to become Agile Coach should be to start working in a development team and then, after some years of experiences (and failures), leading the team and trying to improve the way they build better software and deliver more value.
We are uncovering better ways of developing software by doing it and helping others do it
Obviously, there are more skills needed to lead how the way of working should be, but one of those skills, from my point of view, should be having experience building and delivering software.
We are here to build software
It’s the truth. As professional software developers or engineers we are paid to build products, applications or tools using software. Clients want our software not the methods used to built it.
But, nowadays, Agile is a business itself. Some companies sell “agile frameworks”, “agile coaches” or just certifications to other companies. There is a lot of marketing around these frameworks or certifications and every company wants to say that they are doing Agile or showing how the teams are performing stand-up meetings or have many post-its everywhere:
Agile and its frameworks and certifications are now the business instead the software that they suppose to help to build. If you think carefully about that, it doesn’t have sense.
Why? Because the original target (I want to believe it) was not to make Agile a business….The target was (and should be) to build better software by improving the way to do it, and as a consequence of that, better time-to-market, cost reductions associated to misunderstandings, risk minimization, early and continuos delivery, frequent and short feedback, cycles, and so on…
The target is to show the world the software you build. TO show to everyone the awesome software products you are building and how your business has improved and only then, if you want, to show “the agile you are” adding features or fixing failures or how your teams work. But, first at all, to show the product and the working code not the post-its or the cool meetings.
Individuals and interactions: this is what matters
This the core of all: “individuals and interactions” means “working as a team”. This sentence does not mean that you have to work using an specific methodology or having specific tools. It does mean that you need good people that work together as a team, not as a group. I would like to explain this using the example of the salad versus “gazpacho”
If your team works as a salad, you’re not working as a real team. You are just working as a group of ingredients. In a salad, the chef puts the different ingredients together without mixing them. When you are eating a salad all the ingredients are there but separately, and you manage how to mix the different ingredients and you can even decide to avoid eating one of them because you don’t like it or it does not have the quality you expect. Sometimes you say “these tomatoes are great/bad”, “this cucumber isn’t good” but rarely you would say something about the chef. The fault is always in the ingredients.
If your team works as a “gazpacho”, you are really working as a team because success depends on the mix of everything. Some ingredients complement the others. The chef puts in these specific ingredients and makes a mixture so everything is combined. Perhaps the chef will put more of one ingredient and less of another to get a good flavor. When you eat a “gazpacho” you cannot decide which ingredient to eat and which not. And you will like (or not) the whole dish, not the parts. Everyone wins or everyone loses, including the chef.
In a salad, interactions are managed by someone external who decides how to eat it. In a gazpacho, interactions are full because all the ingredients are mixed from the beginning, working as a whole and complementing all of them with each other.
This is how an agile team has to work. The method doesn’t matter. What really matters is how team members interact with each other and how any of them complements the rest. One team wins and one team loses. And, in order to win, to achieve the goal, the team will decide how to work depending on its context. If you, that are not going to be with the team, decide how it has to work, how they have to organize and which tools they have to use, maybe you are not making it easier… maybe you are putting stones in the way.
The key is that the team clearly knows which objetives it has to achieve (and when) and, then, let them to do their job.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Do not copy models
I’m sure you know the Spotify model and you have heard terms like “tribes”, chapter”, “squads”,… If you know more than about the model, you can read the paper “Scaling Agile @Spotify”. This picture, from that paper, summarizes the model:
Do you know that Spotify doesn’t really use this model? ** In the very first page of the paper you will find the following disclaimer:
Spotify had a goal, “turning the music business upside down”, and worked to improve its way of working to achieve the goal. It was its context and its circumstances, not yours. They didn’t copy the model, they created a new one taking some ideas from some frameworks and they tried to apply them to its context.
So, why are you try to copy it?
** Beside that, some people from Spotify say that “the Spotify model” never worked (you can find more details here).
In order for “the Spotify model” to work in your company, you need to copy more than its way of working. You need to copy all the organization and its business model or goals. And, by the way, getting the Spotify model should never be your goal, or a goal. Your goal should be to improve your time-to-market, to reduce bugs, etc.
For instance, do you really think that just performing a retrospective every two weeks using post-it to show what is working, what is not, etc. everything is going to be better? This is, again, putting the focus on the process instead of in the results. Performing retrospectives, plannings, whatever, …is not a goal. And then, Spotify evolved that model according its context in every moment.
If you can’t (or you don’t want to) perform the retro every two weeks or if you don’t use post-its, it doesn’t matter. What really matters is that your team (and your company) talks about how it is working and how it could be better. If your team talks about that drinking some beers every Friday, in the office every two weeks or at home every day, it doesn’t matter. The important thing is knowing what could be improved and setting steps to try it and if that is not the way, change the way.
In my opinion, being Agile also means having the possibility to implement different ways of working at all levels, from the top (company) to the bottom (teams), and to evolve them whenever necessary according to each context and goals. For that reason, from my point of view, when a company decides to apply a “methodology framework” as a whole, deciding that all your teams are going to work using it, the company is really imposing a methodology that thinks is the best for everyone, every team, every department… Again, the methodology should not be the goal. Let’s return to the first value:
Individuals and interactions over processes and tools
Industrial Agile
Sometimes I have the feeling that Agile has become a factory: “how many Scrum Masters do you need? Are you going to need someone knowing SAFe? OK, perfect. I will send you three of them next week”
Agile is not something like programming in Java and getting certified because you’re going to use Java in the same way independently of the context but you can’t use the same “Agile framework” independently of the context. You will have to adapt the way of working according to the goals to achieve. Because of that, for instance, just having an Scrum certification is not enough, because Scrum could not work well in some contexts or teams.
Agile should not be hiring a set of Scrum Masters or Agile coaches to explain the teams how they have to work. Agile should be to allow teams to adopt the best way of working to achieve the objetives, whatever that way of working. I like so much how Martin Fowler talks about that:
The point is, the team doing work decides how to do it. That is a fundamental agile principle. That even means if the team doesn’t want to work in an agile way, then agile probably isn’t appropriate in that context, and [not using agile] is the most agile way they can do things in some kind of strangely twisted world of logic.
So, teams do not need an external figure like the Scrum Master or the Agile Coach to convince them to adopt a specific way of working. Teams need people to make it easy for them to interact with business colleagues or the final user. Teams need people to help them to remove silos. Teams need people to help them to manage dependencies with other teams, … All these things have to be managed in a different way depending on each company, each context. Because of that, Agile should not be industrialized. What works in a company could not work in other companies.
Teams don’t need “outsiders” to tell them how to work because that is, exclusively, a matter of the team and each team is different. Because of that, Agile should not be industrialized. What works in a team could not work in other teams.
I don’t need some certified Scrum Masters (although I also have the certification….) because if Scrum doesn’t work well with my teams, what do I do with them? Do I have to fire them? This is another reason for me to say that the Scrum Master must be a role within the team rather than an “external” person and if Scrum doesn’t work and the team decides to change to a way of working where there is no Scrum Master role, it should be OK.
Agile is having a plan to change it
Although you are practicing Agile you need a plan. Yes, in my opinion there is (should be) a plan to achieve a goal. Maybe you are thinking, again, about this value of the manifesto:
Responding to change over following a plan
The key is that the plan can change because there are changes and being Agile is responding to them. As a team you should always know “what the goal is” but, depending of the circumstances, “how we are going to achieve the goal” and “when we are going to achieve the goal”, could change.
We plan, but recognize the limits of planning in a turbulent environment.
For instance, when you decide to go somewhere you have a plan to do it and, initially, you know more or less when you are going to arrive there. Maybe there is not a formal plan but, in your head, you have a goal (or goals) and a plan to achieve them.
If, on your way to the goal, you find a closed road you’ll change your path, but the goal is still the same although you know you could arrive later. Then, an event more happens; your mother calls to ask you if you can buy something she needs. You’ll change your path again and you already know you are going to arrive later and you call to your wife/husband to let them know of your delay at that moment so your couple can react to the event.
As a company, you should know where you want to go in a medium or long term, what you want to do with your business because you want to earn money because you have to pay the payrolls of your employees and also, get some benefits. Because life is hard, there are more players playing at the same game and they want to win, you’ll have to adapt your plan continuously in order to provide the best product or service to your customers (and potential ones). That is being Agile.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Maybe you are thinking “having a plan at company level is OK but I’m just working in a team.”. Each team should also have a plan to achieve their goals and should respond to change updating that plan in order to keep providing value to the customer. The backlog is a plan to achieve something (an MVP, for instance). The team should introduce changes in that backlog in order to react to unpredictable events, “feedback” (bugs, improvements, …) from users, managing risks, reducing technical debt, etc.
Agile is not about going faster
Do you know the book “Scrum: The Art of Doing Twice the Work in Half the Time”?
Forget it. The title is false. You are not going to “do twice the work in the half the time”.
Do you think that if you do Scrum, the amount of code needed to implement an application is going to be less than if you don’t do Scrum? Do you think that you are going to find a good solution faster than if you don’t use Scrum? I don’t think so.
Agile doesn’t mean doing things faster. Agile means doing things better, maximizing value delivered when it has to be delivered. The amount of work is the same independently of the methodology. The methodology can help you to understand better your customer and to receive feedback sooner in order to improve things. A methodology can help you to put focus on the important thing: the value delivered to the user.
We can talk a lot about what is “value”. In my opinion, “value” stands for doing what the final users need when they need it. Agile isn’t going to help you to get impossible deadlines. Agile can help you to define a goal and to adopt the best way of working to achieve the goal.
Agile can help teams (and companies) to be conscious that the way chosen is not the right way and it has to be changed. Agile can help to avoid waste.
Agile does include documentation
I have heard many developers saying that they don’t design or document anything because they do Agile and they refer to this value:
Working software over comprehensive documentation
And, of course, they also say that the best documentation is the code.
As I said at the beginning, if you read the history of the Agile Manifesto, you’ll find the following sentence:
We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.
So, it’s false you don’t need design or documentation in Agile. The point is to be pragmatic. When we talk about documentation, having a lot of documents not up to date (maybe because its format is not convenient), is not pragmatic. But also, having no documentation is not pragmatic.
Do you imagine having to read thousands of lines of code in one or many repositories to know something about the system? Have you ever thought that some of those lines could be not-used code? And, what if you don’t know the language? How are you going to know how the end-to-end architecture is?
Maybe you are thinking that someone knowing the company is going to explain everything to you but have you ever thought that, in our sector (SW), rotation level is too high? When people come and go you need something more stable and of course, something practical that could be updated easily
Agile is thinking more and coding less
Many people think that being Agile is starting to code as soon as posible, without designing anything. This is a big mistake.
Design is the most important part of building software. It is always there, no matter if you use a paper or a tool but think, think a lot, before coding. To me, being Agile is coding only when I know what I have to do and only what is necessary. No more, no less. I try to follow these steps:
-
Listen and try to understand the problem (sometimes there is no problem) or need and use cases. Try to answer “what (is the problem/need/use case)” and “why (is there a problem/is it really a need/do they need this use case)”. Ask as many times you need until you know the context where you are going to work.
-
Design efficiently keeping in mind the uses cases (remember YAGNI and KISS). Don’t think in products, frameworks, tools, etc. Think about business, components, behaviors, interactions, data managed, patterns, concepts, requirements, domains, responsibilities and so on. Study alternatives. Think also in failure scenarios and design them. If you don’t know the scenarios, return to step 1. Be agile. Don’t guess.
-
Try to assign products, frameworks, tools, etc. keeping always in mind the context in which you are going to apply the solution.
This is very important. For instance, if you are thinking about implementing an application using ReactJS but most of the applications in that context are built using Angular, you should argue very well why to use React instead of Angular. Think about the current knowledge in that context.
Or for instance, if the budget is tight maybe you should evaluate free alternatives to some commercial products although these ones provide more features or better performance. Do you really need them? Maybe not or at least not since the beginning.
-
Think how you are going to probe the solution(s) and its parts and end-to-end. If you don’t know how to test the solution you don’t know what the problem is. Return to previous steps. Something is not clear.
-
Think how you are going to put the solution into production (and how you are going to observe it, monitor it and evolve it) keeping in mind, again, the context. If we are designing a complex solution to be deployed in production or a solution “not compliant” with the current production environment in that client/context, “Houston, we have a problem”. So, the key is detecting it before throwing a line of code instead of when the code is ready to be deployed in production. Be agile. Return to previous steps.
-
Have you think about risks and dependencies? Do you have alternatives? Be agile. Study risks and how you can manage them.
-
Implement it (test & business code).
-
Deliver it.
-
Receive and analyze feedback.
-
Make decisions.
Only step number 7 is related to code. Don’t go directly to step 7. Be agile. Understand the problem or need and think about the best solution(s) in that context before coding.
Coding without understanding the problem is waste. The best code is the one that is not written.
Agile is delivering, delivering and delivering functional software
Working software is the primary measure of progress.
When we talk about “working software”, we talk about software being used by the user. If the user has not used the software we have built, the software has not been delivered and then, the features associated to that code are not finished although we have passed tests.
Keep in mind three fundamental truths:
- Reality exceeds fiction. Everything will fail anytime.
- The reason can be unknown yet but in production environments usually things work different that in previous environments. The sooner you detect this kind of “differences” the better software you will deliver the next time.
- Users will always find more bugs than you.
So, if we mark tasks as done without them being accepted by the user, we are fooling ourselves and making the same mistakes as the traditional methodologies setting all the tasks to 90%.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Build, deliver frequently, receive feedback from the users and improve. This is the process. Simple.
If you use Taiga, Jira, Jenkins, 2-weeks sprints, Scrum, the most recent frontend framework, Kubernetes, whatever… it doesn’t matter if you don’t deliver continuously working software to the final users.
How can you deliver more frequently? Design, technical excellence, KISS, YAGNI and CI/CD are your best friends.
Continuous attention to technical excellence and good design enhances agility.
To be or not to be Agile
In my opinion, “to be or not to be” Agile does not matter. As I said before, the important thing is to focus on doing things (software) well and delivering them when the user expects them. Simple.
For instance, if we read the Scrum Guide we found the following point:
The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
The Scrum Guide also sets a role to guaranty that the methodology is applied like the guide says:
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Don’t you think, again, that this is putting the focus mostly on the process? It doesn’t care whether the result is Scrum or not because, again, the goal is not the process. The goal is to build better software, the software that the users expect
Agile is an attitude
I would like to finish this post with this quote from one of the signers of The Agile Manifesto:
So, I hope you liked it, whether you agree or not with my vision. That’s all folks.
