Is your Agile Team the right "shape"?
HTML-код
- Опубликовано: 29 сен 2020
- Does your team have all the right roles, and the correct number of people in each role? Or is your team a little bit "real world"?
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
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... 
Хобби
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 team of 18? I thought my team was big at 12.
I have really used DevThatPays videos to leap directly from Scrum to Kanban, so I’m sure you can do it.
Start with removing all meetings except daily. WalkTheBoard daily’s. Focus on getting things from idea to production (left to right). And repeat. Remove waste, work the work, focus on flow.
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.
Feels like we are both having the same problem. Having 2 so called "silos" (development and testing) really destroys any chance on finishing the sprint. Either testers get overloaded at the end of the sprint or developers do not have work to do and add tickets. Regarding PO's always bring that up as soon as you spot it and explain during retrospective why you are failing to meet the goal. If anyone have an idea how to fix the test developers silos please let me know. Just asking developers to test does not work, since it requires different skillsets.
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.
Must a Scrum Master have technical skills to be an effective leader? Does it matter if the person in this role comes from IT or the business? Besides keeping an eye on the flow of work through a team and helping the team remove impediments, I believe the SM is the person who coaches team members to establish a culture of intentional, continuous improvement. In that context, the lead developer supports the SM in helping the team identify potential improvements in technical practices. In Disciplined Agile, we call the lead developer role the Architecture Owner (AO). There is a healthy tension between the PO - who wants the team to build the right product (to delight stakeholders), the AO - who wants the team to build the product right (to avoid technical debt), and the SM - who coaches the team to deliver value early and often, effectively and efficiently. Thoughts?
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.
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 ....
Looks like the opposite of my team.
We are a “Scandinavian team”, having responsibility for both SE, DK and NO entities.
Product Owners have the burden of priorities between the three, but developers just keep on hammering, regardless of country. But they make good trade offs, by learning from the different code bases. The benefits are high of having just 1 team for all three countries.
Søren, consider mapping the value stream in your organization to show the queues and wait time that the existing structure creates. You are correct in proposing bringing work to focused solution teams. There may be times when it makes sense to minimize dependencies by temporarily "borrowing" a person or two for a couple of sprints to create a "whole" team. Check out Heidi Helfand's content on Dynamic Reteaming, www.heidihelfand.com/dynamic-reteaming/. Also, see Al Shalloway's articles, Understanding Our Inherent Problem - bit.ly/36DdR9y, Factors for Effective Value Streams - bit.ly/2GKubtX, and Creating Effective Value Streams - bit.ly/2F5Msl8.
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)
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.
Text-book wise, your team is "product owner heavy", but I've always thought that PO is the toughest role of all (and a lot for a single person to cope with). How do the 2 POs juggle the work?
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)
Interesting: your team isn't textbook - in terms of human beings. But your team does have all the roles... and it sounds like things are working just fine?
@@Developmentthatpays for the most part it is fine. But lots of juggling. This is doable due to the implied trust between the members and failure-is-a-way-of-learning.
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.
I'm fascinated by your 4 parallel sprints. How does that work?
@@Developmentthatpays It work just fine as the customer see it fit to their objective, otherwise the Customer will penalised us. In fact, we are doing a project delivery instead of product development, that is why we got no Product Manager, even more the Product Owner is actually deliver a Business Analyst job. The requirements/features itself is derived from Business Owner. There is Android sprint, iOS sprint, Web sprint, and API sprint handed to a team that in total consist of 48 resources.
😰
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....
Hi David, I'm curious whether the PO is available when the team members need input. Lack of PO engagement significantly affects the flow of work when business decisions have to be made.
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!
Oh, your boss is too stingy to hire another PO and another SM to enable the team to be split in 2, that's all.
Maybe splitting in two is an option with same members. Just make each team half focused on one half of the workload (provided a split of the product/s can be done).
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.
Do you have a video explaining difference between Product Manager and Product Owner?
I don't but I really should have; it's been on my list for a very long time.
Product-Owner + Scrum Master/Delivery-lead + 4 Developers
Textbook!
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 :)
😂 - you made me laugh out loud!