Is your Agile Team the right "shape"?

  Рет қаралды 4,127

Development That Pays

Development That Pays

Күн бұрын

Пікірлер: 37
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
Very interested to hear about the shape of YOUR Agile team. Chime in below.
@sarahs4470
@sarahs4470 4 жыл бұрын
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.
@tommytisen3742
@tommytisen3742 4 жыл бұрын
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.
@karenlewis7009
@karenlewis7009 4 жыл бұрын
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.
@lowevar6
@lowevar6 3 жыл бұрын
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.
@thx5001
@thx5001 4 жыл бұрын
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.
@Dhamian
@Dhamian 4 жыл бұрын
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.
@jcpederson55126
@jcpederson55126 4 жыл бұрын
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.
@paulsims4051
@paulsims4051 4 жыл бұрын
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?
@rudiservo
@rudiservo 4 жыл бұрын
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.
@marymueller2189
@marymueller2189 4 жыл бұрын
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.
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
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?
@RaxDaMan
@RaxDaMan 4 жыл бұрын
Do you have a video explaining difference between Product Manager and Product Owner?
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
I don't but I really should have; it's been on my list for a very long time.
@srenwork8152
@srenwork8152 4 жыл бұрын
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 ....
@tommytisen3742
@tommytisen3742 4 жыл бұрын
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.
@paulsims4051
@paulsims4051 4 жыл бұрын
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.
@ArchimedesTrajano
@ArchimedesTrajano 4 жыл бұрын
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)
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
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?
@ArchimedesTrajano
@ArchimedesTrajano 4 жыл бұрын
@@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.
@lapokode4721
@lapokode4721 4 жыл бұрын
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.
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
I'm fascinated by your 4 parallel sprints. How does that work?
@lapokode4721
@lapokode4721 4 жыл бұрын
​@@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.
@tommytisen3742
@tommytisen3742 4 жыл бұрын
😰
@TechBAwithMark
@TechBAwithMark 3 жыл бұрын
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.
@Roon3y
@Roon3y 4 жыл бұрын
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)
@chadthibodeau8943
@chadthibodeau8943 4 жыл бұрын
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!
@1964_AMU
@1964_AMU 4 жыл бұрын
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.
@tommytisen3742
@tommytisen3742 4 жыл бұрын
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).
@drdmichel76
@drdmichel76 4 жыл бұрын
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....
@paulsims4051
@paulsims4051 4 жыл бұрын
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.
@garyleeson
@garyleeson 4 жыл бұрын
Product-Owner + Scrum Master/Delivery-lead + 4 Developers
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
Textbook!
@kalaivanansundaram7309
@kalaivanansundaram7309 3 жыл бұрын
1 pm (me), 4 developer
@Developmentthatpays
@Developmentthatpays 3 жыл бұрын
👍
@TahayariDan
@TahayariDan 4 жыл бұрын
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 :)
@Developmentthatpays
@Developmentthatpays 4 жыл бұрын
😂 - you made me laugh out loud!
What you taught me about Scrumban. (And Kanban.)
15:52
Development That Pays
Рет қаралды 2,2 М.
Putting the 4 kanban principles to work
14:00
Development That Pays
Рет қаралды 29 М.
黑天使被操控了#short #angel #clown
00:40
Super Beauty team
Рет қаралды 61 МЛН
СИНИЙ ИНЕЙ УЖЕ ВЫШЕЛ!❄️
01:01
DO$HIK
Рет қаралды 3,3 МЛН
人是不能做到吗?#火影忍者 #家人  #佐助
00:20
火影忍者一家
Рет қаралды 20 МЛН
I Started A Business From Scratch To Prove It's Not Luck
7:36
Eddie Cumberbatch
Рет қаралды 4,8 М.
What is the problem with agile? - interview with Jurriaan Kamer
3:52
Jurriaan Kamer
Рет қаралды 1,7 М.
13 ways to BREAK Scrum. (Easier than you think.)
10:08
Development That Pays
Рет қаралды 2 М.
12 Agile Principles with concrete examples
13:08
The Agile Coach
Рет қаралды 48 М.
How to Supercharge your Agile Board (Kanban Board)
30:17
Development That Pays
Рет қаралды 3 М.
Scrumban - Your Questions, Comments and Concerns
15:17
Development That Pays
Рет қаралды 26 М.
Test Driven vs Behaviour Driven Development
5:01
Development That Pays
Рет қаралды 163 М.
Avoid Hiring Data Ninja Rockstars: How To Build Effective Data Teams
29:44
Scrum vs Kanban: Two Agile Teams Go Head-to-Head
17:17
Development That Pays
Рет қаралды 448 М.
Time to stop the madness. Time to stop estimating.
13:18
Development That Pays
Рет қаралды 9 М.
黑天使被操控了#short #angel #clown
00:40
Super Beauty team
Рет қаралды 61 МЛН