Programming

Agile. and I don't mean Corporate Agile, I mean true, by the books, real Agile. Team driven from the get go: Developers, Product Owner, Scrummaster. That's it.

Agile has been bastardized by corporations for so long that developers think it's not for them. Agile was built to be developer-driven, the dev team should be making all decisions and setting their own pace. The developers should decide

• What points mean
• How many points stories take
• If a story is fleshed out enough
• How long sprints should be
• How they want to run their process

Corporations have turned this around and ripped control over the teams from themselves to impose insane company wide rules. Things like points being rigid tied to time things (points should be a "gut check" feeling on how complicated an item is, Not based on time, i.e. "this is a 1 point story, it's similar to a config change and we call that a point". This means that jr developer or senior developer doesn't matter, it's always 1 point), rules around when meetings should be (dev team should decide when standups should happen), the length of sprints (some teams like 1 week, some teams like 1 month, agile doesn't care as long as they are producing), and just so many things.

Agile is supposed to be "Let developers make a process that works for them, business should be able to adjust". Usually if I join a company and their scrum process is dictated from business it means that the business side/project managers were too lazy to translate the dev team's structure into business terms (something that any competent scrummaster would be able to do)

Anyway, thanks for coming to my Ted Talk -A very burnt out scrummaster who has been told by too many MBAs how Agile works.

My tip, "developer empowered" means that the buck stops with Engineering leadership when it comes to dev work. They have to be able to greenlight work, and also red-light it.

That gives engineers the flexibility to build what they see is missing, while still having executive leadership (e.g. "Director of Engineering" etc) in the loop who can rein in rabbithole-development projects.

But the second you allow "Product" teams to dictate dev work, you will lose that developer empowerment, and they will always just be "the ones who build what Product tells them to".

So I've been in IT management since the 00s, first running a help desk, then moving on to projects, then senior technology leadership incl. running onshore and offshore dev teams. Right now I'm in a sr. dev/service architect sort of role that includes oversight of deliverables from developers.

And it's a tough question. The problem is, you will hear valid points from every extreme. Some will say, get the business people out of the way, let the engineers run the show and solve the problems. And they're not wrong. You will hear some people say, money rules the castle, any behavior that is not aligned toward revenue is a waste of time. And they're not really wrong either. And others will say, the management hierarchy is paramount; do what your immediate supervisor says, and trust the process. Others will say, do what's right regardless of what management thinks, and you'll get ahead. And none of these people are wrong either.

What I've learned through working on both the technical and business sides of the house is that while technical skills comprise assembling technical assets and resources to solve an engineering problem, business skills comprise assembling financial assets and human resources to solve a business problem -- assets and resources that INCLUDE engineering effort. And for the most part, business people do not, and cannot, understand everything engineers do, any more than they can understand everything HR does or everything facilities does or everything sales does. Business people are like the generals pointing to a map; they don't know (or need to know) how the guns and tanks and helicopters actually work. They do need to decide which hill to take, which bridge to destroy, etc.

But damn it, they better listen to the people who DO know how things work.

So, inasmuch as I can answer your question at all, I would answer it this way: developers will be empowered when everybody learns to stay in their lanes... most of the time. Business people should treat development a little bit like a black box: make sure the right requirements go in the Input side, and make sure the right deliverables come out the Output side, and get involved in the innards only when there is a problem with the outputs.

Conversely, developers can -- and should -- analyze requirements critically, develop an understanding of WHY the requirements are what they are, and generally be consulted stakeholders in the requirements gathering process. But ultimately they should not be deciding what to build, because they just aren't going to have the 360-degree picture to understand how the business is going to make money from that output. Those inputs have to come from business-oriented people who are actually charging money to do things (or otherwise know what the customer wants).

That's probably why modern development methodologies like Agile are so tightly focused on pairing the developers with business people who can provide rapid input and evaluate prototypes on short timelines. Keep the inputs and outputs in digestible chunks, but keep the business thinking on the customer side and the engineering thinking on the development side.

There are no tips. Building an engaged, empowered group requires vision; owner and management buy-in; financial, technical, educational, and well-being support; and ancillary support services that enable rather than frustrate.

The fact that these are so rare may give an idea of how difficult they are to sustain. (Caveat: based on my US-only experience.)

I'd like to add something to what the others have said here.

First you should see your company as a community, and every community has a culture.

It's going to be extremely hard to change a culture in an existing community. You'll have to identify who the core members are, or opinion leaders, and work with them. This comes with obvious difficulties, for example how will you get them involved in the changes that you wish to apply?

It's easier to start from scratch. I have no experience here and it depends on your exact situation, but you might want to create a new team. The initial people in any community or are going to set the tone and atmosphere and remain influential over time. New members will copy their behavior.

Whichever way you take, you'll want to consider what culture you want. What vision does it have, what values?

Let me make an example here. Say you want developers to be able to say no. It's something a lot of people will be afraid to do, but it can make your company more efficient by avoiding unnecessary work. When you join a new team and you see an existing member doing it, you'll feel safer to do so as well. You might call this value open communication or empowerment.

So you'll want to figure out your exact intent. What vision do you have and what values suit that vision? And what is your strategy to affect company culture?

You have to understand that it isn't going to be a one and done deal, but an ongoing journey.

I would like to argue for the psychological safety that Google found in project Archimedes. As a manager (of any group) one of the most important things to bring is to genuinely care for your people. Also spend time on making a culture where colleagues care for each other.

At the same time, it is important to be willing to take the difficult talks and decisions early on. If you have a bully or somebody tearing down your team, take action. This also goes for interactions with the rest of the company. The task of the group is to build the best product/service/whatever for the company, and anyone aiding in that should be welcomed. Anyone hindering it needs to be stopped, regardless if they are part of the team or belong somewhere else in the company.

Finally, make sure decisions, targets etc. are there because they are good, not because of politics or ego. It may take a bit more time early on, but getting everybody on the same page with respect to how and why you (as a team) want to do particular things always pays off.

Don't treat existing code/design/archtecture is sacred until it's backed up by static analysis proving it is bug-free.