An agile team is closely tied to what I consider to be the core values of Premium Minds: the quality of the end product, the life quality of the people working on the product, and, of course, the Agile Manifesto.
After two and a half years working as an Agile Coach for several diverse teams, I have decided to write some considerations about what, as I see, contributes to building an agile team.
Don't focus on the approach
All methodologies are welcome: Kanban, Scrum, Lean, Extreme Programing... What matters is choosing a methodology to which the team is able to adapt well and vice versa. Also, we must not forget to include the client in the decision process.
Some changes to Scrum that are common in our teams are, for example, the duration of sprints (one week, not two), the presence of the project manager at dailies, a longer period between retrospective meetings and not at every sprint, etc.
Tools are important
This may seem contradictory in regards to the Agile Manifesto, but being "important" doesn't mean they are more relevant than the people and their interactions.
Tools like Trello or Jira are extremely useful to keep some order in the development process of a team. For that, it's necessary to know how to work with them and leverage their potential. It doesn't make sense to create a daily burnChart in paper if Jira can provide you with that information.
In short, using the available tools is important and, many times, due to some strict readings of the Manifesto, it can be forgotten.
Team mindset
Having a clear team mindset that is common to everyone is the first step to having a united group more easily open to change. Keeping a team aligned with the process, the client, and the mindset can be a lengthy and tiring procedure that should be adjusted several times.
Some examples of good practices for the alignment of this mindset are one-on-one meetings - which should be done at least once a month with each team member - retrospectives and constant feedback exchange. This policy of conversation and honesty makes it easier for people to be aligned and therefore to reach a common purpose.
We've already talked about methodologies, tools, and team management, so now let's move on to the part that can be overlooked when talking about Agile: code development. The next two items will address it.
Good tests != Lots of tests
An important part of creating durable and high quality software is being able to perform good tests. Tests are a well debated theme in the realm of Agile. In the case of Extreme Programming, the concept of "test driven development" is used; in some adaptations of Kanban, tests are considered part of the development cycle; but in the everyday life of a team, tests are often left behind due to deadlines or bad setups.
Tests can be divided in 2 types:
-
Unit testing - According to the book Pragmatic Unit Testing in Java with JUnit (even though its focus on Java, it contains very broad characteristics), a good unit test must be "ATRIP":
- Automatic;
- Thorough;
- Repeatable;
- Independent;
- Professional / Readable;
- Fast - This feature is not part of the acronym but is also important. The tests should run fast for easier adaptation to problems.
-
Integration testing - Not my favorite, but still I want to highlight some important points:
- Test cases should be separated for a better understanding of the problems;
- A good practice is the detailed documentation of both test cases and test results;
- They must focus on functionalities rather than business logic;
- They must be run at specific stages of the development process, due to the excessive time they take.
Refactoring
No one writes the best code in the world at first try, and even if you could, it can be very volatile and all code improves when refactored. Every developer understands the importance of a refactor, but many times they look at it as if it were a seven-headed beast.
There are several refactor techniques and, in my perspective, not all refactors have to be long. The advice I give to the teams I've worked with is always to approach the problems in small bits, little by little. For this to happen in a lighter way, you need to have a good test base to be able to do minor refactorings. This method makes the code better and more readable every time you do a refactoring, so it becomes a better code in the long run. The time allocated for this is usually negotiated with the client and shows the resulting added value from the process.
More automations = More development time
A good title for this point 6 would be "Continuous Integration", but I want to cover a few more aspects. Having only a seamless integration environment does not provide a team everything that I think is needed to be more agile when it comes to developing, but it's the beginning of it all.
In my perspective, a project with agile continuous integration should have the following characteristics (if applicable):
- Automatic database migrations, especially schema and mandatory data migrations;
- Configurable and easy-to-access data migration system: providing an easy and accessible way for everyone on the team to insert data that was already testes (unitarily) in an integration environment;
- Running tests automatically in a common environment;
- Creating the deploy package in a common and controlled environment;
- Button Deploy: offering an easy way to deploy the latest version of the code that is accessible to the whole team;
- Post-deployment automation: how to run the integration tests.
Of course, for all this to happen, we must have many other changes in the development phase in order to ensure, for example, the idempotency of data migrations. Another aspect that helps in these cases is having a system that can do the builds and deploys, such as Jenkins or Travis CI.
Time
Nothing happens overnight, and if there is one thing that I think I'm faulting as an Agile Coach is seeking more quick results than long-term results. There is nothing wrong with looking for "quick wins", but an agile team has to be built in the long run. Refining a team is a time consuming process. It's not just a single session that will have the power to align the expectation of a team, nor the whole structure of continuous integration will be done within a week. It may never even happen.
In conclusion, these are the seven points that I think are most important in building the foundation of an agile team nowadays.
