Engaging for Agile Engagement – A Framework For Success

In today’s day and age, ‘Agile’ and ‘Technology’ go hand-in-hand. No matter how widely these terms are used in correlation, many businesses often miss the point in understanding Agile Development. Sadly, many confine it to the ‘two-week delivery sprints’ alone. But in fact, the framework of an Agile contract demands much more.

Srijan’s Agile journey started in 2010, and we’ve come across circumstances wherein the business owners willing to engage in projects, enquire for ‘fixed-cost’ and ‘fixed-outcomes’ during the initial  RFP or negotiation phase itself. This is anything, but a sure-shot recipe for disaster. And if a project is deployed under such circumstances, the quality and effectiveness of outcome will not only be hard to imagine but also would leave behind a professionally strained relationship between the business and the vendor.

But these do not conclude that Agile methods are a road to nowhere. Instead, if religiously and accurately, implemented and followed, Agile methods truly lead towards a path of success. However, it is still oblivious to many that the dynamics of the intricate framework varies for each solution provider and the seeker. Any successful Agile engagement demands the following framework for success:

1. Value Discovery Phase
   It is no brainer that more than 60% of development firms require a discovery phase. What varies is the length of the phase. Higher the complexity of the project, greater should be the time devoted to this phase. But what actually sets apart the experience of development is the consideration of the discovery of a project as a project in itself.
   Under circumstances where the vendor and partner have clearly defined the definitions of deliverables and outcomes, the probability of a better deliverable is higher. This should ideally be treated as a paid consulting assignment. The inability to take this phase seriously leads to loads of hiccups during the implementation phase.
2. Freehand and Faith
   While valuing discovery phase is an important aspect, there are a few other considerations that are to be considered. Both partner and vendor should understand that there are some attributes that may not be unearthed during the discovery phase. So, ensuring a freehand and trusting the association plays a major role. At the same time, a fair idea of budget and time should be considered as well.  With this breathability, it is easier to work and this in turn aids to higher efficiency and product quality.
3. A Good Product Owner
   Ensuring a good enough product owner, is another ballgame. The one in charge is required to have certain traits and skills, like being business savvy or a great communicator.  Understanding the business, market, and the customers is very important when the power of decision making lies with you. Only with such acumen, can a person clearly communicate the aspiration from the product. Also, the PO is responsible for motivating the team with a clear and enriching goal. He should also own the project backlog and be prepared during the discovery phase and during the course of development.
4. Build Robust Teams
   An often ignored yet important aspect is the staffing and coordination. Many a time, the business or vendor’s team is understaffed or lacks people with relevant skill and talent.  So, it is essential to maintain internal teams at both businesses’ and vendor’s end. And at the same time, also ensure that the coordination is good enough so that they behave as a one-whole team.
   When staffing, care should be taken that the term ‘developers’ in Agile teams does not simply refer to ‘coders’. It is more of a cross-functional team setup which ensures that the project is delivered efficiently without facing any lack of resources for a particular task.
5. Openness to Embrace New Avenues
   Any amount of effort and dedication can turn out to be of no use, if openness has not been practised and appreciated. As John Wooden says, “Be observing constantly. Stay open-minded. Be eager to learn and improve”, a similar outlook should be applied to Agile Development as well.
   An open environment encourages transparency, team-building, and rules out the chances of failure due to prejudices – a major behaviour issue. This also encourages equal involvement of the stakeholders and thus greatly reduces the chances of conflict due to sprint backlogs.  At the same time, the ability to adapt and absorb newer methodologies might even speed up the development speed and deliver a better and more effective solution.
6. Banking on a Strong CI/CD Environment
   While the definitions are pretty clear and concise, the inclusion of this philosophy isn’t something that we stumble upon quite often. One major reason for this is the challenges that are faced in building a strong CI/CD pipeline. It demands of investments of time, tools, and workforce is hard to keep up with.
   However, if done correctly the benefits reaped are too pricey to be ignored – Faster software iterations, satisfied customers, and automated testing to name a few. Moreover, a solid CI/CD environment would support a more stable code, reduced manual errors and then certainly fewer code hiccups.
7. Picking the right tools for a sustainable process
   When the idea of Agile development was adopted by businesses and vendors, it led to a lot of chaos. Instead of bringing along the benefits, it proved to be a bane for many. However, to regulate this chaos, while letting your developers rein-free, it is important to implement strong processes via tools.
   Now the idea is not to impose any strict rules and regulation, rather help the developers manage themselves and collaborate seamlessly to deliver results that might be even beyond their expectations. Choice certainly varies from project to project, while some might pick tools that help track the stages of development, others might feel its fit to pick one that is essentially tailored to fit the Agile development.
8. Necessitating Hardening Sprints
   Expecting that the first code written would be completely bug free, would be like expecting snow in summer – the possibilities are slim. It is rather a known fact that even a two-week development cycle will have bugs. Therefore, to ensure that the process is smoother henceforth, hardening sprints are a necessity.
   During this the QAs would focus on end-to-end testing rather than on specific features. The developers could utilize it to fix regression defects if any. This ensures a step forward towards a stable build.  
9. Backup the Development with Support Phase
   Planning a support phase in the development lifecycle is important. It is better to go for a ‘builder fixes the issues’ approach rather than depending on a different team to take care of it. To be carried out efficiently, it is important this is spread over 2 stages: (i) tracking and prioritizing and (ii) owning the stack.
   While the first stage is tracking the bugs and making these visible to the team, the second stage involves trying and prepping your team to take charge of much of the stack. To ensure a well-informed and detailed bug history, a bug-tracking system could be taken into place, and then prioritizing what needs to be fixed first. And when it comes to taking charge of the stack, this is where a fully cross-functional team would excel the business.

If duly taken into account and acted upon, your engagement too can reap the benefits of Agile development. The road blockers can be greatly reduced and taken to the advantages side and would rapidly reduce the instances of code-break.  

Therefore, engaging with a partner whose focus is delivering outstanding business outcomes, would mutually agree to settle on such a framework when getting into the engagement. However, those willing to get a project on fixed cost and fixed outcomes are better to walk away from. Digital transformation engagements do not require such partners. If considered for an engagement without such a framework, the barriers would be too high to jump off.