From Agile Teams to PODs

From Agile Teams to PODs

 

“In place of allocating people to project, allocate project to the team”.  This paradigm shift in approach is being advised and advocated by agile experts for all good reasons.

Many companies are adopting this approach; I personally have been part of the team working on this approach in a multinational company.  We adopted it well in our sub-function. Here is my learning (based on failure and success) on how we did it and challenges

The idea here is to form full stake teams, allocate them the project, when the project ends, don’t dismantle the team, rather maintain them (as you maintain people on the bench) and then allocate new project to the same team.

This shift is difficult but also essential.  It’s difficult to get away from the traditional approach to team formation based on project need; new approach suggests to form teams (cross-functional self-sufficient) upfront and then allocates any project to them.   We prefer to call them Pod.

Most asked question by both internal stakeholders as well as the customer is “what full form of Pod is?” Well, here Pod is not an abbreviation; in the current context, it’s about completion in itself (like iPod), it’s a complete unit capable of doing-all-that-needs for a successful project delivery.

Why Pod –

  1. Speed – Team formation takes its own time; often it takes 6 – 12 weeks, to form a team and make then productive. From team to Pod approach, enable one to shorten this time period significantly, that resulting into huge lag up and speed to overall delivery.

 

  1. Fast changing technologies/tools – now companies and professional are not only coping with ever-changing business requirements, but also fast and regular changes in technology stack & toolsets. So forming teams based on people expertise on certain skill may soon become redundant; Need of the hour is forming the cross-functional team (Pod) able to fast adapt to changes.

 

  1. Best suited for Agile – Agile delivery is a team sport; to win in any team game, need to think & plan everything from the team standpoint and avoid counting on individual contribution. Pod culture enables the organization to approach every decision from the team perspective.

 

  1. Scaling and de-scaling is new normal – fast ramp up and ramp down is more frequent now, growing popularity of scaling frameworks are testimony o this fact. Pod culture enables scaling / de-scaling with an ease.

 

Challenges and what it takes to overcome the – biggest challenge here is the complete shift from traditional people management, now it’s no longer people management, its team (pod) management, be it staffing, bench, trainer or appraisal.

  • Change in staffing approach – allocate team not individual
  • Bench management – from people on the bench to pods-on-bench Or Standby Pods
  • Appraisal system need to pivot accordingly – focus on individual performance to team performance and reward to teams
  • Change in training approach/content – focus shift from competency building of individual to the workshop led training programs to build team’s competency on required skills and impart culture & mindset to happily and quickly adopt changes in technology, tools and engineering practices.

 

How we did it – In my organization – we practice following

  • Maintain standby Pods (something like the team on the bench) – by form Pods (cross-functional full stake team) – based on work projection (demand)
  • Pods undergo “Pod readiness workshop” – a specially designed training cum workshop to impart all required skills and culture/mindset
  • Allocate project to Pod
  • When the current project ends, allocate them the new project – don’t change team composition (until someone left the organization or organization have to let someone go). Let’s team learn and adjust to project context (from the skill set and approach standpoint) and adopt
  • A shared Pod (team of subject matter experts like the Agile coach, DevOps expert, Architecture and tool experts etc.) supports all pods to adopt best engineering practices as well as new technologies, tool, approach etc.
  • In case of no project or project in waiting stage, treat Pods as standby pods and utilize time in competency building and POCs

From my experience and out customer experience (satisfaction) I can happily claim that we did it right (including countless fast failures, experiment, and pivots) and now we are getting the good result.  Adoption of “Allocate project to team Or Pod culture” is worth every penny spend.

 

Next article to Read –

Bot inside Pod – Future on software development:   In next article, I will explain our experiment on adding a bot in the Pod, and we are not the only one; this is soon a new normal.

Leave a Reply