June 30, 2021

Pragmatic Agile - A Quick Foray Into 3 Core Principles

By:

Asim Malik

Background:

I was fortunate to have worked with General Electric in a Service Provider capacity during 1998through 2010 when I was part of Patni Computer Systems, my first employer, where I had the privilege to lead the GE Business Unit from 2007 to 2010, a portfolio of 1500+ employees. This was the time when Jack Welch drove theDigitization, Lean Six Sigma and Change Acceleration Process to its fullest at GE. It is during those years working with various large programs that I had my best learning about process and its impact in accelerating change across an organization (as applied to people, customer facing products, internal facing tools and operations). As part of business development, my role at that time involved responding to RFPs with proposals that included solution envisioning across this very large portfolio. However my involvement in execution of engagement itself was very limited or non-existent. The engagement execution was done by my team, barring occasional project escalations around delivery, people, or process aspects. These proposal responses would generally be fixed price built around the “triple constraints” where we had to estimate the Cost and Schedule to deliver a fixed Scope of the project. (Scope was seemingly fixed but as we would ultimately have to do series of change requests based on the “scope creeps”). It was a constant point argument with the client which at times we won and at times the client.

While I had heard about agile in the past, I got my first exposure to Agile as a development methodology in 2008 while working with one of our large customers when they decided to pilot certain engagements using Agile methodology. A quick glance to agile manifesto and core principles intrigued me further to learn more about methodology.

My foray into Agile

The more I learned about Scrum and Kanban, it felt like common sense; and I questioned why we are not doing more of this. I started to see the logic in the challenges that I had experienced with the legacy way of executing Software Engineering projects, specifically those where the product vision and need might be clear at a high level but there was lack of clarity in terms of detailed feature/functions from implementation perspective. In my role where we dealt with 1000s of projects/programs across all our clients, often, I would hear about a supplier getting fired for not meeting the “triple constraints” or the project having major overruns hurting the Service Provider but more importantly hurting the Client with schedule and cost overruns. This mindset that by tying aService Provider to these “triple constraints” will somehow protect the client, was simply wrong. In case of overruns, the impact to the client is perhaps more than the Service Provider. While it may save some cost by having a fixed price, the cost of lost opportunity by not having their product launched in time, was an impact multiple X larger than the cost saved. Or they are impacted by a series of change requests that created bigger cost overruns than the ROI for the project itself. How about when the client by chance got the Service Provider entangled into the “triple constraints contract web” by having them absorb the overrun, it made the negative spiral even deeper with quality suffering even further as the Service Provider faced loss or eroded margins. This is made even worse by the resulting end of trust and relationship between the Client andService Provider. It was not hard to see what was wrong when RFPs would come for Fixed Price contracts built around triple-constraints.

That experience back in 2008-2009 made me an avid student of the agile mindset… less about the word “Agile” but more about being agile in a complex software engineering effort which is deeply dependent on knowledge workers (be it Business teams or Technology teams) and where “change is the only constant”as market and customer demands change. I was no exception to this adage. I played the role of Business Stakeholder and Product Manager for the CRM system that we used for managing our sales process and revenue forecast. Every time theCRM IT Team would bring a new set of screens and process for review for requirements provided by me earlier, the tag line GE used then “Imagination atWork” would aptly apply. I would think of new ideas which I and my colleagues were confident would help in our Sales Process even more, but my IT team frowned as we had them locked into “triple constraints”. Going back to my learning from GE days where Lean Six Sigma was at the core of their big transformation initiatives. Agile borrows a leaf from Lean where the focus is on Flow (of Value). When I say, “being agile vs. doing Agile”, I mean our ability to pivot quickly based on learning through early experiments so you can deliver the most value adding features to the client in the shortest possible path without compromising on quality.

So, when Neeraj Gupta (founder and then CEO of Systems In Motion which is now known as Nexient)reached out to discuss the idea of launching the company that would bring high quality US based software engineering team to its client, it was a no brainer that the foundation of the teams must be deep in Agile methods while ensuring that the focus is on “being agile” and not just “doing Agile”.This was the beginning of what we called as Pragmatic Agile. It was deep rooted in the concept of “just in time, just enough and not just because”.

Pragmatic Agile:

Going back to the example that I shared about piloting some Agile engagements at one of my large customers, this aspect could not have been clearer. Three Service Providers were engaged for pilots to determine 1 or 2 that would be their “Agile”partners. Only problem: each were given different kinds of projects while usingAgile Scrum framework.

