Author: the agillator

In a waterfall based project distinct project phases are clearly defined, one of them being requirements definition. This phase very tedious and requires a lot work and attention from the business side. Everyone has to dive deep into the business processes, understand them, even optimize and improve them, before handing them over to be implemented. This also means, that the goals for the product have to be clearly set and all the major decisions made.

In enterprise level companies the processes complex and not always clear, responsibilities even less transparent and management tasks swallow a significant amount of time. So you hire Business Analysts, give them a visionary sentence or two, let them gather the information around your organization and as a manager keep your hands out of any decisions, which could be traced back to you in a case of failure. The project ends up with a more or less clear list of requirements, which are then passed to the software engineers.

After engineers start implementing, they find out contradictions, loopholes and different goals being set for the project and usually no one to clarify these problems with. In the best case the Business Analyst is still there and if they are really brave, they clarify the questions with the management and the other business experts. Everyone is irritated, that the developers don’t understand the requirements, and that they are coming along so slowly.

And then, business side discovers agile… The methodology, which has no distinct phases, especially no business analysis and requirement definition. This surely is a blessing in their eyes. A very time consuming and expensive activity is just not needed anymore. They can pass their visionary sentences to the developers, they will intuitively understand what the business meant and implement it in two weeks. Let’s go agile!

When the reality of agile hits, only then they realize, is that the User Stories used in the most agile frameworks are the basis for even more elaborate and precise requirement definition, then it was the case in the waterfall model. Ideally being based on the Behavior Driven Development, the user stories have detailed acceptance criteria. These acceptance criteria must be crystal clear to both the Product Owner and the developers and are ideally formulated to be used as test cases. Not all of this has to be documented in detail in the user story itself, but at the end of the day it is documented in the implemented code and the test cases at least.

To implement high quality software, it doesn’t suffice to exchange the murky waters of waterfalls with even murkier agile waters. The key to success are cold clear waters of user stories and sharp acceptance criteria with defined test cases. And none of this appears out of thin air, but is a result of intense communication between the business and the developers. Which in the end means, that the business experts have to be available as long as the project is running and must be able to make important business decisions. Once the managers realize that their decisions are becoming transparent and results are almost immediately measurable, some of them regret the idea of introducing the agile methods into their organization.

Cold clear water of agile is a blessing for the company, developers and the customers. But agile is surely not there to enable anyone to cut corners. You have been warned.

Let’s start the year 2019 with this slogan originating from the French Revolution, which is answer to so many social questions: Liberté, Égalité, Fraternité. And the question I will be answering with it is: What is the secret of successful teams?

If you think I am making this up and the answer sounds to simple, take a look at the studies about what enables teams to be something more than a mere group of people working more or less towards the same goal. One of those studies has been conducted by Google and the results are published here: What Google Learned From Its Quest to Build the Perfect Team.

What the studies in their core say is, that you have to provide equality between the team members. The team also must have the liberty to make its own decision. And not everyone has to become like a sister or brother in the team, but feeling social security and freedom to speak about the most secret and crazy ideas is crucial. Just as when you talk confidentially about most intimate questions with your sister or brother, or someone you feel as close.

Agile frameworks can make your team live up to the above slogan faster than any other. Just keep in mind, that they are tools to achieve freedom, equality and trust inside a group of people. Implementing agile inside a team cannot be a goal by itself. If you happen to try to heal the team by just “making everything agile”, you are bound to fail. Go for the French Revolution using agile and you and your team will thrive.

When trying to become an agile organization, one of the first frameworks to be tried is usually Scrum. It is very popular and well understood, even if not easy to  implement. One of the most prominent roles in this context is the one of the scrum master.

Since the people in the team all have previous experiences, same goes for the scrum masters. Many of them have been projects managers and when the organization decided to switch to agile they had a choice to become either product owners or scrum masters. The ones closer to the product management tend to choose the product owner role. But the ones closer to the daily team work and hands on projects management, which probably will be the majority, jump into the scrum master role.

Being a project manager is a role, which in itself can be filled in many different ways. Some project managers tend to use command and control more, some let the team have a different degree of freedom. But one thing they all have in common: Project managers are held responsible for the success of the project. And to live up to that expectation they have to choose the best team, the best technologies and strategies. Put bluntly, a project manager has a goal and he is using all the means necessary to reach that goal. The developers are one of those means, the others being requirement analysts, architects, project management office and so on.

In a certain way, a project manager is the master of the project. He is watching over it, directing it, running everything. This is oversimplified, of course, but let’s ignore that for a second while we are looking at the role of the scrum master.

