Scrum Master

If I were to work in the role of a Scrum Master, I would expect that the team I am on is actually a Scrum Team. What you describe does not adhere to the rules nor the suggestions found in the Scrum Guide.

There are a lot of things that I would think about unraveling here. Why is the organization built around temporary or short-term projects instead of long-lived products? What is the relationship, if any, between these projects? Is the team of 28 people really representative of a team, working on a common goal? Does this "team" have all of the skills necessary to complete the work before them? What, exactly, is the manager's role on the team and what are their current responsibilities?

Unfortunately, I don't think I can recommend a plan without more details. There are some possible options to think about as first steps. One could be to reorganize into teams around the current projects, at least temporarily, and make sure that everyone is working on one project. However, if these are tightly coupled projects, that may not be a viable option.

The first change that I'd want to make is to make sure that the right people are at the meetings, even if that means someone has multiple meetings. I'd want to get the daily planning and coordination activity closer to 15 minutes, even if that takes a bit of time to achieve. I'd focus on the planning aspect and push technical discussions out until afterwards - it's OK to plan to have the technical discussion, but don't have it until later. This will solve the immediate pains of long meetings that don't add value for all of the participants.

We expect you to explain what kind of changes you plan to make in the short, medium and long term and what kind of impact you expect after these changes.

None whatsoever. There may be an opportunity for expectations to be revised. I would coach people to self-manage, and to self-organize into more effective cross-functional teams. Yet it wouldn't be up to me to make any changes to the current way-of-working. I would seek to reveal, but I would not seek to resolve.

We expect you to explain what kind of changes you plan to make in the short, medium and long term and what kind of impact you expect after these changes.

I'm going to assume that management and I are in agreement that this is not Scrum, shouldn't be called Scrum, and I am not the Scrum Master of said team... I am now the Agile Consultant that is helping them transform their business to be more Agile. 

In doing so, I'm going to ask for a commitment from all of the leadership that the 4 values and 12 principles of the Agile Manifesto are indeed valuable and desirable to implement for this company. If that is agreed upon, I am going to lay out a plan.

The plan will be as follows:

Short Term - 

Establish which of our 4 projects is producing the most value to our business. Once we identify that, prioritize the work of that project over the others. 

I am also going to decouple these projects as much as possible, till they are separate projects entirely. I will expect the entire team to help craft a vision of how this would be possible and submit that to leadership.

Once we have clearly defined which of these projects are priority, and they are in fact separate initiatives. A backlog will be formed for each of these projects

I will present the backlogs and allow them to organize themselves into teams that will perform the work necessary to complete these projects.

These teams will be given full autonomy over the projects, they can create the solutions and interact with the customers, and even deploy these solutions as they see fit, so long as it doesn't go against the company vision.

When these teams are formed, and all of the work is either accounted for, or at least prioritized such that the teams know what they want to work on, and with whom they will complete that work, with no overlap between teams nor dependency. Then, those teams will be given the option of adopting Scrum, Kanban, XP, or make up their own framework / processes and choose their own tools etc. 

Any remaining work will either require additional resources, or will need to be cancelled / put on maintenance for the time being.

Customers feedback would be placed as a top priority to these teams, and that feedback would steer the continued development efforts.

Medium Term - 

As far as roles are concerned, testing will become the responsibility of everyone in the teams. There are no testers, and no developers, there is just work and teams capable of accomplishing that work. If the team decides they can function just fine with a single tester and say 4 developers, then okay, but ideally I would encourage these teams to incorporate testing and development together into a TDD setup, with automation as the focus for continuous deployment and integration at a sustainable pace.

Teams would be required to continuously improve their processes / tools / customer relationships such so that they can show a trend of improvement over time based on metrics they chose and presented to leadership in alignment with the company vision.

Transparency of the work being requested, agreed upon, and currently in progress would be required and visible to anyone in the company, and customers would be given access to a snapshot of this based on work that is requested / completed but not necessarily in progress.

Long Term - 

I would probably ask the manager to fill in where they can, and encourage them to learn new skills, or perhaps re-assign them into a more business role if they can't be productive for the team.

As far as HR is concerned, the titles and "head count" would have to change such that titles were not hierarchical, while obviously pay would remain untouched. 

I'm sure this plan would evolve heavily over the weeks and months as it began to be implemented, there's no telling what could arise and how it might need to be addressed. But, this establishes the basics of customer engagement and value being the primary driver, teams being autonomous, and continuous improvement with sustainability.

What the company chose to brand this for themselves, would be up to the teams, some teams I suspect would have different approaches, while some may fully enact Scrum, others might use a form of Scrumban, and yet others may have a unique combination of many frameworks. 

Either way, I would probably ask to be titled an Agile Coach for the company, and if necessary I would help recruit other Agile Professionals, perhaps in the form of Scrum Masters to help facilitate these teams if requested.

That's what came to me over the last 30 mins of thinking about this, I'm sure I've left out plenty. Feel free to chime in if you think I've made a major boo boo, I welcome the opportunity to grow.

17 Backend Developers in the team work dedicated on 4 different projects. The remaining 7 backend developers don’t pull work from projects. They pull independent work from Kanban Board.

 

So there seem to be several teams, meeting as a single team, every day.

- that seems to be 17 devs split across 4x product teams

- 7x devs doing I assume more BAU work

Why are they all meeting daily?

Where are the non backend devs for the 4x product/project teams? (excluding the QA people)

Does the org want to be cross functional, or not?

I agree. You're an agile coach, even if you were hired to be a scrum master.

Step 1: encourage the 5 teams to start running their own standups instead of all piling into one all-in team meeting every day. Encourage the Engineering Manager to deal with escalations, (collaboratively) negotiating policy, such as definitions of ready, done, engineering standards, coding practices - things that the enterprise should agree on (yes there is room at the team level but scrum assumes engineering excellence, the engineering manager is there to ensure what that means is commonly understood and accepted)

Garrie