And the solution was: to restart the linux server. That’s a sad one. I didn’t even see the actual uptime when checking because my eyes went to the load of 156 immediately… -.-
But if you restart it you don’t know what was wrong…
(Yes, I know, sometimes it doesn’t matter.)
What is a small story?
How on earth can you spend 3 sprints on a “small” story?
We actually asked the admin who is helping run the system and he said that linux had gone into “OMG”- mode and killed some processes (I didn’t even know it would do that) and we should reboot it–or rather he offered to reboot it but my colleague was faster.
The thing that is running on there is our dev cluster for our elastic search… we’re assuming the re-indexing that happened during the nightly build on Monday somehow got off the rails.
Yeah, it can happen, I just like to poke around the flaming wreckage before I flush it all away.
I worked on a story before Xmas to add a huge chunk of functionality in a rush for a customer.
Looking at it fresh this year I noticed some bits that needed tidying up and left a list of suggestions. There was a bit of thinking but I envisaged the changes maybe taking a week max. It’s only a handful of lines in a handful of files.
Here we are 10 weeks later*.
Now I appreciate the engineer might not be familiar with my previous story but it’s extensively described and documented.
Half the changes he’s made I’ve asked him to either outright remove or at least justify.
In his recent performance review he was complaining that his work wasn’t challenging enough. He’s not been assigned any more work for the time being. Might be having a chat with our boss tomorrow.
There have been several points where I’ve considered taking the story off him. But I rarely like to do that. Wish I’d done it sooner as I’m sitting here now contemplating doing it.
*And the customer wants these changes urgently. We were planning on starting that process today.
I have realised working with our newbie that even though we have regular chats about work I need to make sure that he’s on the right path sooner.
It’s not something I thought I’d have to do with someone at the same grade as me. I’ve had zero engagement from that engineer.
Ouch. I mean it is hard to compare between projects and teams and processes and I know I can work on something for a good long while especially when the code is unfamiliar… but how did this not come up for 10 weeks? I mean the least he could have done is ask for help?
What exactly is your role here? I am not up to date I think. We talked about you changing roles, didn’t we?
I should add that he’s only working for us half of the time and working for another project the other half. So most of the time when asked why it’s not finished, the excuse is that he’s had interruptions from his other project.
I know that to be true to some degree.
I’m a Principal* Software Engineer but I’m also the Scrum Master so helping out our newbie has mostly fallen on me.
(I’m also our Design Authority and just avoided becoming the Project Engineering Lead .)
*We don’t have a Lead Software Engineer on the team, that’s the role above mine. We’re nearly all “Principal” with the exception of the new starter who is a Graduate Software Engineer.
Are these roles familiar outside of defence/engineering?
It’s a long story…
I am not working in an English speaking company nor have I ever done so.
But I know Principal Software Engineer or Principal Engineer is a common one.
My guess is Design Authority is often called “Architect” around here. Having that not be the same job as “Project Engineering Lead” seems weird to me though. So labels…
~
This senior dev sounds very much like me in the “old days” at my old job before my freelancer years. I had to juggle multiple projects while also being inundated by daily tasks that would now be handled by a dev-ops team. These ate a lot of my time without ever being tracked. The project management style was something-something-(V-Modell – Wikipedia) I don’t even know the English term for this process. Except of course it wasn’t really. It was all very much hit and miss depending on individuals rather than processes. And it happened quite a lot that the individual me was working on stuff all on my own and getting stuck without help and I could never quite explain why I wasn’t done with things. I just ducked my head unhappily and soldiered on… hoping to avoid any undue attention and getting through the day.
All of this changed when a friend told me they were now running their team with Scrum. I practically begged my team to try some of these tools–the Daily saved me–and from there changed how everything was organized and how we as devs interacted and stuff came to light that had kept us from being more productive… I worked more but with less stress after a while. What I needed, was a support structure and those tools gave one to me. It was so much better, I finally developed the necessary self-esteem I needed to quit
To me your description above sounds like someone needs help but this may be my particular view because of my own experience. You know this person and can no doubt judge this much better than I could.
However, if as you are the scrum master and have noticed this as an issue, I feel like it would be part of your role to bring this up with them in a way that let’s them express what they feel is going on and maybe from there you could find a solution together.
As for the new start: that should not be on you alone but on the team as a hole and be part of your sprints to onboard them.
Feel free to ignore my ramblings. It’s just reminding me of myself way back…
I assumed that you were the scrum master @tomm_archer. These seem like scrum master worries…
(my bad he said he was scrum master but my English was not up to the task of precise expression)
I’d love to know what I’m actually meant to be doing as the “Design Authority” but having been in that role for six months I couldn’t really tell you. Occasionally someone will come to me and ask me to make a decision since I’m the “authority”
More seriously, the way I see it is being responsible for the requirements and design and making sure that as they evolve, they evolve “correctly”. But also that we follow the right process as we do so. I also put my signature on documents to that effect.
For me “Design Authority” is a label like “Scrum Master” or “Product Owner” it’s not really a job title and doesn’t affect salary.
As for “Project Engineering Lead”, I could link you the job description but that might be doxxing myself slightly. The PEL (got to love an acronym) is essentially responsible for making sure the team produces something. Which is to say, planning, cost and schedule. They also do your normal “Team Leader” job, performance reviews, etc. Our “PEL” is also our “Product Owner”.
(A project may have multiple PELs each responsible for a team and feeding into a Project Engineering Manager. A PEM is not a Project Manager. Labels. Fun.)
Since the PEL is responsible for the engineers I’ll probably take it up with him in the first instance.
This engineer has been bouncing around projects for the last few years, having been kicked off one for reasons of “politics”. For the first little while after he joined us I was having the same issues as he struggled to stop doing work for his old team. He’s only recently picked up working for this new team, I’m not sure he’s been doing it for the entire duration of this story.
I’ve said it before and I’ll say it again, thank you for providing me somewhere that I can unload
Oddly, it’s called ‘v-model’ in english.
God, I don’t miss this crap.
Never met it formally, but it does appear as though it basically relies on the customer to know what they want.
I have only met the v model in a software engineering text, where it received a certain amount of derision as being booth too simple and too abstract to be meaningful.
I actually meant “buzzword formalized software development processes” in general. We have a pretty laid back “here’s my goal, here’s my metrics to see if it works, I will check in in a while” process, which probably doesn’t work for most people, but it’s delightfully free of story points, scrums, and sprinting.