Real Stories From Real-World Agile Teams
A real life story of how a team is overcoming deep silos in their product and system and are strategically on a path to cross train themselves, just so, any one in the team can (a) go on vacation, (b) have a baby, or (c) win lotteries, without breaking a sweat.
Or, read, are dependencies killing your organization?
This is what nightmares are made of. Product A, by Team A uses a stored procedure in Product B’s database. Product B is maintained by Team B. Team B updates the stored procedure and tests only their products that depend on the stored procedure. Tests pass. Changes roll out. All hell breaks lose for Product A.
What’s wrong with the process? Teams dependencies need to be managed around APIs with clear SLAs. In a large organization, identifying those dependencies across teams and products and replace them methodically with APIs is a hairy task. The code debt is the size of US Student Debt of 15T. No less scary. But, paying it off may as well make a difference between long time survivability of the the product and your organization.
If there are frictions between your development teams, due to dependencies, this may be one way to resolve that.
Anti-patterns seen in the organization at team, program, portfolio level.
Build the right thing
Build the thing right
Built the thing fast
Funding and Budgeting (PMO stuff)
Be Happy
Story: Have you ever seen a Team closing unfinished stories and opening new stories? and do other counter-lean shenanigans just so the sprint stats will look good.
Root Causes:
Possible Remedy:
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?
The CoPs need to take ownership of their agenda. Typically, as Agile Changemakers, we may provide some seed topics, with the CoP taking ownership of the list, free to add/remove any.
For example, there is a list of seed topics for CoP of Scrum Masters, courtesy of Steve Moubrey.
I love this guerilla episode on making of a sunglass comparison app from the Nordstrom Innovation Lab.
If you are thinking of building “something new”, a new app or enterprise solution, or revamping your legacy system, this is for you. Often times you hear buzzwords like design-thinking, user-centric design etc. Rarely we have the opportunity to witness a good example of it first hand. Well, here it is. A rather “extreme” example of agile product development. User-focused, value-driven, incremental release in a rapid iteration.
What stood out:
So, next time we are building “something new”, lets make an effort to open our hearts to our users – the “agile way”. Otherwise, we may end up with a solution that’s looking for a problem and not the other way around.
“But .. but, they are just doing busy work!!!” blurted out the division head, in charge of overseeing many small teams within a massive IT house. The team, in question, was one of several we were actively working with. We knew them to be sincere, hard working and yes, skilled in their art. Not one that would just “pretend” to be busy. So, a little perplexed, we probed deeper. Apparently, there were projects assigned to the team that has not moved for a while and the Chief had no idea what the team was busy with. It turned out, the team was spending 80% of their time in “boring and routine” operations and maintenance tasks. Tasks that were not in the radar of the division head.
Every development team I have worked in and worked with does “some” operations and maintenance (O&M) type work. Well, for some teams, like the team in the story above, the regular O&M work may eat up majority of their time, especially in the absence of automation. If you keep the boring O&M work you do in the closet, your stakeholders will always wonder what-in-the-world you are doing with all the time and money and resources. Your speed of delivering value to your stakeholders will always lag behind their expectation.
Avoid being accused of just doing “busy work”. Make work visible, all of it. Go even further. Keep an account of the types of work you do and the percent split that is delivering value to your stakeholders vs that is deemed mere O&M.
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.
“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?
A while back, after two decades of making software as a developer and later as a solution architect, I swallowed the blue (or, red) pill and morphed into an Agile Change Agent. My first engagement was as one of the three coaches in charge of a rather hefty Enterprise Agile Transformation effort. There were about 300 members, in 50 teams, spread over 70 locations. Agile transformation was one of the checkboxes in this US$200 million contract and it was showing. First few months, I was naturally drinking from a firehose. We were busy rolling out Agile Mindset training, Team and Project chartering sessions, 1-1 coaching and mentoring for the teams as they gingerly embraced the Agile practices. Iterate, inspect and adapt, we preached and they practiced. “But, how do we measure our own progress? How do we, as agile change makers, inspect and adapt? Are we above the laws of agility so-to-speak?” I foolishly asked one day. I got graciously slapped on my hand for asking the “boo question” and for the time being, I almost convinced myself that, like a mother’s love for the child, admittedly not everything can be measured. However, coming fresh off the board from a delivery-centric, data-driven vocation of software engineering, it pricked my conscience to no end. And the irony is, this whole “Agile movement” was started off the efforts of some software engineers.
I was not at a point to question the sanity of my decision of becoming an Agile Change Maker. The potential for creating positive impact is just too great. However, let’s just say, I was close.
That is until I came across Comparative Agility and the likes making the rounds in the Agile Community, that restored my faith. In case you have not checked it out yet, Comparative Agility is a Continuous Improvement and Agile Assessment Platform. It allows teams and Agile change-agents to gauge the measure of team cohesion and effectiveness and the level of adoption of various Agile and DevOps practices through a series of Likert surveys. The best part of it, the “platform” not only lets you feast on your own teams result but lets you get an understanding of where your organization stands in comparison to others in your industry. Full disclosure: I have recently joined the Advisory Team of Comparative Agility (Thank you CA team :). Since then, I have seen several other similar approaches, some custom, in-house ones as well. Bottom line is, as Agile Change Agents, our success is tied to the success of the teams we work with. Establishing baselines around the agility of the team not only helps the team gauge where they are, but it also helps us measure the efficacy of our own engagement.
Convinced, I am in the right(eous) track demanding from ourselves “some measure” of success for our effort, I am incorporating similar, but albeit light-weight Likert Surveys, in all the value driven efforts. So far, no one has complained.
So, to walk the walk, it behooves on the Agile Change Agents to establish some measurable, value-driven metrics around our transformation effort. And the sooner the better.
How do you assess your and your team’s Agility?
“When you see her, tell her, this kind of behavior is not going to be tolerated any more.” – an almost verbatim quote from an otherwise cool team lead, let’s call her Pi, when a team mate, let’s call her Beta, did not show up for the daily stand up (a conference call), two days in a row and without notice. Pi was justifiably upset at this indiscretion. She was trying to instill some discipline in a completely distributed team. And Beta was pouring cold water on that effort. But is this the best way to make the team conscious of the new world order? Does threating a member of the team at her (or, his) absence do any good to the team morale?
Let the Team, as a collective, be responsible for their behavior and let them decide what they want to do to one of their team mates who’s fails to uphold the standard. We are all adults here :). At least on paper. How different would it be if Pi asks “Okay, this is the second day we are missing Beta. First, I need a volunteer to make sure she’s alive and well. Next, as a team, what do you think we should do to someone who ditches us like this without notice in future?” Take it to the team to create their own high mark and see what happens.
In the Agile Mindset workshop that my mentor used to teach, he would start the class by setting some ground rules of behavior and let the class, as a team, come up with the rules. The day-long class had hourly 10 minute breaks. And, one of the “rules” was to figure out what a team member would do for being late coming in after the break. The “punishments” varied from push-ups to donating money to charity to singing out loud. And it worked every time. Well, almost every time. I saw it fail only once and the culprit was made to sing and the class paid the price together, if you know what I mean 🙂
What do you do to hold your team accountable to itself?
