Is Agile limited to Development Projects?

Can we practice Agile in a maintenance project?
Can we follow Agile in executing a migration project?
Can we use Agile in …?

Is Agile limited to Development projects - 3E Software SolutionsIs Agile limited to only development projects?

What drives us to adapt to a new process or alter an existing process? It is always this golden objective – Quality. Different projects carry different Quality criteria. Before trying to find an answer for “How do we deliver Quality in this project?” we need to answer “What does Quality mean for this project?”

Let me try to illustrate this with an example of how we implemented Agile in a Production Support project.

*A quick background of the project:

  • The project was about handling the business-critical Production Support for a telecom client. This was handled offshore completely.
  • The customer’s business was tied up with different Service Partners to provide end-to-end service to their customers. Taking this to technical terminology, it was all integrated on an SOA based architecture.
  • Often there were service failures due to various Technical and Operational reasons and our job was to analyze those failures and handle them offline.

So, what was Quality meant for this project?

  • Reliability –As we worked on the production issues, it was a MUST that our solutions were highly Reliable.
  • Better and Faster –It was DESIRED that we provide continuously better and faster solutions, considering the huge customer-base of our customer.
  • Timely & Consistent communication with the business users –We had to work with the onsite team, working on the other side of the globe. So, our communication with them had to be –
    – Timely – Delays, due to timezone differences, should be minimized so that end-customer concerns are addressed at the soonest. Not a typical requirement in Development projects.
    –  Consistent – Our communication with the onsite team should always reflect that either we know something or don’t know something as a Team but not as Individuals. It is highly DESIRED from business point of view.
  • Continuous Learning of the System: It was a complex system and so it was DESIRED that we learn the system better and better as we go dealing with various issues.
  • Customer satisfaction through End-Customer satisfaction: “Our customer will be happy, if their customers are happy”. This is the simple business rule that we always respected.

*So, how did we implement Agile here?

The daily Scrum meetings played a major role here and this is how we tuned our Scrum approach in dealing the issues reported by the end-customers.

  • What is New (Either we didn’t handle this before or this is slightly different from what we handled before)?

Can we handle this ourselves? If so, who is the best person to handle or help? Or, do we need to approach the onsite team? (Providing ‘Reliable’ solutions)
This is towards the “Reliability” criteria.

  • Are there any Bulk (High in number) and Repeated (being seen more often) issues?

This is towards identifying the need for building new tools or modifying the existing tools (Automated or Semi-Automated) to meet “Better and Faster” criteria.

  • Any escalations?

Business SLAs take priority over having a perfect solution (‘End-Customer satisfaction’).

— Timely communication with the onsite team and continuous learning of the customer’s business were the by-products of these discussions.

— It also helped us address the Single-Point-Of-Failures (SPOF here is Knowledge being confined to individuals). SPOF would, in general, have more impact in a Production environment than in a Development environment.

— We never discussed the issues that were routine and they were far off the Scrum meetings. Our meetings intended to be meaningful and action-oriented. We didn’t make them daily status meetings. Our team was enabled to take care of the routine issues by themselves.

What is meant to be conveyed through this example?

— Challenges are different for different projects. Some projects would be more about ‘What to Implement’ whereas some projects would be more about ‘How to Implement’?

— Our project was more about ‘What to Implement’ than ‘How to Implement’. I must say that technologically it was not so challenging but we were constantly identifying and implementing the tools(Java/J2EE and PL/SQL based – just to add) that create value for the customer’s business. So, it was more of a business challenge.

— There was no concept of continuous delivery, iterative development, early feedback etc. in this particular customer engagement. From a different sense, our solutions were reaching to the customer on a daily basis (unlike in a typical Development project).

— To state the fact, it took us some time to figure out what exactly were the expectations and the Quality criteria. Every project would see this phase, particularly when your team is handling a new type of project. Some conscious experiments and trial-and-errors are required to get on to the right track.

The subtle message that is intended to be conveyed is – ‘Work on identifying your Quality goals and customize your practices to achieve those goals’.

After thought:

  • What are the Quality objectives of your project? How is it different from the other projects that you executed?
  • How can you apply the tools(practices) available for the job-in-hand? What works for you, and what does not work for you?

This blog first appeared in “Beyond your Code” on 10 Aug, 2014, authored by Faizulla Shaik, Founder, 3E Software Solutions.

Contact Us

Recent Posts