The Art of Product Management
The phrase “There is an art to this job” usually means there is something opaque about it that can’t be easily defined.
By:
I was fortunate to have worked with General Electric in a Service Provider capacity during 1998 through 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 the Digitization, 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 the agile development methodology in 2008 while working with one of our large customers when they decided to pilot certain engagements using agile principles. A quick glance to the agile manifesto and agile core principles intrigued me further to learn more about the key principles of agile methodology.
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 functions from an implementation perspective. In my role where we dealt with thousands of projects and programs across all our clients, often, I would hear about a supplier getting fired for not meeting the triple constraints of project management or the project having major overruns. These constraints would hurt the service provider but more importantly the client with schedule and cost overruns. This mindset that by tying a Service Provider to these triple constraints will somehow protect the client, was simply wrong. In the 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 much 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 and service provider. It was not hard to see what was wrong when RFPs would come for fixed price contracts built around triple-constraints for project management.
That experience back in 2008-2009 made me an avid student of agile development principles… 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 the CRM, the 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 at Work” would aptly apply. I would think of new ideas which me 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 development principles while ensuring that the focus is on “being agile” and not just “doing agile”.This was the beginning of what we called,Pragmatic Agile Development. Pragmatic agile deep rooted in the concept of “just in time, just enough and not just because”.
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 using Agile Scrum framework.
1. New custom development of Web Application
2. SAP Agile Supply Chain implementation for one geographic region
3. Support and maintenance for an agileweb application already in production
While Scrum was the right choice for the 1st, for both 2nd and 3rd projects it was not. For Agile Supply 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 agile methodology. 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 fully live 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 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 Scrum Waterfall as many aspects of the business (not just IT) needs to cut over at the time of deployment, as the entire Value Stream tied to elements of agile Supply Chain.
On the other hand, a Support 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 agile practitioners and not enough coaching time built in the process to have the team learn the Scrum approach to become high performing.
A pragmatic agile 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.
(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 is essential for empathy mapping in agile. 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. Not taking the time to understand and learn the context of the product, people and process will lead to a false start.
Agile 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 in an agile gemba walk.
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 agile practitioners relevant to your situation(see Empathy)
By Pragmatic Agile Development, I am not at all suggesting having a wild-wild west agile or anarchy. It is the contrary. Pragmatic agile is all about doing common sense things that help you achieve agility without compromising on agile core principles e or getting away from agile manifesto values and principles. 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 of agile. Either extreme will result in what I call “fragile” as it will not sustain long term. You need to find that balance where agile working principles 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 pragmatic agile development terms of delivering value early and often is what you need.
In staying true to agile core principles, also understanding how agile 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 Development approach, whether at team level or team-of-teams level as required for enterprises to scale agile. Deploying the principles of scaled agile framework is the ONLY way to deliver value in a complex value delivery process as applicable in the Enterprise world.
Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.
.svg)
