Is your Agile Team the right "shape"?
4,019
Published 2020-09-30
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/webinars/p-and-p?ref=y…
= = = = = = = = = = = =
Does your team have all the right roles, and the correct number of people in each role?
If so, count yourself lucky.
Many teams have to make-do-and-mend.
I call them "real-world" teams. And I have a lot of time for "real-world" teams.
-------------------
146. Is your Agile Team the right "shape"?
#DevelopmentThatPays
What is the “shape” of your Agile team Does it have all the right roles With exactly the right number of people in each role If so, congratulations, you have a “text-book” team. But the chances are good that Your team does not have all the right roles OR does not have the right number of people Your team is what I like to call a “real world” team. And I have a lot of time for real-world teams. Not too long ago, I worked in a development team in a startup. A reasonably sized team 1 designer 2 data scientists 3 backend 3 front end 1 product owner And that was it. Oh. Did I mention that the team was doing Scrum If you’re familiar with Scrum, you’ll know immediately that the team was missing a role. A rather key role. The role of Scrum Master. And as time went on, the more we felt that the lack of a Scrum Master was holding us back. Eventually, the lead developers - there were two of them - got together to recommend hiring a Scrum Master. The request… perhaps you can guess, was DENIED! We had no choice but to carry on with a team that we felt was the “wrong shape”. And I suppose at this point we should talk about what is the “correct” team structure. The answer to that question depends on which “flavour” of agile you’re doing. If you’re “doing Kanban” - or even Scrumban - …. Not very prescriptive …. Unless you know something that I don’t. But if you’re doing Scrum, well… The Scrum Guide is pretty clear about the make-up of an Scrum team: To be clear: Exactly one Scrum Master Exactly one Product Owner And exactly one development team. The team I was just talking about lacked the Scrum Master role, And a Scrum purist might say that we should have found a way to get one. Now here’s the thing: Thinking of the non-Team aspects of Scrum: the events, the artifacts. Perhaps you look at the list and thought, oops, we haven’t done a Retrospective for a while. Fixing that is as simple as… holding a retrospective. You could do it today. There’s certainly no need to dispatch two lead developers to get budget allocated for it. The retrospective - like everything else on this list - is entirely under your control. … teams control. But when it comes to team structure… it's a different story. Certainly, you’re not going to fix things today. And in most cases, you’re not going to fix things for free. In many cases - I’d say the majority of cases - you’re not going to fix it at all. You’re stuck with your “real world” team. And do you know what, I have a lot of time for real-world teams. I have a lot of time for what I like to refer to “real-world agile” teams. Perhaps - like the team I talked about early - your missing the Scrum master role. Or perhaps you have a project manager (rather than a product owner). Or more than one product owner. Or more that one project manager! None of these situations is ideal. Teams that aren’t quite the right shape. But are determined to get things done anyway. So I’m curious. What’s the shape of you agile team Is it “text-book” Or it … shall we say… more interesting Tell me about the shape of your “real-world” team in the comments below.
• Is your Agile Team the right "shape"…
All Comments (20)
-
Very interested to hear about the shape of YOUR Agile team. Chime in below.
-
2 POs, 0 SM, 2 QA, 1UX, 13 Dev..... moving from Scrum that didn't work to well with out a scrum master to Kanban.... appreciate your guidance through this channel.
-
1 Product Owner, 1 Business Analyst, 1 Scrum Master (me, and I am also the technical project manager responsible for planning with the client and delivering solutions to the client), all based in UK; 4 testers responsible for functional testing all based in Mauritius; 5 'developers', 1 senior in Dublin, 4 (including 1 team leader, 50% assigned) in Belarus. We run Scrum and manage to run all Scrum events, though tend to do many show and tell sessions throughout the Sprint, rather than a single Sprint Review. But the organisation is still very naive about agile software development and how to get the best from that way of working. The team continually fails to meet its Sprint goals, usually requiring 2 Sprints to achieve what was estimated for 1 Sprint, mainly due to the fact that dev and test work in waterfall fashion rather than collaboratively. This is partly due to the type of technology (heavy financial processing back-end), lack of ability to think in agile fashion about how the value can be co-created and tested between Dev and QA: usual responses are "It has to all be coded before it can be delivered", "We cannot test a little part on its own", "We can't test a calculation is correct unless it is seen on the screen too". Product Owner adds things to the Sprint without consulting the team, because 'It has to be done in this release'. We have problems relating requirements as stories with work to be done. So JIRA becomes a task planning forum rather than a true Product Backlog. The organisation spreads a very lean capacity pool across a wide number of clients and projects, so I will find out often through a small comment in the Daily Scrum that somebody is also working another project. This makes commitment to the client very difficult.
-
My current agile team has a few real world twists: RWT1: The dev team has a unique character on it, a business systems analyst (BSA), whose work is different from the rest of the dev team's. RWT2: The scrum master does not have a dev background (aside from writing Apple BASIC code in high school), but came from the help desk / analytics side of IT prior. The scrum master knows agile, but can't really coach the team technically. RWT3: Instead of all working together in the same office, the team is based out of several different offices, in different time zones in the US RWT3a: We can meet with web conferencing, but we have to keep the cameras off, due to network bandwidth issues.
-
Can Mixed Roles work? Here are some of the scenarios I have witnessed and experienced: the Scrum Master who was also the only tester (me) in the team; the PO who was also a tester on another team, with its own PO; a scrum master covering two teams working on different products; the line manager as the PO; the PO is also the Scrum Master; the project manager covering many teams is also the scrum master for those teams.
-
My current team is 1 PO, 1 SM/Developer (me), 2-3 Developers. I get about 1 day's work per sprint to take care of SM tasks.
-
Depends on how many projects you have, small businesses don't have the luxury of hundreds of thousands of euros in a single project, so they have to do a lot of small projects and give a warranty of two years on it for bugs and stuff, you often get a one or two teams jumping around either developing or putting out fires, pure scrum is not feasible. So we do try and get a product owner, team leader and a devops for multiple dev teams, it's stressful but it is what it is.
-
Our real world team: - A Product Owner - Role is to always be available for questions about the product and help drive new and existing work - A QA - Role is to work with the PO and the Dev's during planning and ensure the end goal of a work item is agreed on. They then test the work item (card on a board) achieves that goal after development. They are the gate keeper to production. They often ensure some form of automation test exists for each work item. That may be a unit test, integration test, or even a browser test that they have written during (or before) testing. - 2 or 3 Developers - Role is to work with the QA and PO during planning and add the technical input to work items. They complete the technical work to the agreed goal (the value we want to give to the user). They then work with QA to ensure the work goes smoothly through to production. The work isn't done until it's in front of a user. Daily stand ups - Rotate who runs the stand up and walk the board backwards starting from any production/release issues. At the end of the stand up they nominate tomorrows Scrum master. This is a very brief description and some roles have more responsibility outside of the team (like the PO). When we know what's going on then work flows extremely well. The problems appear when we have urgent last minute issues and the work items lack real thought (usually because of the urgency)
-
Do you have a video explaining difference between Product Manager and Product Owner?
-
I am currently SM for 3 teams where 50% of the teammembers are member of all 3 teams. I have talked with management about bringing tasks to teams, instead of forming a team around each little project. My conclusion so far is, that the company structure does not support what I want. In management they are very keen about maintaining all the traditional roles and the belief is Scrum and Agile is something added as a "Process" on top of the traditional structure that makes things goes faster. Still long way to go ....
-
The roles are there, but the team size grows and splits accordingly. I do play the role of "scrum master" or "kanban coach" but I am also part of the development team and I make product decisions as well. In a sense the roles are more nebulous, in that that they appear as we work. We still have 2-week sprints an have retrospectives. Our planning sessions are a little less formal now because reality is to make commitments on a technology platform that is vast and large where not one single person can understand all the components from coding to building to deployment is setting up people to fail if we want to meet business targets and having more conservative commitments will make us miss business targets. Not to mention we still have to "keep the lights on" during production. However, the mutual respect is still there, like I said the role assignments are nebulous, but they do form as people gain more confidence. As they grow in confidence, the lead/owner role may split off on its own team. Also when the realization that it is too much occurs we merge back teams as needed. However, I think having a scrum master/kanban coach that allows this reconfiguration to work along with the sprint retro to assess how things are. One note, our retros are not limited to the specific team, we actually allow people from other teams to join in and sometimes contribute (specifically to discuss about re-merging or redistributing teams)
-
I have a data team and it consists of 2 Product Owners, 1 Scrum Master, 5 developers, and 2 testers. It's working good for us now but seems like we have too much work and we have to continue shift our priorities according to our business partners needs.
-
We got all "Textbook" roles in place, but the Real World, we added a Project Manager, a Project Director, Two Scrum Masters, all to manage one team but with 4 parallel sprints. Unfortunately, the Scrum Events is a luxury thing, as the work load, timeline, and backlog did not helped much in providing us time to do the Scrum Events.
-
Would love your thoughts (@DevelopmentThatPays) on my scrum team consisting now of 12 Developers, 1 Scrum Master, 1 PO (myself) and 1 Program Manager. I find it very difficult to work in this environment as daily standups exceed the targeted 15-30 minutes; Sprint planning takes 3+ hours and I think that some of the developers are getting "lost' as keeping track of 12 is a herding cats problem to the fullest. Thanks in advance and great video!
-
Most of my real world teams don't have a PO... Well, let me rephrase that: they often officially do have one person with that hat, but it's often someone on the customer side (B2B) who knows the "domain", but they are not trained in how to be a PO on a Scrum project....
-
Product-Owner + Scrum Master/Delivery-lead + 4 Developers
-
New Team. Available Artifacts before we onboarded were: Feature List with Waterfall deadlines. 1st to 3rd weeks: 1 Product Manager that does nothing, 1 SysAd (also 0.5 developer), 1 Architect (Technical Direction), 1 UX, 1 Mobile Dev and me (dev). 4th - 6th week: 1 Product Manager that just logs update (initiatives from us), 1 SysAd (also 0.5 developer), 1 Architect (Technical Direction), 1 UX, 1 Mobile Dev and me (business analyst/project manager). I used CP/APF. 7th week to present: 1 ProjectMgr/SM (me), 1 BA (I trained the Mobile Dev since we don't have any mobile work now), 1 Architect (Technical Direction), 1 UX, 1 SysAd (also 0.5 developer), 3 newly onboarded fullstack devs, 2 upcoming QAs (1 manual, 1 automation). We now use Scrumban with a very well defined DOR, DOD and Buffer Zones. Heck, I even included Release Notes in the Board. LOL We focused on the PROCESS/FLOW. We documented all decisions in Confluence. Daily Standup starts at the same time. We eliminated other meetings unless a team needs to deliberate on something, but before we do that I write clear agendas. We switched to 1x1 chat/discussion when we need info from someone. Dedicated a day for refactoring right after review and before retro/planning. PO role is collectively shared between that BA/SM/Architect. DevOps role is shared between the SysAd/Architect. I told the Architect to lead the architectural discussions, code reviews, merging, deployment and we should establish code conventions early on so tech debt will not pile up and he will just code when necessary.
-
1 pm (me), 4 developer
-
My current team has 1/4 of a PO , 1/4 of a UX/UI guy, 2 frontend devs, 1 backend, 1 tester. It's a shit show :)
