-
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.
-
I would even argue that points, stories and sprints are not things you need. If you go kanban, you don't need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.
Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they're basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).
-
which I'll fire back and say should all be team decisions. Usually with my teams I try to persuade them to go sprints at first while they're getting to know each other, but Kanban is always a possibility. Thing with Kanban is that you need a lot of trust within the team and a lot of honesty, things like "This story is really really stuck and idk what I'm doing wrong" vs letting it sit there holding up the WIP count.
-
-
I am, for the first time, in an actual agile environment, and it’s amazing. I love our product manager.
-
It's extremely freeing realizing that coding in a business environment can be fun, it doesn't have to be torturous. The big companies just love micromanaging though.
-
-
The book in “by the book”; Any book to recommend?
-
As long as you're following the manifesto and the principles, you're good. You'll notice this doesn't talk about scrum or kanban or safe or whatever, those are processes that try (sorta) to follow these. But if you're ever in a situation where somebody says "this is the process we're supposed to do" hit them with the manifesto.
-
It's impressive how few people have read the 4 (four) lines of agile manifesto, especially buisiness people.
-
-
- Teams should be self sufficient. Team A shouldn't depend on Team B. Coordinating across teams takes up so much time.
- Teams should be flexible and change organically. If you suddenly need the expertise of another person, they should be able to join your team without filing a bunch of paperwork. If you're no longer needed on your team but another team could use you, same deal.
- Product doesn't get to solution. I know, everybody should get to have an idea and voice it. But devs have to actually build and deal with the thing. Product can make requirements but don't get to say "you have to use bigquery" or something.
Edit: I almost forgot the two statements that I put in every team working agreement.
- You're number one objective is to not burn out. Limit your number of hours. Schedule a week of vacation for every two months at least. Work a 4 day week if you can. Work the hours that make sense to you. You can have some core hours where everybody should overlap on most days, but the goal is to deliver something not sit at a desk from 9-5.
- You are allowed and encouraged to make mistakes. This is how we learn. You will only get in trouble if we, as a team, keep making the same mistakes.
-
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.
-
I work in a company where we say that everyone is an expert (and to a very large extent this is really true). We create teams of experts, including more business savvy people. Everyone respects each others expertise and makes sure they can apply it as best as possible. We don't infringe upon each other's expertise. We might ask another expert about the why or the how, but we should not assume we know better. Obviously this happens sometimes, but then we remind each other that we're all experts and that an engineer wouldn't like to be told by marketing how to do their job either.
I think this fits nicely with 'stay in your lane' and actually makes it easy to remind people to do so. It's in the core values of the company that people excel in their lane and cooperate with people in other lanes.
-
Engineers like to say that business people should get out of the way and let the engineers to their job, but ask yourself how many engineers choose to supervise other human beings. Somebody has to do the hard job of dealing with employee psychology all day long. It's a messy, "up to your armpits in other people's lives all day long" kind of job.
You need people who are actually GOOD at that, with all the emotional intelligence it implies, if you want a workplace that doesn't completely suck.
-
-
-
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.)
-
Don't treat existing code/design/archtecture is sacred until it's backed up by static analysis proving it is bug-free.
-
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.
-
“How do I create an empowered culture in IT”
This fuckin guy: “FIRE EVERYONE”
-
What I'm really trying to say here is have you tried turning it off and on again xD
Well if it's a large company he can start a new team is what I meant.
-
-
-
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.
