[Closed] Agile - I feel I'm being micromanaged - SoftwareDevTrackWorld

Yes, exactly the same. It is ludicrous and beyond micro-management. We spend so much time in meetings and explaining what we are doing over and over again.

Utter bullshit in my opinion but some people are making very good careers out of it.

Agile works well when it's done right, the problem is that everyone does it wrong.

It always goes to hell as soon as you get PMs trying to be scrum masters, in my experience.

As someone who is a Product Owner I understand the view. Personally it works for me and has stopped developers giving me stuff I didn't want or ask for. We mainly work in 4 week sprints are yours shorter?

I only read 1 line and gave up. Maybe that says more about Mr than it does you

Utter bullshit in my opinion

Agile methodology can be done badly just as any other management idea can be done badly.

It is NOT meant to be spending all your time in meetings (obviously, as this is stupid). The fact that your managers haven't figured this out suggests that they are rubbish managers. I mean who would ever think it was a good idea to spend tons of time in meetings instead of working?

I think the problem with Agile is that someone has tried to formalise a way of working (small, flexible teams) but in doing so has broken the essence of what makes it work.

No, your company has broken it. When done properly it works well. You work, you talk to the people in your small team, then once a day you have a standup meeting where you share what you're doing. So you have a small number of people saying 'I'm working on this' or 'I need this'. They are called stand-ups because they're meant to be so short that there's no point sitting down or getting a room.

The idea is that instead of spending forever getting bogged down in planning hell, you just get on with it and figure it out - and then if it turns out to be taking longer your deadline will extend - but crucially, your management will know exactly why it's taking longer and will be able to see what the new now more accurate delivery date will be. The longer the project goes on the better you know your velocity and your confidence in your end date goes up.

If it's not like that, your management are making a balls-up.

Who are you updating on everything and why are you being asked? Do you have a Kanban board?

yeah i hate Agile. It's just the latest management buzzword. Everyone has a different idea of what it means, no-one really knows, and we never seem to do it "right".

The purpose of the daily standup, is more to focus you on what your going to do for the day, rather for the others.

It always goes to hell as soon as you get PMs trying to be scrum masters, in my experience.

That's pretty much what's happened.

Although, the best scrum master we've had was someone who started being a dev, went to PM, then became a scrum master as they understood all sides. One time when we were up against it they were debugging environment issues, doing some testing etc. They could update the business on exactly what was going on.

We mainly work in 4 week sprints are yours shorter?

We used have to 6 week sprints. They are now 2 weeks.

When done properly it works well

I believe it can

You work, you talk to the people in your small team, then once a day you have a standup meeting where you share what you’re doing. So you have a small number of people saying ‘I’m working on this’ or ‘I need this’. They are called stand-ups because they’re meant to be so short that there’s no point sitting down or getting a room.

That's what we had, before.....

Who are you updating on everything and why are you being asked?

Me personally, just the scrum master and lead dev. The team as a whole, business stakeholders.

Do you have a Kanban board?

Of course

Even within the same company different people can have very different expectations.  I've had both good and bad agile experiences in the same (large, non-tech) company.  It does feel like some people expect PM's to be good agile scrum masters but they're so used to Gantt charts etc they just can't look beyond them.

I always thought the purpose off the stand-up was just to make sure no-one was waiting for something from someone else etc and to make sure everyone was being productive.

It can be as frustrating hell, or a brilliant way of working… all comes down to the SM, in my opinion. You can see why the good ones earn good money. A poor one will make you want to quit your job several times a week. Get rid of them… seriously… if devs and product owners are frustrated by a SM, you have to be ruthless and get rid, or you’ll just all dig a big hole of personal animosity and broken product.

Because that’s what we had, before

Right, but your managers wanted to know when their product was going to be delivered, and you said 'ooh, dunno, X months maybe?' and they don't like this because they need to budged and coordinate other stuff. So someone came up with a way of managing this uncertainty, and called it Agile.

The bottom line with managers is that some of them think their job is to make their underlings do what their bosses want, and others think their job is to let their underlings do what they need to do and take the heat from them.

If you have the first kind, it makes no difference what methodology you use, your job will always be shit because they will always be looking for ways to beat you up and put pressure on you. Because they work for their bosses, not for you.

I always thought the purpose off the stand-up was just to make sure no-one was waiting for something from someone else etc and to make sure everyone was being productive.

Yes, I didn't used to have a problem with them but they feel very different now. I think it's the lack of feedback that a non-technical scrum master can give, it's more or less "Thanks". Rather than "You've got X working, how did you manage that? That's pretty good given we were working with Y"