Reading the title scrum master, when being read through the eyes of a project manager, the word master somehow feels familiar. It reminds a lot of his current role and the tasks he has. After all, he is a project master right now, so just changing the methodology will not be that of a big deal.

But it turns out, that the master in the scrum master is something completely different. The master in this context refers to the mastery of the scrum as an agile vehicle, not to being above someone in the organizational hierarchy. It is just like the master in the kung fu master: He knows the depths of the kung fu. And the scrum master knows the depths of the scrum. But not just at the theoretical level, but on the mind and organization changing level.

So what change of the mind is necessary for someone like project manager to understand this new role and fill it appropriately? The core of this is that the scrum master is in fact a team servant, not a team master. His purpose is in serving the team to successfully reach its goals while at the same time becoming ever less needed by the team. In short this means helping the team to set the goals, to stay focused on them, to reflect on the best ways to reach them, to develop habits of improving themselves as a individuals and the team. On the other hand this also means providing the best possible organizational conditions for the team to be able to focus on their goals and not waste their time with jumping through the loops of the internal bureaucracy. Scrum master is also the person who will mediate solutions to the conflicts inside the team and provide the right setting for every team member.  And this is not where his day ends.

In the future posts I will deep dive into the most important aspects of the scrum master role and how to make all of this agile thing happen. For now this short listing of his goals and tasks gives a very rough frame, especially for someone coming from command and control organization and into an agile team.

In the conclusion, if a project manager, or someone coming from any other role is ready to serve a group of people instead of controlling it, help them become a successful team and celebrate the shared responsibility and success, he is the right person for the job. If you are not ready for the above, you and your team are going to have a rough time, until you realize the change of mind needed, master the scrum and you all together become masters of scrum.

There you have it, your new shiny team. You have done everything by the book, all the agile events are happening regularly, everyone is getting used to each other. In your development team you have your testing experts, your database guru, your coding magicians, your continuous integration and deployment pipeline plumber. All is in place.

Then one day you have to stop all the work on the database, because the expert is taking a vacation. Two days later your testers go for a seminar. And all of sudden, the magic of the coders is not working any more. The database is not working, no one knows how to write tests or even to start them. Everyone is doing their best, but it is not enough. What to do now?

Not much can be done, when this is already happening. You can either try to hide it from the product owner, which is a very bad idea, or be honest with him, and try to patch your losses by borrowing someone from another team. But even that will be more a cosmetic attempt with little or no positive effect. It will probably backfire.

Could you have prepared? After all, you hired the best people on their respective field, you have done everything right, right? For some roles you even doubled up the people, for the case someone gets sick or takes a vacation. Is there anything else?

You’ve probably heard, that in an agile team, everyone should be able to do everything. But if someone can do everything, he can’t do nothing right, since he is not an expert in one specific field. So the common knowledge at least.

Welcome to the age of multiple areas expertise. This means your ideal team member is a so called T expert. He covers one or two ares really deep, and in other areas they are good enough to manage by themselves.

But where to find these new age experts? It is difficult enough to find good people for one area.

The answer is, that you don’t find them. You grow them!

You already have all the expertise you need in one place. All that has to be done is the distribution. And here are some suggestions how you can use each expert to teach the other one or the whole group.

Pair Programming Let the people pair up, when they take up a task. Pair up a tester and a coder. Let the tester learn coding step by step and let the coder train challenging the implementation. When you suggest this, everyone will tell you, that this will slow you down. People are used to the thinking, that nine women can bare a child in one month. So if you put two team members on one task, the number of tasks in the sprint will be cut in half.

Well, not exactly. See, what you would be doing is separate session, like coding and testing, is being done in one session. It will probably take longer than just coding it, but much less than coding and testing and fixing and testing it again. The probability that you will get things done in one run is much higher.

At the end of the day you got faster, and your team is getting more coders and testers every day. But don’t stop there. Pair up people on any task. Let them learn about databases, pipelines and architecture from each other.

Group Programming Sometimes team members have very different ideas of how certain code should look like. To speed up the development of team wide programming style, group programming sessions can be established. Especially at the very beginning putting the whole team in one room in front of one big screen can speed things up. Just give it a try and see what happens. The smaller the team, the better it works. Let the team work out the details and when they feel confident enough to break into smaller groups.

Reviews You are probably already familiar with the branching and merging concepts. The reviews I am talking about, are the ones in this context. Every time you merge your code from the feature branches, let someone review the developed code. Someone who didn’t work on the task at all.

At the beginning you can have your senior developers review the finished work. Take care, that the feedback given is constructive. As soon as possible provide the possibility for the senior experts’ work to be reviewed too. This will prevent the creation of hierarchies in the team, and at the same time allow people to learn by just reading the code. And even the most senior developer has a lot to learn from his teammates.

