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
- Alignment of product with portfolio not well understood
- Skip product chartering
- Not listening to the customer / stakeholder voice over own voice.
- Not doing “why this, why now?” prioritization before taking on work
- Not having a clear, measurable hypothesis before picking up major work.
- Not completing the “learning cycle”
Build the thing right
- Pushing code-debt down the road, be reactive, rather than pro-active.
- Deep silo is a major issue. Major subsystems owned by a single person, sometimes resistant to relinquish control.
- Code not in repo.
- Database scripts are out of repository.
- Database and Code are not versioned together.
- Change management not in place. No discipline around release of versioned software to different environments, to facilitate roll back, roll forward, bug tracking etc.
Built the thing fast
- Ditch retrospective.
- Skip team chartering
- Output tracking over Outcome tracking at the leadership level
- Lack of output tracking at the team level
Funding and Budgeting (PMO stuff)
- Output, not outcome, driven funding, commitment
- Year-long Commitment around old recommendations (70/70 items in recommendations done 3 years back will be delivered.)
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.
- Output is more incentivized than outcome?
- Team feels a lack of safety.
- MIA Agile Mentoring, Agile Mindset.
- Transparency and Safety goes hand in hand. We cannot expect a team to be honest and transparent if that means severe reprimands. Let’s create a net around safety before demanding honesty and transparency. And that imperative goes up the value chain.
- Teams will falter. Teams will fail. Can we replace the reprimands with a sense of genuine curiosity and learning mindset – to figure out what went wrong and learn from the mistakes?
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.
- Using Metrics
- Effective Retrospectives
- Managing dependencies
- Estimating Techniques
- Leadership Skills
- Facilitation techniques
- Best Practices
- Using Data points
- Preparing for Sprint Planning
- Tips and Tricks for Refinement
- Helping teams achieve commitments
- Encouraging teams to update tool
- Daily Standup
- Templates used in ceremonies
- Identifying and navigating risks
- Training Needs?
- Presentation skills
“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 will identify your biggest time sinks and therefore your biggest candidates for automation. “Look, John’s spending 50% of the time each sprint backing up 500 TB data. Let’s do something about it.”
- Your stakeholder will understand and may even empathize.
- The stats you have of your work type split will help you justify the need for additional resources.