How Well Do You Resonate With Agile?

Agile as a set of values and principles has now been available for a long enough period that everyone seems to be incorporating it into their practices. However, in order to fully incorporate it, we need to know exactly what Agile stands for, in both letter and spirit. Once we understand Agile, we can figure out whether or not our situation is suitable for Agile. Agile’s underlying philosophy is to leverage human nature as much as possible, just like OOP’s programming was to simulate human interaction with the world. The Agile Manifesto states its four core values as follows:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Objectives/Motivations for Agile Behavior

In order to know if our situation is suitable for Agile or not, we need to understand our motivations.

• Do our client’s expectations frequently change, thus demanding continuous changes in the plan? Often, burnout stems more from just-in-time change requests resulting in context switching, rather than the absolute size of the work backlog
• Are the targeted systems complex, with a lot of uncertainty in terms of business, technical, architectural, and management concerns, or very simple ones? The simple systems are easier to scope, estimate, and deliver and therefore can be implemented without much effort

Why Agile Is (Or Seems) Too Good

Before we even think about taking upon some idea to improve our life, we must be sure that it is as good as it claims to be. The beauty of the Agile approach (in comparison to the Waterfall approach) can be illustrated by applying the Pareto principle (the 80:20 rule), wherein 80% of our tasks are done in 20% of the time allocated. Psychologically, we are driven to work under pressure, and most work is actually done when a deadline approaches. If this seems like your work method, don’t feel bad. Once we have accepted that this is how we work, then we can figure out how to make the best use of it.

Comparison Between Waterfall and Agile Approaches

In the traditional Waterfall approach, the deliverables are given very late, possibly with a half yearly/yearly cycle or more. This provides little chance for either feedback or improvement. In most cases, the business value is already lost by the time it’s delivered. The Agile approach divides the delivery cycle into smaller ones comprising of releases and iterations. This gives ample time to receive early feedback in retrospective sessions, and therefore allow us to work efficiently during a deadline crunch. Make mistakes, but learn from them and move on.

Being Agile vs Doing Agile

Since Agile originated from a perspective of software development, as stated in the Agile Manifesto, we have always taken it in that manner only. However, Agile is not just about software development; it is also how we live out life. When we follow the Agile principles to their core, we are “being” Agile. However, we have built our own processes and practices around these and in doing so, we seem to have lost the spirit behind the actual purpose. We need to inculcate Agile as a mindset, understanding the motivations rather than just “doing” Agile-related activities. The activities are meant for improvement, but once we understand the spirit behind them, we can begin implementing Agile better.

How 3Pillar Breaks the Weakest Link in the Chain

The weakest link is almost always a lack of proper estimation for the tasks to be completed. Once we have this prerequisite, we are able to plan out our lives well enough.

• At 3Pillar, we estimate at a high level to inspire confidence for accomplishing the task. This confidence comes as a result of discussions about the impact analysis and dependencies involved. The initial estimation is continuously updated based on work progress and new challenges found; therefore, everyone is aware of the present state and whether or not any corrective action is required.
• The involvement of the whole team ensures that there are no problems resulting from different people’s variance in perception. With this shared and enhanced knowledge, everyone’s performance improves.
• Cross-cutting concerns (like performance and scalability) and operational aspects (renew, build, release, demo) should also be included in planning, as should be the documentation, however minimal, because it does take effort.
• Along with estimation, another point is to identify the business value associated with each story. At 3Pillar, we need to know what we should do, but we also need to focus on what not to do. Using the MoSCoW prioritization method is a great help to make the best use of our available resources.

This strengthens trust built via delivery skills because the entire work is transparent without hiding anything, even failures. This plays a major role in continuing a healthy and mutually-satisfying relationship, because clients also appreciate their own growth and can accept us as their product partner rather than simple people-on-hire.

Release an Iteration Each Day

Because Agile is all about continuous adaption to change, no specific rules or plans apply for every time and every situation. We must use our experience and knowledge to make judgment calls at all times. That being said, we can have a few generic recommendations, which can help teams remain productive on a continual basis.

• Because a “good start is work half done,” before starting each iteration we conduct a backlog grooming. The whole team brainstorms upon identifying dependencies, known/unknown capabilities, research required, clarifications required from external stakeholders, etc.
• Being an agile team, we accept that everything cannot be known at the start; therefore, we revisit and reinforce our understanding through frequent discussion with product owners, business analysts, and all relevant stakeholders
• By pursuing the unknown/difficult items first, we reduce a lot of risk coming from their non-deterministic nature
• By having some effort reserved for automating certain repetitive items (like vulnerability analysis or regression testing) in the iteration plan, we are able to focus more on business-valued functionality
• Because we work on small chunks of work, we are able to finish quickly and then help other team members via peer review/pair programming. We find comfort in live status updates rather than hiding behind a huge timeline for an epic production. At the end of the day, the team is satisfied with its progress and able to move onto other projects. This approach reduces stress and pursues happiness.
• Working in smaller chunks also enables continuous integration, so everyone is working on the latest versions. This also allows informal peer review because every team member can identify improvements on the go.
• At 3Pillar, we believe in continuously celebrating good work. Team members completing their work earlier, finding improvements, and helping peers are celebrated each week, usually in the form of a round of applause. This can be a big morale boost.

Being Agile as a Product Partner

Being Agile, the 3Pillar team understands that business needs can change at any time; thus, we seek and respect the decision of the Product Owner. In addition to building a trust relationship with the client, being Agile also gives us insights into how the business works, which allows us to gradually contribute suggestions. By trusting and empowering our people to make and adapt decisions for each situation, we have a highly motivated, self-organized team that the client is proud to have as their product partner.