Right, but your managers wanted to know when their product was going to be delivered, and you said ‘ooh, dunno, X months maybe?’ and they don’t like this because they need to budged and coordinate other stuff. So someone came up with a way of managing this uncertainty, and called it Agile.

I think the fundamental mistake is that all teams have been changed. Some worked just fine, others had big issues. However, these issues were rooted in the software implementation (v. poor), hence changes and developments were very involved and always took a long time. The software is a collection of services for CRM, so all need to change to do a 'new' thing. Some services are badly implemented or had dependencies on uncooperative teams outside of the 'dev' sphere (e.g. catalogue reference data).

Another problem with using Agile methodology is that managers think it means you'll never have to make Version 2 of the software, you can just go from sprint to sprint making add-ons, fixes, bodges, bodges for the bodges, etc when the most efficient thing to do would have been to say, 'We've got this version of the software working, now lets start again from scratch using the lessons learned from our first attempt using a design that will allow us to improve functionality in the future.'

Our company are drowning in technical debt at the moment to the point where we haven't released anything for more than 2 years.

Funnily enough, when I started in the development team I said, 'Maybe we should stop adding onto this software since nobody really understands how it works anymore because it's become too convoluted and tangled and start working on the next version. It might take a year but I think we'll be in better shape'

To which the manager replied, 'Companies that don't release new software for a year go out of business.'

Well, it's been 2 years of trying to get an update to work and we still seem to be in business.

molgrips
Member
Who are you updating on everything and why are you being asked? Do you have a Kanban board?

We have daily stand-ups that are run by the project manager and last half an hour every day.

We do have a Kanban board and we chat over that, going through each person one at a time. We are not purely software, we are an engineering R&D team. So, we may have to listen to the PCB layout engineer telling us all about pad size and number of layers, a mech engineer telling us about material strength, an electronic engineer talking about EMC issue, a test engineer talking about breaking things......

Stand-ups, retrospectives, planning meetings. If we are in the stand-up and there is an issue, the immediate response is 'we'll arrange a meeting for that'. We used to just have a quick chat between the interested parties and get on with it. Now we have to have the project manager plus a couple of engineering managers, then the engineers to discuss it and raise some tasks.

There seems to be a lot of talking about work rather than doing work.

This seems to be the way of things these days, especially in major corporations and not exclusively in IT.

Hard to call agile a new thing when it's been around for more than 20 years.

When you get your implementation of it wrong, you need to go back to the principles of it, look against your current activities and if it's not helping it, bin it

Just wait until you go SAFe, then it’s PI planning, IP iterations, scrum of scrum, problem solving workshops, system demos. Add in Release Train Engineers and it’s all aboard the ART! I’ve just received my SAFe Scrum Master certification, peep peep!

Scrum master 🤣🤣🤣 WTF!

#differentworld....

I think remote/home working has not helped. I was on a project where we were organised by management into teams they thought would work. These were multi-disciplinary, i.e. people with knowledge of different services in the stack, rather than a team full of people working on just one service.
It was a bit bizarre though. There was an obsession with having 3 teams (max. size perhaps?). It lasted 2 weeks before we reorganised ourselves into 2 teams that had the resources we needed. We could do this as we were in the office and there were no restrictions on Jira for assigning tasks etc. Also they only had 2 scrum masters anyway (one did two teams). So we forced the issue. We delivered the first stage of the project on time but there was still a lingering "yeah, but you'll have to go into 3 teams for the next stage"....3 teams appeared again, this time with 3 different scrum masters. This also coincided with lockdown and then everything fell apart. Nothing was delivered on time. We scraped similar resources back together. This was through negotiation with the scrum masters this time though, so people were in and out of teams all of the time. Remote working made the scrum masters very much the gate keepers. People came into the team but didn't/couldn't stay long, so I was repeatedly going over stuff with people new to the team. I reckon in the time I spent doing this I could have done their work myself.

I should also say that in the last year we gained an Agile coach/consultant to whisper in the ear of top management. Not sure if that relates to what I see today....hmm

Do we work at the same company? 🙂

I know what you mean, we went through this quite a while ago, and I'm still not a big fan of it.

Some key things that might help

- Use the processes in place. Be vocal in retro's and daily standups about the issues. The scrum master is there to help you and the team, if they don't, they aren't really doing their job. Especially complain in retro's...since that's what it's for.

- Find the influential people who will listen. Probably lot's of people will hold the same views, and the more people that shout, the easier/quicker things seem to get resolved