Don’t make any exceptions to the review rule. Try to prevent, people pairing up and reviewing each others code exclusively. This will prevent any feelings of exclusivity and will keep the team balanced and intact.

Architecture and Design Planning When planning a sprint try to establish a two phase planning. The first part of the planning should be conducted with the product owner. In the second part, the team should take their time to dive into the details of the architecture, technical solution, and implementation strategy.

Usually there is no specific task for developing a technical design, let alone for architecture. If this second part of the planning is omitted, you will end up with a big ball of mud, ridden by technical debts. When this second phase is promoted, the whole team will be able to pursue the same design goal, without anyone having to check, if they are sticking to it. They will be checking themselves, since they have a clear picture of what has to be done.

In this planning the techniques of strategic software development can be shared among the team members and completely new approaches can be born. Don’t let anyone full you, that agile teams don’t design and don’t need architecture.

One-on-one Feedback Talks This is something you will not want to do at the very beginning. Let the people build up their trust first by by using pair programming, by celebrating their successes, by practicing constructive criticism in the retrospectives.

If you are the scrum master, you can start this up by requesting the team members to give you feedback and suggestions how you can improve your work and relationships within the team. Listen carefully to what they have to say. And be sure to act upon it. If they ask for your feedback be sure to be as objective and clear as possible. Always reiterate, that even if you are trying your best, you are still inevitably being subjective.

Once this is established, encourage other team member to gather feedback for themselves, and if any way possible, from everyone in the team. This will make sure that the social competence of the team will dramatically increase. Blind spots can be discovered and personal development of each team member helped forward.

Refinements There is probably nothing you don’t know about refinements. As a product owner you sit down with you team, you go over the user stories, explain them and after everyone understood everything, you are good to go.

Unless you want to use this chance to inspire your team, to explain them the overall goal, show them the big picture, how the product is a part of a company’s strategy and what exactly you want to achieve.

If you use this chance to transport your vision the team will follow you. Since you are surrounded by talented people, they will have suggestions for improvement. Make sure to encourage this kind of feedback, since it will improve your product and implementing own ideas makes the team enables the team to identify with the product.

For the developers this is the unique chance to learn how the business is functioning, what matters when it comes to the marketing, sales and strategy, how products are developed. This is not something you would usually learn on a computer science class. Who knows, maybe one of these refinements will give birth to another successful startup.

Communities of practice This is where you leave the realm of your own team and make a step towards spreading the knowledge between different groups. If you want to know more about the community of practice, the wikipedia page is a good place to start.

Important thing is to make the attendance count. Share your solutions and approaches. And don’t have the whole team attending, but just one or two members who can transport the subject of matter to the wider audience. And let them gather ideas for problems you still didn’t encounter or you did, but your solution doesn’t make you that happy.

Communities of practice can create very valuable pattern and overall solutions and deliver templates for the overall architecture.

These are some of the ideas how to spread and create knowledge while using agile methodology. Scrum and many other approaches don’t have these as a part of their framework. Which doesn’t mean, that they are not needed. On the other hand, even if you  are not officially in an agile environment you can use some of the measurements to improve your team. Please try them out. But never enforce them. Your team will return it to you many times. And in the end you will be the one to learn from them.

I am sure that you have seen at least one of those movies, in which a guy or a girl masters a martial art. You know, like Karate Kid. Or Kickboxer. They start off with the main character being, well, not the top notch fighter. Then they find a master. Music start playing, while you see them practicing in the sunset. After a few minutes music stops, and our hero ends up invincible, kicking down a concrete column.

I also thought that growth, personal and as a team, is something accompanied by music and it happens overnight. You read the manual, get the certificate, visit a seminar, you bread in and out, and you are changed. You fall asleep as a baby without any teeth, and wake up with all of them fully grown.

Many have the same expectation about agile. Once you start doing it, it will not only solve all the problems you had before, but will make you grow and improve almost overnight.

I have a good news for you. Agile actually does offer the possibility for you and your team to grow. To grow your technical, and your social skills. To grow your understanding of the business. It even offers space to improve the understanding of yourself.

But I also have another news: It comes with a price. When babies grow their teeth, they don’t think it is fun while it’s happening. Also they take time to grow. And worst of all, there will be no music playing in the background, unless you play some. While teeth grow by themselves, growth in an agile is not going to happen by itself. Just like in those cut sequences, you will have to punch, to bleed, to fall, to get yourself up again, and again and again. You really have to want it and fight for it.

