Agile is a good methodology to get things done. I buy the philosophies behind it. I think it can be applied in many areas, not just at work, not just at building software. To me, Agile is a tool, a meant to help me get the job done. In software development, I have heard people talking about these beautiful things.

1. Agile team is self-organized
2. Deliver working software (features) every sprint.
3. No upfront design.
4. Hmm, do we need an Architect? Do we need a Team Leader?
5. Embrace changes
6. ….

Many fantasy things. When I first heard about them, I thought

Wow. That’s so cool. Everything looks perfect. Hmm, if everything is perfect, then there is a hidden problem.

Unfortunately, I felt something was missing. Later on (at least up til now), I have found many. Basically, all those things are correct if, and only if, you have a perfect Agile Team. In reality, we all know that human is the root of everything. And having a good team is, well, just a dream. We have to face that truth. Do not try to assume we have a good team at hand. It just does not work that way.

Let’s take a small area from that fantasy: Add a new feature.

The Story

Good morning SWAT Agile Team, in the sprint we will deliver a new cool feature: Delete (soft delete) user. The feature will allow the administrator to delete a user. Users are marked as deleted but not removed from the data storage.

With these facts

• The system has 10 of features built in.
• There are features associated with User: Create, Edit, Manage Order, …

The wishes

• The new feature will not break the existing ones.
• Reuse the code as much as possible.

The untold facts (which will be discovered when writing user stories for the feature)

• Some existing features will be impacted. Cannot delete users having orders. Cannot edit a deleted user.
• Code Quality: Cyclomatic Complexity (CC) must be under control.
• …

If you have been in such a situation, please share how you will handle it.

The Problem

Developers, Testers when joining a so-called agile team, how much have you known about Agile? When a project starts, developers are sold a plan of getting small deliveries, increasements. No upfront design. No architecture. Hey! That is the waterfall, folks, an Agile-men said.

There are many requirement meetings, discussions, … Everything goes well as planned. The team has a clear set of user stories. Estimation is done. Agile is on set.

Good! Ladies and gentlemen, where do we write the first line of code? Serious. Where do we write? Not mention how. To make thing super clear, where/how do you write the first line of production code? Just to opt out the Unit Test code.

A harder question. How do we code in such a way that in the middle of the sprint (or next sprints) the requirements change? How do we embrace the changes?

As the system grows, the harder to add a new feature.

The Solution

Hell No. I do not have a solution. However, I do have some proposals.

Infrastructure and Architecture

No matter what fields we are in, to embrace changes, to stand still, we need support from Infrastructure and Architecture. Without a good foundation, we just build a house on the sand. A single wind can blow it away.

We need an architect. We need a good, stable foundation. If there has not, we must build one.

We need an architect to define system boundaries, to separate the logics into proper concepts, to decide the architectural style, to decide design patterns. A good architect will limit the impact when implementing a new feature or modifying an existing one.

For legacy systems, a good architect can help decouple the dependencies, create boundaries. It is much harder than in the green field projects. But it can be done and can improve over the time. Otherwise, every single change is a risk.

Agile Mindset

People are the core of everything. Members decide the success or failure of the project, of the team. What is their mindset? We bring Agile in to increase the flexibility, to embrace the changes, … None of them will work if members think

1. I must have a clear requirement to start with.
2. My job is just coding or testing
3. Who cares about the design. I just need to code this function. I change only a small part of the code.
4. Hey, I just add a new method for me. Isolated. No breaking change.
5. …

Still the old mindset. I am not saying that mindset is wrong. But it does not fit the new environment either.

I would suggest the first thing we should do is to train our member; to get them adapt with the new mindset; to install the agile mindset into their subconscious mind. It is not easy, not at all.

A few things we can train developers

Architectural Thinking

There is no clear definition of Architect. However, everyone can think architecturally. Every developer, paid for a job, must be able to write code. They should not stop there. Instead, ask these questions

1. Can I read my code after 3, 6 months? How about a year?
2. How many ways can break the code?
3. How easy to change? What if clients want to change XXX?
4. Is it easy to understand?

What kinds of architectures that support well to embrace changes?

It is a long road. It is worth a try. Oh, wait a minute! Which means we need an architect. Yes, Sir! We need an architect or one having architecture skill in the team.

There is an argument saying that the architect will setup the system, build the framework, make some training sessions, and finally handle over to the team. Good luck! Soon enough, the framework will break. Things will tear apart. Why? Because of the lack of quality of maintainers, the development team.

Coaching

We cannot change someone else mindset. It does not work that way. However, we can show them the right mindset. We can consistently tell them the right mindset. Coaching approach might work. That is you do not train or tell someone what to do. No! They decide what they want to do and how they will do it. We, the team leader (I hope you have one), will

1. Give some suggestions, show the direction
2. Encourage
3. Motivate

Will It Work?

I do not know. But if your current team does not work as you expected, maybe you should try it. There is no silver bullet. Try and Improve!

In discussions, every leader seems to know that people are the most important asset. However, when it comes to daily work, the reality might not the same. How much do we care the most important asset? What have we done to improve that asset?

Agile or waterfall, no matter what methodologies we use, we are a team works on a mission. We want to get that mission done and we want to be proud of what we have done.

Should we need an Architect in the team? Yes. Definitely. Then help everyone think as an architect.

Should we train our people? Yes. Definitely.

To win the war, you need good soldiers!

Happy Sunday! Thank for your reading.