- Suggest some ideas such as 'focus time'. There's a few tools we're trialing that re-organize calendar meetings to maximise focus-time (it's working quite well)

- Only accept meetings with agenda's. If you don't think you would be allowed todo this, bring it up in retro's and get the team backing - make meetings more efficient.

The biggest one, is probably to aim for continuous improvement - nothing should be set in stone (including the scrum/agile processes themselves).

What you've described does sound a bit hellish, OP 🙁

I think "Agile" per the Agile Manifesto is a Good Idea, and when I've worked in teams using the methodology it has been broadly pretty good.

The only real downside was that the daily standup could drag on a bit occasionally. But equally, it was good for team cohesion, and for keeping everyone in the loop. Certainly I never felt particularly micro managed.

I think as others have said, a lot boils down to the implementation. I think if I were a PHB type at your place and you'd organised yourselves into two teams and gone on to deliver on time I'd be tempted to leave well enough alone and let you get on with it.

I work as an agile coach. It sounds very much like your scrum masters and your coach don't really know what they are doing. This is sad, but not unusual. You should absolutely not feel like you are being micromanaged, that's a sign that something is very wrong.

I work as an agile coach

Don't take this the wrong way, but qualifies you to do so?

I am genuinely interested to know what people who do that role have done before and how they get into it. One might think that they would have many years of successful (and some failed) project delivery cycles in different companies, because essentially they're playing with the future of the company they advise.

Don’t take this the wrong way, but qualifies you to do so

34 years in software development. Programmer, DBA, systems programmer, architect, manager, Director of Software Engineering. Experience of pretty much all the methods that came before agile. Led agile adoptions at more than one company. Worked on agile projects with up to 120 people. Lots of reading and discussion with others in the field. And I like to think I'm not stupid.

But it was a fair question.

I know an agile coach. He was a dev for many years then a senior dev.

I don't think they are playing with the future of the company, really. It's just a different way to manage projects. It's not one thing that you have to spend a huge amount of money committing to. You just try it out, build your own skills, figure out what's going to work. As I understand it, it's a meta-approach to management. You use the framework to work out what you want, and no two projects are likely to work out the same. That's why it's called Agile.

34 years in software development. Programmer, DBA, systems programmer, architect, manager, Director of Software Engineering. Experience of pretty much all the methods that came before agile. Led agile adoptions at more than one company. Worked on agile projects with up to 120 people. Lots of reading and discussion with others in the field. And I like to think I’m not stupid.

That's the answer I was hoping for and the sort of background I think is necessary.

I'm not sure our Agile coach is even 34 years old....

It’s just a different way to manage projects.

I think that viewing it as "just another way to manage projects" is one of the things that leads to the scenario described by the OP. There is rather more to it than that.

I know an agile coach. He was a dev for many years then a senior dev.

I think it is a massive negative when you lose incredibly talented technical brains to project management (scrum masters or whatever you want to call it).

I think these positions should be paid less than the technical positions because most engineering managers and similar positions are taken by very good technical people who just end up being meeting stooges/JIRA shufflers.

I know several very intelligent PHD qualified chartered engineers who now do no engineering, they are just resource managers earning more than they did before.

I’m not sure our Agile coach is even 34 years old….

I don't think he has to be, he just has to talk to and listen to the ones who are.

I think that viewing it as “just another way to manage projects” is one of the things that leads to the scenario described by the OP. There is rather more to it than that.

I disagree - I understand the level of organisational change it requires, but that's ultimately what it is. I think the OP's situation comes from it not being fully understood.

I think it is a massive negative when you lose incredibly talented technical brains to project management (scrum masters or whatever you want to call it).

The guy in question wanted to move, because he was fed up of people cocking up agile methodology.

I work as an agile coach

I am genuinely interested to know what people who do that role have done before and how they get into it. One might think that they would have many years of successful (and some failed) project delivery cycles in different companies, because essentially they’re playing with the future of the company they advise.

The best post of the thread. There are waaaaay too many 2 day certification imposters giving agile ways of working a bad name. The classic test is when they are more coach than domain expert - turning the question around instead of giving concrete options based on battle scarred and hard won development experience. You shouldn't be allowed to work as a product owner, scrum master or agile coach unless you've served time as a developer (in the Scrum sense of the word). All IMHO of course.

I don’t think they are playing with the future of the company

It is where I work. We write and maintain all of our CRM stuff in house so we can respond to new or changing markets. There have been some requirements turned around in no time at all, e.g. for Black Friday. Outsourcing to a 3rd party couldn't match it. It's one of the reasons I like working there.

It sounds as if you are at the mercy of your bad legacy software design rather than any agile coach.. But good management should take that into account I feel.

You shouldn’t be allowed to work as a product owner, scrum master or agile coach unless you’ve served time as a developer (in the Scrum sense of the word)

Well this is what I thought...until we had scrum masters coming in, straight out of uni.

Our Agile coach was asked by a scrum master if maybe he would step into one of the other scrum master roles while they were recruiting. It was a genuine question. He laughed off the suggestion.

Chuck GDS into the mix for added fun 🙂

It sounds as if you are at the mercy of your bad legacy software design rather than any agile coach

Actually, some brilliant stuff has been done despite the legacy software. Really clever stuff to make it do more than it should and keep the lights on. This was all before we went full 'Agile'. I am now a bit worried that we will start to lose the edge. That said something had to change, but I feel they've gone too far in the wrong direction and delivery will start to suffer.

Chuck GDS into the mix for added fun

Please don't. They're better than they used to be, but still have a lot to learn.

Gartner's hype cycle applies to agile adoption as much as anything else

Please don’t. They’re better than they used to be, but still have a lot to learn.

They're funky cool guys who ride scooters and have stickers on their laptops, so they must be right 😉

I think it is a massive negative when you lose incredibly talented technical brains to project management (scrum masters or whatever you want to call it).

Oh I get it, the only hard problems to solve are technical 🙄

(Clue: they are often the easiest. Try solving problems involving people)

Molgrips knows what he's on about.
Poor Planning/ Development lifecycles
Unreasonable or toxic people
Inability to listen /ostrich mentality
Legacy debt riddled software people don't understand any more.
People pretending they do understand it. Or that you should.
Bullshit
Inability to have a coherent conversation about all these things

These really are all the sources of pain.

I think it’s the lack of feedback that a non-technical scrum master can give, it’s more or less “Thanks”. Rather than “You’ve got X working, how did you manage that? That’s pretty good given we were working with Y”

I thought the scrum master was just there to facilitate the process? The daily stand-up is for the dev team to update each other and agree tasks for the day. If it’s working well the scrum master shouldn’t really need to get involved at all, especially in the technical aspects ?? At least that’s the way I woz learnt it.

I thought the scrum master was just there to facilitate the process? The daily stand-up is for the dev team to update each other and agree tasks for the day. If it’s working well the scrum master shouldn’t really need to get involved at all, especially in the technical aspects ?? At least that’s the way I woz learnt it.

With the new "multi-disciplinary" teams we have you might be the only one who is working on that piece of software or service. Within the general scope everything the team is doing is related but you can be quite isolated on your own tasks. Therefore the scrum master becomes the person holding it all together. This has been exacerbated by things now being done remotely.

Ex scrum master here. WRT the OP, that sounds miserable, but it's not supposed to be like that. In fact it really should be totally unlike that - one of the big benefits of agile methodologies is that it should empower the team (and individuals on the team).

To put it bluntly, I wouldn't want to work with a scrum master who didn't have a pretty good grasp of the technical details of the development work. I think they need to be someone who is capable of being a good engineer but with additional interests in team building and software process.

On the mechanics, scrum ceremonies are about what the team gets out of them.
* Standups, for me, need to be quick - 30s per team member is probably a good target - and informality and accessibility of follow-up conversations is important. You're not agreeing what the team is doing - you did that before the sprint started - you're just saying what you did yesterday, what you're going to do today, and whether there is any impediment that can be addressed by the team.
* Planning is a total pain if done meeting-heavy. I found it useful to do sprint planning activities semi-formally with engineers in ones and twos before planning meetings and make those meetings fairly quick and focused on formally committing to items and announcing them to the rest of the team. After planning the next sprint should contain a backlog of tasks for each person on the team for them to work through over that sprint.
* Regular retrospectives are vital and you have to keep improving and adapting to your needs or things stagnate really quickly. These can be really good for picking up what's working and what isn't for the team, but that depends on the personality mix on the team.
* Backlog grooming is important too, but I find it tedious beyond measure.

When I see complaints like those in this thread I wonder whether I am too harsh about my several years spent in a split role as scrum master and lead/senior engineer. I found it fundamentally unsatisfying to be honest on both fronts: didn't feel there was enough work on the team to be a worthwhile full time scrum master; also felt constantly frustrated by my limited time engineering things.

While I was pretty unhappy in that role, my team team were largely positive about the way we ran things, and I think felt about as empowered as they could be in the structures of that company (it was pretty far from agile a couple of rungs higher up the ladder). As usual, we ended up shovelling tech debt frustratedly, but clearly that's relative because we were putting out four feature releases a year despite it.

Ultimately I don't think agile is to blame for your predicament but I can totally understand that badly run "agile" is a disturbing new hell. The usual rules of engineering apply to this stuff too - if you think it could be better why not investigate the details and make it better?

In my opinion, Scrum Masters don't need to be technical. With Scrum, the Scrum Master is a facilitator with a responsibility (among many others) to ensure the Organization and Scrum Team adhere to the framework.

The daily standup is not a status update session. The Scrum Master doesn't even need to attend it. It is an opportunity for the Developers to discuss their progress towards the Sprint Goal.

There are a lot of events with Scrum (standups, retros, review, etc) but they shouldn't get in the way of Development Work. My first thoughts are that your Sprint is too short. That will be a lot of events to have in that period. I'd consider moving out to at least a 3 week Sprint.

Oh I get it, the only hard problems to solve are technical 🙄

(Clue: they are often the easiest. Try solving problems involving people)

I think it was more the point that technical people (myself included) often find ourselves in the position where if we want to keep advancing (aka earn more money) we have no choice but to move into management roles. Whether or not we either like the idea or are any good at it.

Anyway, my project's agile, and it's working really well with no micro-managing. We've also transitioned to 100% WFH without any major issues.

A lot of the issues with companies adopting SCRUM and other Agile methods is their expectations. They often think its the silver bullet to improve the performance and volume of output from a team, unsurprisingly this rarely happens.

I was a massive evangelist for SCRUM initially and I think done well can create an ordered and exciting way to work. However I am less so now as the majority of implementations are so flawed it creates more issues than it solves. How many times have people been told "This has to fit in this sprint"? How many people have seen sprint after sprint fail and then at the next planning session see people agreeing to another sprint that's doomed to failure. I know people will say thats the not the fault of the SCRUM process and they are right, its the human nature part that breaks it. However this can lead to a team that constantly feels its failing.

I am a contractor and every project and every company I have worked on for the last 12 years or so has used SCRUM. Without exception they have all suffered from this to some extent or the other. Some worse than others, in really bad cases it puts so much stress on developers they leave as they feel they are constantly failing to deliver what they are asked to deliver and feel pressure to agree to deliver it at planning.

Oh I get it, the only hard problems to solve are technical 🙄

(Clue: they are often the easiest. Try solving problems involving people)

Software development is essentially a people problem - it's right there in the first value of the Agile Manifesto "Individuals and interactions over processes and tools". @dmorts description suggests that this hasn't been given nearly enough thought in his company. The scope of the things that you have to do to create the right conditions for individuals to have the right interactions is what leads me to disagree with @molgrips that it is 'just another way of managing a project'.

They often think its the silver bullet to improve the performance and volume of output from a team, unsurprisingly this rarely happens.

Good point. For the Development Team, Scrum should focus on removing impediments and waste not on improving the "speed" or velocity. Focusing on velocity reduces quality and increases stress.

A lot of the issues with companies adopting SCRUM and other Agile methods is their expectations. They often think its the silver bullet to improve the performance and volume of output from a team, unsurprisingly this rarely happens.

Indeed, because Agile is about improving the quality and ‘fitness for purpose’ of the software, not the speed of delivery.

When Agile is used for BAU delivery as part of a continuous delivery process then it can mean features are delivered quicker than one of the more traditional methods, but it’s a by-product of the process.

It’s often the worst aspect to convey to a client about Agile when they ask when they’re going to get their delivery. The answer of “I’m not really sure, but when you get it, it will be what you need” doesn’t always go down well, and that’s when you need the Agile coaches.

I get the OPs feeling about being micromanaged. I’ve encountered it a lot (in over 20 years of delivering software using Agile and SCRUM). Developers are a breed who like being left alone to do what they do - I know, I was one. Even being asked the three questions in a standup gets some of their backs up. What the scrum master should be conveying to them, is that being left alone and just “building to the spec” is why Agile was invented. To improve communication and make sure what you’re building is what’s needed, rather than what someone thought was needed a year ago.

I would track the time you spend giving updates over a couple of weeks and feed that back to management (hopefully you have decent delivery managers/directors sitting above the PMs/scrum masters).

Not a big fan of Agile myself as it needs the business to engage properly but they often don't want to (or can't as are under-staffed) and it's more just something to say they're doing rather than actually gaining anything from it.

