Agile with no Refactoring is no Agile

Let’s say, you have a task to draw an elephant trunk.

You are very excited about the elephant trunk project. It’s going to be cool, it’s going to be an Agile project, of course. To play it safe, we can always modify the trunk, change a color, a size, a style. We will present the result to a customer ASAP to capture the feedback, to make changes if it’s required. It’s gonna be fine!

Well… We are on a Sprint 1. And everybody is happy. Still.

On Sprint hmmm … 3 customer comes to talk to you. They are extremely happy about the trunk. BUT …  some guys in IT reminded them about … tusks. Tusks need to be attached to the trunk if it’s possible. And we understand that it wasn’t in the initial scope, but trunk without tusks?!  It doesn’t make any sense! So it’s clear a new business requirement. Let’s make it happened!

Well, again, this picture is a very optimistic illustration, because in a real life we don’t know for sure, how those tusks are attached to the trunk. There some options, you know.

Sprint 10.

We introduced the concept of legs. We haven’t got an elephant body just yet and we have no idea, how it’s going to be connected with the trunk and tusks ( if it will be connected somehow)

Sprint 23. 

Yes, you could guess from the beginning what it’s gonna be at the end.

Whole elephant!

But it was all about Agile, not about guessing.

You should be very happy if you’ve got something similar to what’s described  on this picture…

Because,  in my world, probably,  you’ve got something like this:

It’s the nature of Agile projects: at the start we don’t know what it’s going to be at the end. Just approximately.

To keep your solution clean and solid during  the Agile project you need refactoring. In other words, you have to keep reviewing and redesigning and redeveloping, retesting  your system while project requirements and scope are changing.

Google it. There are many good articles and books regarding this topic.

“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

Attention!  If you have no code CRM solution, keep reading.

According to Wiki, “Web app development is the creation of application programs that reside on remote servers and are delivered to the user’s device over the Internet.”

There is nothing about coding here. If you have 5 CRM functional consultants  modifying the application program, using “no coding” configuration, it’s still a development. So keep reading.

So,  in your Agile CRM project,  you definitely need to think about refactoring  if:

1. You are on a Sprint 1+ and haven’t thought about this yet.
2. You have multiple CRM developers ( functionals/ programmers) working on the same part of the system.
3. Your requirements for the functionality of the system were extended or changed multiple times since Sprint 1.
4. You have multiple workflows are running on the same entity.
5. You have workflows and business rules triggered on the same entity.
6. You have a plugin and a workflow triggered for the same entity.
7. You have a plugin,  a workflow and a javascript triggered for the same entity.
8.  You have a plugin,  a workflow, javascript and a business rule triggered for the same entity.
9. You have multiple javascript functions on the same form and going to add one extra.
10.  You have syncronous and asynchronous workflows running for the same entity (order matters)
11. You feel your solution become too “crowdy”. Trust yourself. Do refactoring!
12.  You love CRM add-ons and got them installed on top of your solution.
13. [Many other scenarios ]
    

    You just need to review your solution from time to time.

Just one more thing: it’s much easier to set customer expectations at the beginning of the project, introducing refactoring as a part of the process. But it’s never too late to do so. It’s not like we all want to, we just have to. Because it has a great impact on a quality of the end product.