Very interested to hear about the shape of YOUR Agile team. Chime in below.
@sarahs44704 жыл бұрын
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.
@tommytisen37424 жыл бұрын
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.
@karenlewis70094 жыл бұрын
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.
@lowevar63 жыл бұрын
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.
@thx50014 жыл бұрын
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.
@Dhamian4 жыл бұрын
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.
@jcpederson551264 жыл бұрын
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.
@paulsims40514 жыл бұрын
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?
@rudiservo4 жыл бұрын
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.
@marymueller21894 жыл бұрын
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.
@Developmentthatpays4 жыл бұрын
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?
@RaxDaMan4 жыл бұрын
Do you have a video explaining difference between Product Manager and Product Owner?
@Developmentthatpays4 жыл бұрын
I don't but I really should have; it's been on my list for a very long time.
@srenwork81524 жыл бұрын
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 ....
@tommytisen37424 жыл бұрын
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.
@paulsims40514 жыл бұрын
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.
@ArchimedesTrajano4 жыл бұрын
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)
@Developmentthatpays4 жыл бұрын
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?
@ArchimedesTrajano4 жыл бұрын
@@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.
@lapokode47214 жыл бұрын
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.
@Developmentthatpays4 жыл бұрын
I'm fascinated by your 4 parallel sprints. How does that work?
@lapokode47214 жыл бұрын
@@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.
@tommytisen37424 жыл бұрын
😰
@TechBAwithMark3 жыл бұрын
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.
@Roon3y4 жыл бұрын
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)
@chadthibodeau89434 жыл бұрын
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_AMU4 жыл бұрын
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.
@tommytisen37424 жыл бұрын
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).
@drdmichel764 жыл бұрын
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....
@paulsims40514 жыл бұрын
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.