Yup, that seems to be the way with Agile - a lot more time telling people what you need clarity on and what you are planning to do (in between the various meetings).

I've done Scrum Master (although not done any for a year) and it is very much an enabler position. It shouldn't be micro-managing but more finding out what is stopping the team progressing work and working to get that blockage removed.

Agile does involve more meetings - but they should only be held if required, it isn't about having a meeting for having a meetings sake. It still seems to be a better approach for the vast number of things a lot of companies do than Waterfall is.

Right, we're pretty much agreed that @dmorts company is doing it wrong. Unfortunately, with this being about people and all, there aren't any easy ways that he can fix this. There are a few things that might be worth a try.
All of the issues that he raised are the sorts of things that can be brought up in a retrospective - and if they are doing Scrum by the book then retrospectives will be happening. That should allow a sensible conversation and identification of actions to make things better. Easy? Well, probably not, but it does have the advantage that you are working entirely within the process and therefore cannot logically be criticised for doing so.
Scrum says that the team should be self-organising - if you unanimously decide to work a different way, there is no one in Scrum who can tell you not to. But you should do some homework first - obviously you should all have read the 16 pages of the Scrum Guide, but I also I recommend reading The Agile Mindset by Gil Broza, and having a browse around Gunther Verheyen's website. Encouraging everyone to be better informed by running a book group or lunch and learn sessions can also work in some cultures.
Changing this will be hard - mainly because you have to get a whole load of people to first realise and then admit that they got things wrong. The ability to do this is a key differentiator between successful teams and those that struggle - for more detail on this look at the work Google have done on teams .

