Software delivery teams - landscape that can be creative

What I have learned over the years working with different delivery methods and modern "frameworks"?

As a delivery team, your main responsibility is to deliver the value for your business and rapidly. With any delivery methodology or framework (scrum, SAFe etc.) you are bound to get some rules laid out for you and a lot of it can be in fact limiting or a distraction for the team for the main ask - to deliver! I have also seen teams getting more conservative about estimations and quality of the product as well in some cases. So how do we play a little more offensively to not compromise with the central idea of delivery teams - deliver!

Sail through, don't sprint!

Continuous refinement should be the goal

With more focus on planning the time, teams often do more time planning than refining. I think the heart of any consistently successfully delivering team is how well they understand the problem that they are solving and if we are rushing to fill up the iteration plans and tune to the demanding metrics (commitment to delivery, commitment to completion, velocity, throughput) then refinement takes the backstage. "Let's not get into weeds" is becoming an alarming antipattern in delivery teams. Refinements are the heart of successful execution on the teams. If we refine better we define it better and the teams define the problems well, they crush it in execution - bring clarity through continuous smaller effective refinements meetings. Good old day long planning meetings are counterproductive, filled with mundane chats and processes requiring almost impractical attention spans. Instead, focus on refining twice or thrice every week in an hour long focused meetings which will help build strong requirements for the team.

Focus on pursuing milestones instead of planning for an allotted time

With all the modern agile frameworks, I experienced the focus is more on planning the work for an interval of time which puts team think more about what can we fit in the time span instead of thinking about the mission as a group of small and large milestones. Especially when you are building a new product.

Out of all the agile frameworks, I find Kanban more exciting to keep the mindset of the team on small goals instead of focus on time. With all that I have said here might make you think I am saying screw the time and commitment but that's not the case - I think it's about focus of your mindset, if you are focused on the goals and creating clarity every step, the speed of execution will follow. Clarity boosts confidence in execution. I call it sailing instead of sprinting, where you are heading towards certain goals by a consistent velocity instead of trying to run at a high speed for a short duration, which is tiring, monotonous and counterproductive in fresh product development.

Identify the characters in your team

Givers - These are the people you will bank on when you need mentoring, handholding others. These are typically the thought leaders on your team. You would also want to make sure to get the very best out of these people - your job as a leader is to identify givers and make sure they are positioned to be high performers.

Matchers - These are the people who will be a bit transactional in nature and generally won't commit to something they can't see through clearly. Quite self-driven and can be used for precision with time and efforts.

Takers - Watch out for these characters and probably needs most of your attention, because they can slow down the momentum - they are struggling with skills or experience. Coach them and continuously evaluate strategies to make them independent.

Captains - ownership over consensus - build leaders

I have found good success with this method in building a culture of ownership over the consensus model, which is overly prescribed in most of the agile frameworks. This does not mean there is no buy in from others, but the focus is on having one person to drive the conversations, collaborate and call the decisions on a certain problem.

What is a captain?

A captain is a single point of contact for an important delivery activity in the team.

Feature Design Captain - this person will own the decisions on the solutions we are building, working with architects of that module, providing feedback on what could be done better. So this engineer will be part of the design of a feature from the word go and will be a close ally of the architect and product owner for that feature.

Deployment Captain - this person will have an account of all the deployment activities planned and communicated with a checklist of sort. Most of the modern tech stack involves lots of small deploys and can be crazy coordination. I have found that "if everyone owns everything, then no one owns nothing". With this, you also have this person keeping track of the list and build up that shape over the period of a feature life cycle.

This cultivates a culture of leadership and ownership, which brings the best out of people when they feel in the driver's seat. Some people may not enjoy it as well, and you need to be conscious of working with it as well.

Investing in building tools which can make your team's life easier for supporting and building the product

Build tools and provisions which can help you support and administer the product better. It is often an afterthought to create capabilities which will help us see the state of production better. For example, we rarely invest in buying or building tools like glassbox, dynatrace and building home-grown custom tools to help to deal with a complicated product. It's important we invest in tools that empower us as an engineering team, which in turn helps our clients with efficiency and superior experience when they need support on the days our software is not doing what it's supposed to do.

"Team time" :)

I work with a very diverse engineering team, in the modern cosmopolitan environments we are going to be in this situation more often than not where a team can be made up of multiple nationalities, religions, sex, races, cultures and skills. Still, I found my current team a lot more diverse than a typical engineering team in industry - just take a look -

An Indian team leader, A Chinese QA automation engineer, A Kenyan software engineer, An American software engineer, A Bangladeshi software engineer, An American product owner.

We all grew up in completely different geopolitical areas, cultures, spoke different languages, and yet we are here and are expected to be an effective professional team. With this scenario, I felt, it is important to understand people beyond their resumes and profession. We started doing a team building activity called "team time" where one of us would host this meeting at a time and use this time go over his/her life so far and this activity has helped me on different teams by now. So what is the team time?

• Talk about yourself, your background, family a bit, whatever you can comfortably share ?
• Share some things from your past – achievements, trips you have been to, hobbies you care for!
• End with a fun team game ??
• Since it is during the lunchtime, feel free to eat your lunch during this time ??

This indeed has helped me with team building (way better than some random team activities we often read about) and getting the team closer because there are aspects of a person you can never see in a dry, strict professional setup and this was an opportunity to see the person beyond work - we came across instances where we were completely unaware of some of the passions and interests our colleagues had, certainly shading a good light different sides of it.

This was helpful in breaking the awkward silences, lack of initiative and prospered a culture of confidence where people were not afraid of failing in front of the team or asking for assistance publicly because they are free to be vulnerable here - that's how families stick together, and professional teams can fall apart.

So... this is the way I went a little off the road to try and test some methods that worked for me and my delivery teams - a bit unorthodox at times but effective - it is in a way portrays a creative side of the job. I am thankful to my leaders who let me run with independence during this journey, and also the great people I worked with on the teams. I hope you will find your own way and if you do it any differently then please share it with me.

Thanks,

Umesh