How to manage an army of not-really-devs trying to write code for the sake of project management?

Question

We recently adopted a new management methodology that says there are no roles on the team (a "cross-functional" team where "all team members are developers") and everyone should be doing everything so we now have UX designers and QA engineers trying to ship code with some copy paste and online courses.

I have never been a manager before and I am not a manager of these people but since we have half the team suddenly becoming developers and as the only actual software developer (sorry if pejorative, but none of these people have written code before) not just ignoring newbie slack messages I am not getting anything done.

It doesn't help that each developer has a certain number of points required per sprint and there is no difference between people based on experience. The newbie developers really shouldn't have the same point expectation as people who have coded for years.

I approached my manager, but the project management method has been dictated from the top. The manager is also a developer and doesn't really want to deal with it. His manager finds the methodology strange but isn't willing to go against the people with the certifications. Basically I don't think it can really be changed all that much so I need to learn how to work within the framework.

What are my options for dealing with this? How do you manage an army of really green people and get useful code out of them?

Answer 1

The idea that "everyone is a developer" and "everyone writes code" aren't the same thing. In this sense, "developer" does not mean "programmer", but "a person or thing that develops something". UX designers, programmers, testers, business analysts, and others are all involved in the development of a product.

Sometimes, the idea that "everyone is a developer" can be useful to form the culture that everyone is equal. Something that I've seen before is programmers who think they are better than testers or who won't push back on a UX designer regarding design decisions. Thinking about everyone as a developer can put everyone in a position as equal collaborators.

There's no reason to make everyone write code. Instead, everyone should contribute using their skills. There could be ways to cross-train. Perhaps UX designers can learn front-end programming skills to gain a deeper understanding of implementing their designs. Testers can learn programming for a deeper ability to perform white-box testing or test automation. Likewise, programmers can learn these skills to take some of the load off of these roles and share the overall workload.

The issue that everyone needs to complete the same amount of "points" is probably making this worse. Typically, measuring work like this is done at a team level. The team, as a whole, plans and executes the work. Everyone brings all of their skills to help the team finish the work and deliver high-quality products and services.

I don't believe that this is something that can be worked within, at least effectively. Something needs to change, otherwise you'll have people doing work that they are not skilled or qualified for in the name of "getting points done" rather than contributing their knowledge and expertise to the team's objectives.

Answer 2

there are no roles on the team (a "cross-functional" team where "all team members are developers")

One thing I want to note is what exactly cross-functional means:

it is not a team where every member can do everything. Rather, it is a team that is capable of doing everything.

What I would suggest foremost is confirming what exactly upper management meant by 'cross-functional'. It is possible that upper management simply said "make the teams cross-functional!' and middle management misinterpreted that as 'make everyone do everything!' and this is all a huge misunderstanding.

---

It doesn't help that each developer has a certain number of points required per sprint and there is no difference between people based on experience.

I have two words for you.

• Reality
• Transparency

In order to be good, estimates must be grounded in reality. Ordered in terms of best-but-least-likely-to-be-allowed to worst-but-most-likely:

1. Tell management you're lowering the story points per iteration. You (the actual software dev) will be brought down to match everyone else.
2. Tell management you're modifying the amount of work that 1 story point corresponds to. Exactly the same as the above but with an extra layer of indirection.
3. Ignore all estimates entirely. They don't exist. When questioned by management, explain that the estimates are not realistic.
4. Vote with your feet (find a new job).

It's common for estimates to be made by the team even in non-self-managed teams. An unrealistic estimate, imposed by someone not familiar with the work, is not worth the bits used to store it and should be treated as such.

Furthermore, management needs to be aware of the effect of decisions. Transparency is key - management making bad decisions when having all the facts is incompetence, but making bad decisions because they don't know what's going on is avoidable tragedy.

Answer 3

Analogy: "Everybody who knows how to occupy a house, or who has an interest in what their house looks like, knows how to build one – and who, therefore, knows how to contribute in some meaningful way as to how such a thing should be constructed."

My Experience: I do not pretend to know. Please do not give me a Home Depot gift-card for Christmas. I choose to hire professional, licensed contractors. They give me stacks of business cards, and I dutifully and happily distribute them.

Best Recommendation: "This ship is sinking. Head for the lifeboats."

Answer 4

This smells to me like a very bad misunderstanding of Scrum. The intent was never to homogenize everyone into having the same skillset and performing the same tasks, as though people with different expertise were fungible. You might seek some clarity into what is meant by these directives. If team members want to cross-train to understand each other's work, that's beneficial, but if you wouldn't hire someone to do a developer's work with zero experience in that work, then don't expect another employee with a different skillset to be any better at a different role. This idea that every employee needs to meet some quota of 'points' is nonsense. If that's really the direction you've received, then you might have to throw out the definition of 'points', do some legitimate style of measurement and estimation within the team, then assign these nonsensical 'points' in a way that checks the box after the fact.