Good luck!

I've tried to be open-minded but it does feel like an excuse for the devs not to meet deadlines (TBH they had plenty before as well).

Doesn't help that our agile methodology is being implemented by an inarticulate buffoon who did a course for a few days.

I’ve tried to be open-minded but it does feel like an excuse for the devs not to meet deadlines (TBH they had plenty before as well).

Agile could help you understand why you're not meeting deadlines (if done right).

Agile could help you understand why you’re not meeting deadlines (if done right).

I meet all my deadlines, without fail. Journalists are trained to do that.

I have my suspicions why the dev team can't do it, but as above - we have an idiot implementing something a bit like agile - so that isn't helping.

I was reflecting on stand-ups and I realised something. Stand-ups with the current scrum master and the previous one are very much ticket focused. The SM will share the Kanban board, hover over a ticket and ask whoever it is assigned to "how are you getting on?" or even "how much time is left to finish this?". To me that is focusing on moving the tickets across the board, rather than being a light touch enabler.
In the scrums that worked a lot better, tickets were almost secondary at the stand-up. Devs came forward said what ticket(s) they were working on and if any needed moving into the next column.

It's a subtle difference, but if a task is dragging on or a dev is struggling, a scrum master asking those ticket focused questions can tip into micro-management. I now realise why a junior colleague really struggled and got upset, as every day he was asked "where is this ticket at?". He sat at home on his own struggling. It took longer than it should for other devs to realise and step in to help because the interaction was SM -> Dev, and not Devs as a group.

