My Agile Day

Real Stories From Real-World Agile Teams

Agile Enterprise

/

Product Ownership by committee?

At USCIS, I came across this simple construct of mapping an Agile team to two overlapping sub-teams of “Value Team” and “Delivery Team”, first coined by Ahmed Sidky (ref: video).

The Value Team is a construct WITHIN the agile team to augment the role of the PO – to facilitate the management of budgeting, governance, delivery, and prioritization of the backlog. It’s a VERY lightweight model i.e. no impact on the way Delivery/Development team works and brings more rigor to the way the PO/Business/PMO side of the team operates.

Please note, the model still upholds the PO as the ultimate owner of the Product Backlog. It just provides a construct to form a “stakeholder representative group” around the PO to facilitate his/her work.

I have taken a shot at mapping the 5-year-old talk graphically for easier consumption. Take these illustrations with a grain of salt. They need to be peer-reviewed.

Do you see this value in reviving this undervalued model of the value team/delivery team to map out your agile team?

My Agile Day – Value Team, Delivery TeamDownload

/

What is a “single point of failure” for your agile team?

You are moving to the cloud with your product. The architect is making sure all web servers are load balanced, containers orchestrated, elastic, automatic fan out, fan in, automatic fail over across multiple regions and Availability Zones. Database is getting clustered, replicated. The whole nine yards. The architect, rightfully, has sold the vision of an ops environment that cannot have a single point of failure. You have given him the full authority to execute on that vision. In a big enterprise, there is very little consensus on things. This is one of the few things that everyone agrees on. That, if you are serious about continuity of your business, in your architecture, there can be no single point of failure. You agree with it. Good for you.

Now consider this. Away from the vigilant eyes of the DevSecOps’ monitors and scanners, away from the cloud and the humming servers, you have a product team working away on the next big thing. In the team, you have Subject Matter Experts (developers, network engineers you name it) who work in silos. Now, imagine this. In the team, there is one SME, John or Jane, who owns a significant component or data pipeline and has solely worked on that for several years. S/he has so much domain knowledge about the piece s/he owns that it is not funny anymore. What happens when John or Jane goes on vacation? Any work on that component stops. Your project manager becomes extra religious for those few days, praying for zero hot fixes in that piece of code, for no one else in the team can pick up the John or Jane’s burden of work. The poor guy (or gal) cannot even fall sick in peace. Oh, and what happens if they just decide to quit? Would you consider John or Jane as a single point of failure?

If your team is going through the rigors of Agile Transformation, here is one more thing to watch out for. Collectively take some time out with the team and identify extent of this silo-ization. Then come up with a plan to organically cross pollinate some of the domain knowledge. Your team will, eventually, thank you for this. In the coming months (years?), we would cover some of the strategies we may use to break down these silos.

/

Are you paying off your tech debt? Or, do you want your business to pay for it?

“Let’s sneak in some tech debt work while doing some actual Epics.”. I am paraphrasing here. But, that’s pretty much what the tech lead said to me.

“Why?”, I asked.

“‘Cause, the leadership does not see any business value in doing this type of lowly maintenance type work.”, he replied.

“But that feels wrong, doesn’t it? Do they know that is today just-a-lowly-maintenance work, left alone can become tomorrows priority-zero hotfix. Do your leaders see value in keeping the lights on?”, I said in my head.

I looked back on my developer days and completely empathized with my compatriot. Because of their invisible nature, developers, DevOps and I.T. folks often fight a continuous uphill battle to justify time spent on “lowly” O&M type work or addressing non-functional requirements. In retrospect, the very term “non-functional requirement” that is used to bundle attributes like performance, availability, auditability etc. sounds derogatory. As if, meeting any of those attributes does not serve any “function”. Yes, I’ve a chip on my shoulder.

To the business owners and enterprise leadership of the world. Of course, if your tech team is spending 70% of their waking hours doing Operations and Maintenance type work and fighting fires, something is amiss. (That’s yet another blog post for yet another day). But, if your Agile Teams are not given the freedom to be transparent about their technical debts and the mandate to make continuous payment, for which you are prepared to give them credit, your business stands in line to fall prey when the debt is out for collection.

Does your Agile Team have the mandate to do what is right?