1.    New custom development of Web Application

2.    SAP Supply Chain implementation for one geographic region

3.    Support and maintenance for a web application already in production

While Scrum was the right choice for the 1st, for both 2nd and 3rd it was not. For aSupply Chain implementation, context is important. You cannot have a releasable product with a 2–3 week sprint as the entire Value Stream needs to be ready to roll with SAP. It is a major change in business process not to mention the many integrations required to embed the ERP solution internally with various systems in the company before you can go-live fully. Perhaps Scrum-Fall would have made sense. Implementing an ERP or BPM is a great opportunity to “Simplify or Streamline” the business process before it is digitized or automated. Scrum methodology would work well where supply chain and related configurations/workflows/Bill of Material (BOM) configuration etc. (in other words “Business Requirements”. are identified, and the customization or configuration changes (in other words “Implementation”) are done in 2–3 week sprints. This provides an opportunity to the business and operations stakeholders to contribute to and see the progress in an iterative and incremental fashion.However, the rollout could be a major release like in Waterfall as many aspects of the business (not just IT) needs to cutover at the time of deployment(entire Value Stream tied to Supply Chain process).

On the other hand, aSupport and Maintenance engagement does not have the predictability of defining scope for each sprint upfront. Requests can come from multiple stakeholders with prioritization conflicts. There Kanban is a better option than Scrum.

The resulting findings from the 2nd and 3rd pilot projects did not meet the success criteria because the methodology was not right for the type of work. While the 1st engagement was moderately successful, it was not a slam dunk as it lacked true practitioners and not enough coaching time built in the process to have the team learn the Scrum approach to become high performing.

A pragmatic approach would have begun by identifying the right approach for the type of work included in each pilot and perhaps providing a much better outcome.

So, what is Pragmatic Agile? There are 3 core aspects of Pragmatic Agile:

·      Empathy: (the psychological identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another).

How many times we have heard the phrase “One size does not fit all”!! Nowhere else is this phrase more applicable than agile engagements and it is deep rooted in Empathy. Having empathy for people, product, and process. You need to meet the team where it is in terms of its agile maturity. You need to understand the context of the product (business driver, customer need etc.) and type of work that this entails. You also need to understand that a team that has been doing something for a while may be resistant to large scale changes or it could be a newly formed team that has yet to go through the storming, norming phase.

Not taking the time to understand and learn the context of the product, people and process will lead to a false start.

·      “Gemba” experience i.e., Practitioners:

Practitioners that have “been there and done that” make a big difference when it comes to success with agile engagements. Whether it is the Agile coach teaching the team how to fish, the product owner creating and refining the product backlog; the scrum master enforcing the process non-negotiables, the architect building the architecture runway, the software and quality engineers building the software and automating the testing, the DevOps engineer creating the CI/CD pipeline. Having at least a few roles in the team that have done this and know the pitfalls and learning will help the team succeed.

Here at Nexient that is what we bring to our clients through our Full Product Teams that combines Consulting and Engineering to create a cross-functional team of practitioners relevant to your situation(see Empathy)

·      Staying true to core principles (Just in time,just enough and not just because)

By Pragmatic, I am not at all suggesting having a wild-wild west agile or anarchy. It is the contrary. Pragmatic is all about doing common sense things that helps you achieve agility without compromising on the core principles of agile or getting away from agile manifesto. Remember“being agile vs. doing Agile”. You cannot be dogmatic taking a line-by-line textbook approach or not following any of the core principles. Either extreme will result into what I call as “fragile” as it will not sustain for long term.You need to find that balance where the practices of agile are aligned with the agile mindset to produce sustainable and predictable value delivery. When process is forced “just because”, that is the beginning of the end of the process. Finding that happy medium that makes the team achieve agility in terms of delivering value early and often is what you need.

In the staying true to the core principles, also understanding how the principles work together is important. I see many orgs and people grab one or two things like stand-ups, and sprints, but still keep the vast majority of their broken process.

Nexient’s Agile Transformation Approach is built keeping in mind this Pragmatic Agile approach, whether at team level or team-of-teams level as required for enterprises to scale agile. Scaling agile is the ONLY way to deliver value in a complex value delivery process as applicable in theEnterprise world.  

I will share the details of this agile transformation framework in my next blog post named “A Practitioners Guide to Agile Transformation.“

The Latest from Nexient

We're hiring

Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.

Join Our Team