Also today, no stand-up in the diary because we have sprint planning later.... but it's not like day to day work stops because we have Spring planning.

How many people have seen sprint after sprint fail and then at the next planning session see people agreeing to another sprint that’s doomed to failure. I know people will say thats the not the fault of the SCRUM process and they are right, its the human nature part that breaks it.

It is, but that's why there's a published methodology - to manage that.

You establish your velocity during the sprint. This is what your team is capable of. You don't then put pressure on the team to increase the velocity, you accept this for what it is and factor it into your project timescales.

It comes down to what I said earlier - does your PM work for the team, taking the heat, defending them, and pushing back against unrealistic demands; or does your PM work for the bosses, seeing themselves as a driver who can pass the pressure downwards to get things done quicker?

Example 1:

Boss: This is taking too long.
PM: Sorry, but our original estimates were to short, we've learned about more issues than we were originally aware of because of X, Y, Z. We did highlight the uncertainty in the original estiamtes.

Example 2:

Boss: This is taking too long.
PM: (feeling threatened) Ok yes boss sorry I'll get my team to work harder.

In example 1 the PM is not only explaining the situation but is implicitly respecting the team. In 2, the team is not respected. If they say they are working hard enough, the implication is that they are not working hard enough, so they are therefore lazy. No respect, morale is crap, productivity down, misery through the roof. In these projects, if developers raise new issues they are accused of whining to cover up incompetence or laziness. I have been directly accused of this once - I tried to explain my problems, and instead of these issues being identified and worked on, the manager replied "I'm sorry but I don't buy it". I have never been more angry at work.. and believe me I can get pretty angry.

I've had PMs of both kinds, and inexplicably the distinctions in these two approaches never seem to have been brought up despite being absolutely fundamental to success whatever the methodology used.

Ultimately - most projects are fundamentally uncertain, but no-one wants uncertainty so they deny it. And then the are pressured to give optimistic results to make themselves look better, and then they are inevitably delayed. So this is we always read delays and overbudget about projects - civil engineering, internal projects, even video games.