When your team makes first steps in agile, you will feel excited. Your first few iterations my be very harmonious. Only when the sunshine starts fading away, the growth starts happening. People start opening up and conflicts occur. And this is where you have to start using agile tools and need some very capable, empathic and experienced scrum masters.

Don’t worry about conflicts. As already said, they are a sign of growth, just like the pain, while teeth grow. Facing tough problems is good for the team. It releases a new energy inside the team and individuals. Use this energy in the retrospectives to channel it into creative solutions. Allow conflicts to be resolved in an ordered manner. Protect the integrity of the team members and the team itself, while allowing the core of the problems and conflicts to be constructively  discussed. Provide clear guidance to the team and enable them to create solutions. They are very intelligent people and they will find their way.

Just like for any other skill, you will need patience to reach mastery in retrospectives. Things will take time. And then some more. And once you know all the moves, once the team finds their groove, you can’t stop practicing. Your knuckles will not bleed anymore, but you still have to punch that board at the end of every iteration. The board will not get softer, but you and your team will get stronger.

Retrospectives are not the only way to help your team. Use your successes to celebrate them. Together. Make every successful iteration a visible achievement. Celebrate the team and the effort. This will raise the spirits, and for the long way in front of you, you will need that.

Don’t allow the team to shut off from the experience and knowledge of other teams and other areas of knowledge and expertise, even if under pressure focusing might look like a way to go. The team will be focused on solving the problem, becoming a team, but allow them to move their focus away from that. Let their minds wonder in different directions and let them bring these fresh thoughts back into the melting pot. Allow every team member a few hours a week or even a whole day to work on their own projects, research and develop a skill. Even if it has nothing to the with the subject of the matter of the project. They will be able change the perspective easier, when solving impossibly complex problems. And this again, will make the solutions less complex. And we all know how important that is.

Use the loops to hone the individual qualities of the team members and allow people to influence each other in the best way possible, even if this means going through conflicts and using unorthodox approaches. Agile framework allows this growth to happen. But you will have still have to do the heavy lifting. The struggle will be real. It will be long. And it will be worth it. The new you and the team at the end of the process will thank you. You will probably not end up being invincible, but able to get up stronger whenever you have fall. And the growth and change process will never end. What else can you wish for?

Once you look back, after maybe a year has passed, things might seem like you watch them in the movies. Good memories will flashback in front of your eyes, and it will feel as it if your grew overnight. Now, all you need is some fine music and a sunset you can ride off into.

Whenever an enterprise wants to introduce agile as the new big thing, you hear a lot about the benefits. What you will hear very often is, that everything is going to be faster. Well, cheaper as well, but even if it doesn’t get any cheaper, you will definitely finish everything much faster.

Let’s take a look at the word itself and the meaning behind it. This is what Merriam Webster has to say about it:

1 : marked by ready ability to move with quick easy grace – an agile dancer
2 : having a quick resourceful and adaptable character – an agile mind

On one side we have graceful movement, and on the other a resourceful and adaptable character and an agile mind. Since agile movement is based in the software development, and software development is somewhat of a mental activity, it is a safe bet, that the second definition is the one to go with.

Agile introduces resourcefulness and adaptability. What I hear is not speed of going ahead, but the speed of changing your concepts and adapting your solutions to a suddenly changing environment.

Being agile doesn’t mean quickly reaching a firmly set long term goal. Being agile means reacting fast when the goal suddenly changes. It means seeing things from a new perspective, changing your mind set, changing your habits in a very fast pace. Sometimes even every two weeks.

How can there be no speed up, when everyone is using agile methodologies to shorten their time to market? If you use agile to implement a set number of features for your product, meaning that your product is only finished, when all the features are implemented, you wont be any faster than using any other methodology. Your good ole’ waterfall will do better, if you are  good at it.

Agile delivers the most important features first. Not all of them. Just the important few. And since this is just a fraction of the full feature set, the product can reach the customer much earlier. This is how the time to market is shortened. The full feature set, as conceptualized at the beginning, will probably never be implemented. Other features are born from the interaction with the customer and implemented instead.

If you expected the speed of light, agile is not your silver bullet. It is not the magic wand that somehow enables you to break the famous triangle speed – quality – cost by increasing the speed at no cost and no quality loss. If you want to become faster, buy a Lamborghini.

The good news is that enables you to react to the change faster, to transform faster, to start every iteration with a new mindset. It help you to understand your customers’ needs faster, and adapt your products to their wishes and satisfaction. If you are looking to speed up the change, then agile is right for you.

When fighting to introduce agile, don’t use the speed as your first argument. Not even as a second. Do yourself a favor and don’t use it at all.