Comment (0)

Venky (Enterprise Architect): “Hey dude, Agile isn’t working for us and we are wasting so much time in ceremonies with no fruitful outcomes.”

Ramesh (Agile Practitioner): “Well, let us start with the objective. What are you trying to do?”

Venky: “For our upcoming release, we are trying to add a new technical capability which we haven’t done before. We like to research and explore the feasibility before full-fledged implementation.”

Ramesh: “Basically, you are building architecture runway and there are lot of unknowns…”

Venky: “Yes, we are following Scrum currently and it’s quite challenging to plan and execute leveraging Scrum.”

Ramesh: “Because…?”

Venky: “We are dealing with unknowns and we don’t even know how many uncertainties there are. As I said before, this is new, and we are prototyping and it’s not easy to plan and size the effort even at a high level”

Ramesh: “So Scrum is not working for you. Also, your requirement is evolving and rapidly changing as you progress and discover the unknowns.”

Venky: “That’s right”

Ramesh: “Agility is all about uncovering better ways of developing software through four core values. So, it’s not that Agile is not working for you. We need to find the right Agile methodology that fulfills our needs.”

Venky: “Spot on, let’s do it.”

This conversation led us to explore various methodologies before we decided on eXtreme Programming (XP).

We started with the knowledge matrix to understand where we are currently so that we can choose what works best for us.

Illustrating the above with some examples:

Known Knowns

Let us take an example of chatbot implementation in an iteration. There may be several technical challenges and complexities during the execution. But all requirements can be clarified, and the team has enough artifacts available in platforms like StackOverflow to proceed.

Scrum may suit this better since the Product Owner can explain the needs, and the Scrum Master can help with the removal of blockers and enables the team while the team self-manages the work.

The team can leverage daily stand-ups and demos to understand the progress and take the early feedback.

Known Unknowns

An example would be a dependency on other Scrum teams and other business units. We are aware of the dependencies and when they need to be resolved by, but we are not sure about how the work is progressing in the unit we’re dependent on.

Frameworks like Scaled Agile may work well where the cadence and alignment are the primary objectives. Synchronization through program increment planning, Scrum of Scrum, and demos enables transparency of unknowns.

Unknown Knowns

Operations and support functions fall into this bucket where we need to react as quickly as possible based on customer issues. We know the nature of work and steps, but we don’t know the frequency of inflow and complexity involved.

Kanban is ideal here since the methodology helps in scheduling the work just in time. Over time, Kanban helps in converting unknowns into measurables through lead time and cycle time.

Unknown Unknowns

Our requirement of research fits into this category where the resulting work may not be just the software product also domain knowledge and building blocks for architecture runway.

The challenge here is the rapid change of requirements and need for some development along with exploration to discover the unforeseen implementation problems. The spikes may not be very effective here. Extreme programming comes to our rescue in addressing these challenges.

Extreme programming is straightforward with just two roles

• Customer (in our scenario it’s Venky): responsible for making all decisions regarding the architecture runway 

• Developer: responsible for realizing requirements identified by the Customer.

There are two additional optional roles, the tracker, to keep track of progress and identify areas for improvement, and the coach, to mentor the team in XP practices.

We have taken advantage of the XP approach by setting goals on a daily (and hourly for some cases) basis with the objective of teams being able to ramp up quickly and identify implementation approaches. The plan is to assess at the end of the time box and change the course of direction accordingly. The team felt the methodology is simple and developer-friendly since the core values of XP: Communication, Simplicity, Feedback, Courage and Respect, are preferred by everyone.

The pair programming concept was leveraged where the developers participated enthusiastically not just within one group, but across the entire team. Even before the target, the team geared up and built confidence on the implementation approach. The informal methods encouraged by XP are liked by everyone since innovation and respecting each other’s’ ideas are core DNA of any development team. The team was able to size the work better with increased confidence.

XP practices as summarized below are simple yet powerful. The inherent advantages we felt are not just the productivity and increased collaboration, but also the simplicity yielded and a built-in quality that everyone strives for.

In summary, it’s not about a comparison of different methodologies; you must choose the right one that works for the team effectively. While every Agile methodology has its own merits, the knowledge matrix helps in identifying the suitable one. XP’s core strengths are fine scale feedback at every milestone, continuous processes that enable the customer, shared understanding within the team and customer, and maintaining the programmer’s welfare through a sustainable pace.

Comment (0)