Agile is meant to provide a framework to take all this into account. So that when your boss complains about a delay, you can explain and justify it by referring to metrics and data rather than just apologies.

I meet all my deadlines, without fail. Journalists are trained to do that.

Journalism is completely different to software dev. This is another corrosive issue in projects: "I can do it in X project (a different project with different issues, or even a different job) so why can't you?"

And TBH it's going to get way worse in the current environment with the enormous onslaught of new unfamiliar and immature tech we're having to deal with.

Software development is essentially a people problem

Absolutely this.

I didn't read this

I think it is a massive negative when you lose incredibly talented technical brains to project management (scrum masters or whatever you want to call it).

the same as you molgrips!

The way the whole post still reads to me is that management/analyst/people side is inherently less valuable than technical expertise.

If that's how it was meant, then that's bollocks. IMO. And I have worked with several primadonna devs or technical people with this attitude (a minority thankfully).

Granted, that view may be based on past experience of managers not creating the collaborative conditions onwheelgood speaks of, and basically piling pressure on and leaving the technical guys out to dry (I've seen this many times too!)
However if done right, those analytical and managerial positions can add a tremendous amount of value. Often someone who has come up the technical path is actually ideally suited, because they understand tacitly what a team needs, on order to make it productive.
I'm in one of those kinds of positions now (Architecture), having been an ex dev. I think some devs just don't understand the half of how difficult some of those non-tech positions are, and just see lots of people failing at it.
That is not the same as those positions being inherently lacking of value.

It is, but that’s why there’s a published methodology – to manage that.

You establish your velocity during the sprint. This is what your team is capable of. You don’t then put pressure on the team to increase the velocity, you accept this for what it is and factor it into your project timescales.

It comes down to what I said earlier – does your PM work for the team, taking the heat, defending them, and pushing back against unrealistic demands; or does your PM work for the bosses, seeing themselves as a driver who can pass the pressure downwards to get things done quicker?

I totally agree with everything you say there. However even the most enlightened companies seem to crumble under the commercial pressure and revert to type.

Even more so if you work in a seasonal industry, for example I worked in the Leisure Marine Electronics industry for a long time. If your product was not ready for the boat show season that was a big deal and if a month late you might as well be a year late. Also with some embedded products there is only so much you feature de-scoping you can do before the things does't even switch on 🙂

I have a real love hate relationship with SCRUM 🙂

Edited to add I lose track of the number of times I have said that our velocity would indicate that committing to this sprint would be dooming it to failure. Then listening to people tell me why that this time its somehow different and there were extenuating circumstances why we failed last time (and the previous 20 times). Its like people don't realise that doing the same thing will give the same outcome. I appreciate this is a problem with people not the SCRUM methodology.

Journalism is completely different to software dev.

I'm trying to think of an example. How about, you're writing up your story* but you can't finish because the underlying word processing software unexpectedly stops working because you're using a new font type. So to complete your task you need to fix the word processing software first then write up the rest of the story. But due to time constraints, the fix you did on the word processor will only last for while, it will break at some point, e.g. when you try to use another new font that the business want you to use.

That's a very common situation in software dev. Things can get expansive easily

*Sorry I can't think of better word, article, prose?

Journalism is completely different to software dev.

Agreed.

But the dev team are currently a year late on delivering a key part of the product, which massively affects my and others' jobs - both performing them and their continued existence.

I'm just venting really, but go ahead and defend some people you've never met and don't know anything about, if you wish.

I’m trying to think of an example.

Ok.. but I think the concept of a deadline is the real problem. As bazzer says, sometimes you really do have a deadline like a seasonal show, or say you have to roll out the timing and data platform for a sporting event like the Olympics. But in other cases, you just have to keep on going until it's done. When they build buildings, they factor in time for stuff like discovering archaeological remains - it's known about, and people can understand it. I really think that one of the fundamental problems with software is that most people just don't understand it. So when people explain the issues, managers often think they are just stalling. And this is because managers often do not respect the techies. They think they are just whining nerds. (Incidentally this is not the case in places like Germany - they respect the engineers, and consequently things usually get done well).

It seems to me that the companies that are feted for doing Agile well don't have extrinsic deadlines. Netflix for example - they can release features whenever they are ready.

The other big problem in software is the constant changing of technologies. In my line of work there are not that many experts any more, as whenever someone becomes an expert in something it becomes obsolete and gets replaced with something new!

Agile isn't about giving people deadlines, it's about establishing when you expect to hit deliverables.

I’m just venting really, but go ahead and defend some people you’ve never met and don’t know anything about, if you wish.

Why would I do that? I have no idea who you're even talking about.

I'm just discussing the issues that people can face. I've no idea if they pertain to your company. You might well have a team full of lazy whiners I don't know.

But the dev team are currently a year late on delivering a key part of the product

I'm not asking this as a confrontation or to defend or attack anyone, but it's pertinent - do you know why they're a year late?

do you know why they’re a year late?

I've had on several projects "This project is two years late!!!!!" to which my response has been "Okay, but I've been on this project for less than 2 weeks."

(Incidentally this is not the case in places like Germany – they respect the engineers, and consequently things usually get done well).

Interestingly, this may be the case for actual engineering, but it isn't true for software. Name me a great bit of software that has come from Germany... SAP? I don't think so. Because most of software development is not like engineering, it's a people problem, not a technical problem, and Germany has been slower than many places to realise that, largely for cultural reasons. Their close neighbours, the Poles, tend to be better at it, in my experience.

I’m trying to think of an example. How about, you’re writing up your story...

You're writing up your story, but you uncover a new piece of evidence, or you're given a new lead.

Do you:
a) ignore it, you've a deadline - although it might be pivotal and change your entire story
b) research it further and push the deadline out
c) make some sweeping statements about it without doing due diligence

