Whatisagile

WHAT IS THIS AGILE THING

Agile is the soup of the day.  For that, I have an urge to describe some of it’s characteristics. The desire to talk about it comes from several experiences I have had lately with many who are so excited about it and trying to embrace it, but in the end, they aren’t becoming… Well…  Agile.

I will talk about some of the characteristics. Some of the misconceptions I have observed around it. This agile fever that sprint by sprint is catching up like wild fire on many environments. But, that sadly for some, it is not having the best symptoms and side effects. Bad results that come from the wrong organizational culture, ignorance or from the way it is being embraced.

In general, I will try to describe the philosophy of it. Explained to my understanding of it’s key characteristics. Hopefully you will notice if in your workplace it is being embraced with all it’s implications. You don’t want to be the one claiming that you are agile just because you use a Kanban board, do sprints and daily standups, while doing everything else  pretty much in the same way (true story!).

Sorry but no talks about performance today. First we need to really understand agile.

WHAT IS AGILE (TO ME).

There are so many ways that I could describe Agile. But I will try to approach it by what I feel and see it is. Experts may try to lynch me for what I am about to write. But please Mr. Expert, if you want to add something and contribute to my and other’s education I will be more than glad to write a retraction with accurate information based on the comments.

What I will write below will not be rules. They are just guidelines of what agile must be. Since being agile is more a journey than a destination. We have no fixed list of attributes. A question exemplifies it better. After how many times going to the gym are you fit and buffed? There is no precise number, but at some point and after acquiring more characteristics, suddenly some will tell you: “Hey you look like the terminator!”

Below are some of the most important characteristics that I personally think makes you truly agile.

FREQUENT ITERATIONS, RELEASES AND FEEDBACK

You may be doing sprints in a bi weekly fashion. But that is not what makes you agile. Well, not only a sprinted work fashion by itself.

To have a true agile project, you should be pushing small new features to your customer as often as possible. In my experience, big bulky one time releases imply you are doing mini waterfalls. All aimed at that big release.

Agile projects can have an end date, but the ability to play with it should be available way before the end date. It should be available pretty much right away after the start of the project,. Starting with a few features. Even just a skeleton, but something to mold and release sprint by sprint.

The benefit here is that as soon as you have code out, your testers, developers and especially the users can give feedback. Youi will receive several types of feedback. Usability, complaints, functionality, performance and usefulness (utilization). This feedback must not come only from people, but from automated mechanisms that you should have in place to report back to you even before the people does.

SMALL GROUPS OF SPECIALIST POLYMATHS

The señor Jeff Bezos stated that an optimal agile team should be well fed with two large pizzas. A team of normal eating habits. I could easily chug those two pizzas myself. But what the señor Bezos meant was teams with around 5 to 10 people, not their eating capabilities.

This small number of people creates an incredible synergy of accountability and cooperation. As a small team, if one person starts to lag, it will drag the whole team.

The reason for the lag can be varied. But the team will have to step up, distribute work and let someone else help. Everyone should be able to pick up someone else’s work. Even with specialists on the team, they should be able to work on the other areas. The days for the monolingual member are over. There is still a need for specialists. But they must understand hello, hola, bon jour, konnichiwa, guten tag… and so on.

A specialized dev should know automation and database. The scrum master should understand coding and release calls and so on. ‘T-shaped’ is how they are known. The body of the T is their specialty and the head has the other things they can speak and work. Another new type of person is called the E shaped. They have three big legs of knowledge and a common knowledge body. You don’t have to know it all, but at least try to be good at a few more things.

Because of this, the tester role requires to have some other knowledge than just automation, manual or QA strategies. The QA role, engineer role and even the performance tester role become blurry lines in a group of people who all should know general QA with a well round everything QA engineer.

ADAPTATIVE WORK WITHOUT LEFTOVERS

Another component for the true agile team/project is to assign work, learn and adapt sprint by sprint.  As you move forward, you will learn if your prediction of time for a task was right. Don’t worry if it was bananas at the beginning. You should get better at it sprint by sprint. In the end, you are the one saying how long or much of an effort it will be.

This eases the team on not biting more than they can chew. But as well forecasts how much can be done from the remaining work. At the same time leaving space for unforeseen tasks.

The goal is to complete new features and keep moving forward. Technical debt is a spooky term in agile. It also has to be kept in balance. When new features are added, bugs tend to appear, automation tends to break, builds start to fail, and the general entropy principle will keep bringing chaos.

With this constant chaos appearance, the technical debt will start to creep up and in. Another team duty will be to balance the urge for new feature creation with the constant discipline of keeping technical debt at bay. Even if you to get often a greasy steak and ice cream, you should always have some balance with veggies and fruit. Otherwise you will get in trouble. Too much ice cream can derail your team’s sprint by sprint feature releasing capabilities.

To clean the chaos constantly was not possible on the old ways. A key characteristic of truly being agile, don’t let the chaos pile until you have it up to your neck.

CONCLUSSION

Agile is a huge mindset change in the IT world. Several were used to the old waterfall methodologies. They are having a hard time letting go the old mindsets. It is crucial that project managers and leaders with traditional mindsets let go many concepts regarding the old ways. Forget about it and LET IT GO.

The practice consists of small frequent releases to the product. The final user should be able to use parts of the product right away and the team should get all types of feedback from such release. ‘Big-ass once-in-ages releases’ feel to me totally anti agile.

The teams are small with multidisciplinary people. Having a specialist that can’t do decently a few other tricks might not be the best elements for an agile team. The scrum master or Project lead should definitely be the biggest polymath.

Workload deficiencies, defects and technical debt should be found and fixed as soon and as automatically as possible. The urge for creation and the need for maintenance must be balanced. In sufficient smart ways that constant change is manageable, chaos should be handled without losing speed in creating new features.

And last, Agile is not the new efficiency path to deliver projects. Traditional PM’s and leaders must let go those old mindsets. Agile is not a more efficient way of doing things. It is a more effective way of doing things. If it is  applied well. Since the product generated will be usable while the team keeps working on it, everyone can leverage the use of the product by the clients, to improve, change direction if needed and deliver the best tailor suited solution.

So for the old ways… Let it go, let it goooooOOO!!