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...
For me, Agile works well when tasks can be broken down into assignable chunks which can be undertaken by a multitude of people in the team as they have similar skills, knowledge, etc. Where it fails is when your team is comprised of multiple specialists attempting to do something that’s never been done before. Sure, in certain circumstances and for certain tasks, this can still work, but it’s largely the mundane tasks that are urgent, but not important that then take the specialists away from what they really need to be doing, but which is difficult to describe in a text box or update on a daily basis. The specialists feel the need to show that they’re accomplishing something and so do the quicker tasks rather than the deep thought tasks.
People who are pro-Agile always say "Agile works when it's done properly".
But it's never done 'properly'.
Because it doesn't work.
The specialists feel the need to show that they’re accomplishing something and so do the quicker tasks rather than the deep thought tasks.
For me, it's fundamental that it's team velocity, and you shouldn't be looking too hard at trying to track individuals.
People who are pro-Agile always say “Agile works when it’s done properly”.
But it’s never done ‘properly’.
Are you comparing it to communism?
Because it doesn’t work.
You are right, but I have 34 years of experience that tells me that it works better than everything we tried before. Somewhat like Churchill's description of representative democracy as the worst possible systems - apart from all the others that we've tried.
damn, beat me to it with the Churchill quote.
I've worked in agile, pretend-Agile, whatever you want to call it, since 2007.
Before that, I worked in the same field for 10-15 years.
And I have seen far more failed, abandoned, re-started, written-off, or just generally hopelessly off-track projects under Agile than I ever saw before it became the thing.
And far more highly capable individuals who are frustrated, unhappy, stressed, harried-to-the-point-of-bewilderment and probably burnt-out yet still determined to do a good job.
Just my observations; I'm not even trying to make a point beyond saying that if something can't be implemented correctly no matter how often people try, the fault is probably with the thing, not the people.
… a building project under Agile would see the roofer, bricklayer, electrician, digger driver, architect and plumber all turn up at once and told to start building, typically without first being told if they're aiming for a hospital, airport or block of flats.
Because it doesn’t work.
Just out of interest then, what's your alternative?
People who are pro-Agile always say “Agile works when it’s done properly”.
But it’s never done ‘properly’.
Because it doesn’t work.
It does. Loads of examples out there, I've been on a couple.
Does the alternative work? In software, most non-agile projects I've been on have been late, over budget and under-delivered too. So what does work, in your view?