(Not attacking journalism, nor defending software development, just trying to put it in a context that's comparable)

I meet all my deadlines, without fail. Journalists are trained to do that.

I got given a deadline of a week once for a "simple" code change. It took six months for the requirements to be rewritten after I pointed out how flawed they were. Now being a journalist I am sure you would have got it done in that week but as a lowly dev I can only apologise for my failings.
After reading most technical articles in the normal press (as opposed to technical press) I would suggest it is quite easy to keep to a deadline if there is no need to pass QA.

For the OP and more generally for Agile.
I notice there is the normal "you are doing it wrong" for any criticism of Agile. Which for me is the critical problem. If you have a good PM, dev team and business analysts they can make just about any system work satisfactorily. Once one of those is missing it doesnt matter what you are using you will start failing.
There is a definitely a problem of since scrums are trendy therefore do it even if the people running them dont really get the concept. Poor PMs/scrum masters/whatever will always have a tendency to try and micromanage especially if they dont understand what they are micromanaging at which point they just stick to the box ticking exercises and get in everyones way.

do you know why they’re a year late?

A mix of naivety, incompetence and poor management, IMO.

A mix of naivety, incompetence and poor management, IMO.

The holy trinity! 🤣

We're currently over a year late. Poor management is the root of the problem. Most of the people who make decisions and specifications don't know anything about software and the ones who do don't understand how our software works or even how it's supposed to work. They don't invite the people who do know about our software to the meetings.

In addition, I get the impression that management are too busy defending their own fiefdoms to worry too much about the actual product. The devs are always there to take the blame, after all.

If we could get rid of management we could probably make new releases every month.

Interestingly, this may be the case for actual engineering, but it isn’t true for software. Name me a great bit of software that has come from Germany… SAP?

I was on the early stages of a project to modernise a company's applications (thousands of them) from old versions of Java and app servers to new ones which includes a high degree of uncertainty - because they weren't our apps, and the people whose apps they were had long since disappeared. We were given a fixed budget which of course was far too low, it always is. We had a German guy on the team because he'd done the same thing in Germany, but he'd been hired as the expert on time and materials. Fixed price contracts say 'we (who really don't know anything) think it should take X time so make it happen I don't care what the issues are', whereas T+M say 'you do what you need to do, we respect your skills and views'.

Needless to say the project that hired good skills on T+M was a success, and the fixed price one was a fiasco before it even got off the ground because corners had to be cut and estimates artificially shortened. I was asked to estimate it, so I came up with a methodology for it. I was asked to shorten it for no reason other than they wanted to meet the fixed price. Seems pretty obvious to me that there's a huge problem with that.

A mix of naivety, incompetence and poor management, IMO.

Historical poor management leads to poor design which makes it much harder to work on the product, which means it takes far longer. This has long been known. So when there's an issue, devs can be blamed for being incompetent when it's really not their fault. It's like building your own car out of obscure customised components and using weird techniques and then complaining when your garage says it's going to take a while to fix.

Having said that, there are a lot of incompetent devs out there! But why does our industry depend on skills we can't find, and why does it put people with low skills or lack of experience in positions where they can't cope? I'm sure VW don't put Kwik Fit employees in charge of engine design and manufacture.

I get the impression that management are too busy defending their own fiefdoms to worry too much about the actual product.

We currently have more dev managers than actual devs...