We Were Both Right...But I Was Wrong
We Were Both Right...But I Was Wrong
Looking back on an article from 2013 proves just how important it is to have a clear understanding of the Business Sponsor's vision.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
In January 2013, I wrote an article titled "We Were Both Right, But I Was Wrong" and posted it on my personal blog. At the time, Agile adoption had not started to gain momentum ... but some (like my team) were doing development in short iterations. Our approach was to put together some deliverables and focus on them — working directly with the subject matter expert (think Product Owner in today's terms) — providing demos a couple times a week, as development progressed. Sounds kind of Agile-ish, right?
In this article, I plan to note how much of my five-year-old blog post still applies today.
For those who have not read the article, I thought I would provide a short recap...updating roles and responsibilities to match Agile terms.
The Product Owner had a long-term relationship with her boss, the Business Sponsor. They had worked together supporting their line of business for roughly ten years. During those ~2,500 working days, she had gained a strong understanding of the direction and thoughts he provided when setting the path for the next round of features to be added to the application.
The core feature was something referred to as "Fixed CAM" and it handled the computations and business rules about tenants covering the costs of aspects that were not leased by them — but were common to the leasing area. A great example of this can be found in a large shopping facility which may have an open play area for children. The area is in the middle of the shopping complex and is intended to draw people to the facility — knowing there is a place for parents to allow their children to play during a shopping excursion.
The Product Owner and I both had a strong understanding of what Fixed CAM meant and how the process would flow. After a few weeks, we were both happy with how the feature was working in Test. The two of us, along with my supervisor, met with the Business Sponsor to show him our results.
We expected to have a celebration, complete with a round of high-fives (oh wait...fist-bumps to match today's celebratory actions). Instead, what we presented did not match what the Business Sponsor had in mind...at all. Our solution, like his vision, both met the outstanding needs — our approach and design was not at all what he expected.
No fist-bumps. No high-fives. Nothing.
In a world of conflicting priorities and endless task lists, delegation is often a manner where outstanding items can be completed within a reasonable period of time. In the case provided above, the Business Sponsor was getting direction from the C-Level executives, which always seemed to take a higher priority than items such as Fixed CAM. So, he delegated the responsibility to the Product Owner.
This is not a bad decision, if the Business Sponsor is open to releasing the creative control to the Product Owner. In our case, the Business Sponsor wasn't ready to release that level of control. After all, the application was an application he watched spawn from a single feature to a fully functional application running their entire business line.
In this case, the situation could have been resolved if a) the Business Sponsor communicated the need to see updates as the iteration progressed and b) be willing to make time to review and offer suggestions early and often in the development lifecycle. If one (or both) of these items were put into place, there would have been fist-bumps and/or high-fives during the final demonstration of the developed solution.
The good news in my original example is that the components and services created to meet the needs for Fixed CAM did not require any updates to meet the functionality that was expected. In that regard, a great deal of time was not required to make the minor changes being requested by the Business Sponsor.
If the Business Sponsor still wants to maintain some level of ownership toward a given feature set, it is important for Agile teams to keep the Business Sponsor in the loop during development process. Equally important, the Business Sponsor must agree to make time for such events. Failure to do so could wind up with a solution that is not deployed into production, because the result does not match the intended vision.
Have a really great day!
Opinions expressed by DZone contributors are their own.