Let’s face it there are a lot of challenges when it comes to standing up Agile teams, so pointing out only two blockers may seem like a drop in the bucket. Yet these two impediments come up over and over again in my courses and conversations with other Agile practitioners.
1. Securing a sufficient amount of funded work for the teams to perform is often the largest initial obstacle we face.
This falls firmly into the category I like to call “Duh” but for some reason, it always seems to get overlooked. The transformation lead or manager must gain insight into the work planned for the teams in question. You will need to know the amount of work, confirm the funding model, and verify that the work aligns with the team or teams being stood up.
The amount of work required may shift from one organization to another but typically it should provide between five months and two years’ worth of output. The wide variance in work volume depends on several factors including organizational scale, Agile maturity, and the goals of the transformation. If your organization is large, has program levels in place, existing mature teams, and the goal is to increase capacity then the two-year backlog makes sense. If, on the other hand, your company is a startup with little Agile experience looking to capitalize on a new product the shorter five-month backlog might be more appropriate.
Confirming that the work is funded is highly dependent upon the organization’s funding model. Many traditional companies still have some sort of legacy project funding model that is used to fund Agile work at the portfolio level. Other companies have moved to a more forward-thinking community funding model and some have even gone so far as to establish a team funding model. The model doesn’t really matter as long as you can get confirmation that the work has funding in place.
This represents the value your organization has front-loaded into the backlog of the team(s) and should be transparent to all the stakeholders including the team members.
Join our Pro Tips Pipeline
Agile Pro Tips respects your privacy. Read our privacy policy on how we handle your personal information.
2. Confirming persistent team member allocation is far more difficult than it should be.
It baffles me that Line of Business (LOB) partners, who are often vocal in their support of moving to Agile, typically can’t stomach permanently assigning employees to Agile teams. “Well, I can’t spare anyone on my team… they’re too valuable.” Too valuable to do the work you have been tasked with delivering?!?
It is the job of the transformation lead or manager to firmly, but gently, communicate that Agile teams need to be staffed with team members who are permanently assigned to their role. Sure, contracts end and people still get hit by buses on occasion but let’s not set the teams up for failure by rigging the roster to include people we have no intention of devoting to the team.
Simply put, the team’s ability to deliver value suffers when you have a change in team members and that truly is the bottom line. This is a cellular structure after all and if you change or remove the nucleus or mitochondria even temporarily the cell will suffer or worse. This also applies to “special projects” where team members are temporarily called away or subject to reduced availability.
Conveying the significance of this to the business and leadership stakeholders is crucial to getting them to commit resources one hundred percent to Agile teams.
Addressing these two issues early puts you well on the path toward launching successful teams. There are other challenges obviously but these are true team killers that must be solved early in the process.
9 thoughts on “Standing up Agile Teams: 2 Blockers & How to Remove Them”
When the team has no option but to lose a member for a period of time . Do they get to have a collective agreement on who should go help or do they just have to suffer?
Yannick,
Great question! If a team member needs to take some leave or falls ill there should be a plan in place for how to handle the absence. Unfortunately, team members also get pulled away from teams from time to time by leadership. This should be avoided whenever possible but if I am being honest, it happens more often than it should especially when team members have a specific skill that is in demand.
So, teams should have their plan for handling these situations built into their team agreement. That document serves as a code of conduct and a set of guiding rules established by the team for handling situations they are likely to encounter.
Options for your example include having each team member skill share with at least one other person on the team so that they have an understudy in place ready to pick up the slack in the case of an absence or leave. Another possibility is to have the workload the team commits to reduced proportionally based on how many team members remain available to complete the work. For example: if a development team of 5 loses one teammate for a Sprint they would commit to 4/5ths of their normal workload until the team member returns.
I hope that helps!
Cheers,
Joe
Very true and great article. Is legacy tooling an obstacle to the funding I wonder, or is this more organizational? Looking forward to your next article.
Jenner,
That’s an interesting thought. Making sure the Scrum or Kanban teams have funded work in their backlog is step one, but this would be impacted if the tools or environments needed to be upgraded to complete the work. This is often problematic as we all want to work with the latest and greatest tools, but sometimes and for some applications it is actually a necessity.
So, to answer your question: Yes, ideally the tools, platform, and framework needed by the teams to complete their work should be included in the funding model. However, as you point out more often than not this expense is “absorbed” by the organization as a “cost of doing business.”
After all, good tools pay for themselves if they save us time and effort in regard to repetitive tasks and procedures.
Great question!
Cheers,
Joe
I have been a part of a team where we brainstorm great ideas. Unfortunately nothing moves forward because we do not have the funding. It is critical that you first know what your funding amount is before you try to chase rainbows.
Yes, the brainstorming should take place to answer the question, “How can we best deliver this new feature?” after the larger body of work is funded.
When I worked for a telecom company, the one issue that I constantly dealt with was that my technical resources kept changing. This was a huge problem because I would have to review the project scope every time there was a change. This not only frustrated me but the client.
Development teams should be set up as persistent teams to minimize this, but even with persistent teams, there are challenges. Using contract employees and not converting them to full-time increases turnover and knowledge loss. However, the worst examples of this occur when companies shoot themselves in the foot by shoulder tapping developers to work on short-term special efforts or constantly reassign engineers to “rebalance” teams.
there are a few things that should be in place prior to funding the Agile model. Everyone should be on board as a team to plan out and utilize the tools for a successful project