Tag: Agile

Bedding into a new team

The merging

A few years ago, some team members had been moved onto other projects and we were left with two developers and one tester. I led the team, and it was a tough project which ended up getting delayed. The result was that some managers saw the delay as a failure, and others interpreted that we did a great job against adversity.

As the project reached its conclusion, our team merged with a team that managers claimed was one of the most successful teams. Additionally, my manager switched from Colin to Mary.

Mary said the initial plan was to merge the two teams, then we were adding 3 new developers, so the plan was to then split the team into 2 because it was too big. The other developer that I led actually moved to a different team.

Doesn’t really make any sense does it? May as well have added a couple of developers to my original team.

Mary criticised my leadership and made out that my team was a disorganised mess. Technically, Colin was the Technical Manager so was the equivalent of Mary’s role in this new team. I was the development Team Lead but I didn’t think I actually had responsibilities. I kinda think things just organise themselves really. I like a laid-back culture but would voice my concerns if I felt it wasn’t working.

I was actually looking forward to seeing how organised and productive their team was. I was good friends with a couple of their team members already and they always seemed to boast how productive they were, getting plaudist from external managers.

The first week

On the first standup, Dennis talks about a problem he was having for over 5 mins. I was thinking I would have interjected and asked to discuss at the end. In my previous team, I didn’t mind people talking off-topic because it was pretty much the only time you hear people talk. But at a certain point, I’d flag it and request we organise a separate meeting with anyone that is interested, leaving the other team members to go off and do work; which is even more important in a larger team. This team had a member assigned as “Scrum Master” and that’s his job to guide these meetings.

In one of the standups we were asked to estimate one of the items. Standups are for progress updates, not planning. Why are we planning mid-sprint?

Also during this Sprint, I saw that the team was working on items not assigned to the Sprint, and left unpointed (not estimated). Then when they do officially bring it in, they bring it in with fewer points because they estimate the remaining work; and ignore the investigation/prototyping work they had just done. So what happens to tracking their actual effort? They will be lowering their velocity working that way.

There’s another type of work item called “Spike” which is an investigation item. So if you know you have a requirement but have no idea how to implement it, then you can do some design/planning to make it clearer to estimate the actual item. This team was creating Spikes when they can’t recreate bugs and so I asked them what the idea was. The way I see it, instead of basically marking the item as blocked, you are creating another item to say it is blocked and then removing this new item when it is unblocked. The Scrum Master said he has no idea where the idea came from, couldn’t remember how long they have been doing it, but everyone has been following this process without questioning it. Weird.

Meeting Chaos

I got told to go into their shared Team calendar and add all the meetings into my personal calendar. It turned out they had multiple invites for the same meetings so it was easy to miss them. So instead of one meeting that recurs daily, they had 2 fortnightly meetings for Monday and Friday then another meeting which recurred weekly Tuesday/Wednesday/Thursday. So 5 meeting invites in total just for the stand-ups; then invites for a few other types of meeting. I ended up initially missing a Stand-up meeting when it wasn’t in my calendar which Mary made out was my mistake. The invites were also set to show the reminder at 15 mins before which I find really annoying. I like 5 minutes or just alert on start. So I had to then go through all the invites and change the timing.

Not the amazing organised process we were promised

With Mary micromanaging and boasting of her ability, and with a dedicated Scrum Master, you think every aspect would run smoothly and processes would be perfectly followed. I didn’t think I’d hear/read statements like this:

“it’s tested, it just needs a test case writing for it”

Tester
Dennis: "Did you log the bug we found"
Tester: "no mate"

How are we supposed to check the bug is on an older version when the test environments are all on the current version and the API often doesn’t work? This is ridiculous. Absolutely ridiculous. It shouldn’t be like this. We’ve never had this before

Mary

Stubborn Management

When it comes to code reviews, we have a rule that it needs to be approved by 2 people that weren’t involved in the work. We needed Dean to help fix a few of the remaining bugs since we were running behind schedule, but Mary blocked it.

“you can’t help because we need you to do the approval”

Mary

Ok, we need people to review, but he could have reviewed what the other team member’s wrote, and we can review his parts. It’s not a big problem. Also what is worse? Finishing on time but it’s not reviewed, or finishing late but it is reviewed? You have to be pragmatic.

During integration testing, shortly before release, I found another bug. Mary and the Product Owner decided they wanted to keep it secret from Software Delivery. Mary tried to blag it to us that: because the bug hadn’t been directly found from a test case; then it can be released. She was then insistent we release the software as is, and fix known bugs later. I thought it was technically unsafe to do so.

NO Mary. That’s not only not how it works, but I did find it directly from a test case, so you have just mugged yourself off.

my thoughts

why is she doing this? it just reflects badly on the company. her job ain’t to ensure a deadline

my old team member

“I’m not comfortable putting our feature out like this…we are removing items just to get something out on time. Is this even legal?”

Tester

It just seems like they are clutching at straws and giving any kind of justification to not fix it. It also sounded like they have beef with the lead of Software Delivery so are avoiding talking to him.

Implied Disrespect

For the remaining bugs on my project there were clear “easy” and “hard” tasks. Mary explicitly told me to do the easy ones and Dennis to do the hard ones. We are on the same level, just that she is chummy with Dennis and doesn’t seem to trust me.

When it came to hiring these new developers, she said she chose them simply based on how much they talked because she didn’t want people that don’t talk in her team. Which I felt was a dig at me. I tend to hate smalltalk and struggle to talk to people I don’t feel comfortable with. Not that I dislike certain people, but I think there’s certain people that I tend to instantly connect with and feel myself, whereas others I find more intimidating and it takes me a while to open up. I can talk a lot at that point but sometimes people’s first impressions are that I am too shy.

When it came to the inductions, the Product Owner, Tech Lead and Scrum Master were all assigned to the “Welcome Meeting”. Dennis was assigned the “Ways Of Working” meeting, then Tech Lead, Scrum master and Dennis were assigned as Technical Mentors. Me and my tester who had joined the team weren’t assigned to anything. You could argue we hadn’t fully integrated into the team but we knew the process and weren’t new to the company. We felt disrespected there, like we weren’t official members of the team.

Complains about autonomy 

During testing some of the remaining items, a bug was found, and I took the initiative and fixed it.

“we can’t keep working like this. You can’t keep finding bugs and fixing them”

Mary

She had berated us for not having many unit tests but that actually allowed us to work faster. She complains that I have made the decision to fix a newly discovered bug without consulting, but that also got it fixed faster. Then she was “really disappointed” that we had missed the deadline. It would have been worse if I hadn’t made these decisions.

However, the next day:

“Thanks both, efforts haven’t gone unnoticed with all this, I just feel bad for you guys it’s got so manic for so long”.

Mary

Performance Review

“You’ve got the ability to not be quiet”

Mary

In my end of year performance review, Mary says she has noticed an improvement since I joined the team. I think this is just coincidence and confirmation bias. I think she wanted to “manage” me and see an improvement; so that’s what she thought she saw. I was actually demotivated due to all the disrespect and had actually been taking longer breaks and finishing early.

Mary also told me that Colin told her what I said about her during the handover period. Colin is an absolute backstabber. What happened to talking to managers in confidence?

What I said to Colin is that Mary seems to try and micromanage. Constantly asking for updates, telling you to pick up tasks that you know you have on your To Do list. It’s like she doesn’t trust you to be autonomous, and then can claim credit for success because she has been controlling it the entire time – even if it would have had the same outcome if people were just left to manage themselves.

She also mentioned the tester had complained that I hadn’t had a call with him when he asked. I wanted to have a call but he was on a call for what seemed like hours. Then when he was free, I was busy so I missed the call again.

I actually thought she was rather positive and very friendly during the review; a change in mood that remained.

Closing Thoughts

It was a weird initial few months with that team. The hype of them being organised and productive didn’t seem to be true. Then I felt like I wasn’t welcome even though I was good friends with the main developers of the team, and had actually worked with the tester previously and got on with him.

I must have caught them at a bad time, because after the current projects were released, I didn’t notice much erratic behaviour from anyone, and Mary was never problematic again. What seemed like a nightmare quickly resolved itself and I have actually really enjoyed working with the team over the last couple of years. I suppose it could have been helped by the fact that Mary did take 1 year maternity leave and then we worked more autonomously. Maybe shows that these manager roles aren’t actually needed.

Neurodiversity Celebration Week

In recent years, my employer has been progressively promoting more “woke” issues, as well as some health-related content. Our recent internal blogs on Viva Engage have been about Neurodiversity Celebration Week.

“This week is Neurodiversity Celebration Week; a worldwide initiative that aims to challenge stereotypes and misconceptions about neurological differences. We want to use this opportunity to raise awareness of the experiences of neurodivergent employees, highlight the value of neurodiversity in the workplace, and provide tools and guidance to help all our people create an inclusive environment where diverse minds can thrive.”

I think it is a good idea to remind people that some people think differently. I’m unaware if I have anything like autism but I do often struggle when posed questions that are phrased in certain ways. When we first learned about Agile development, and started doing “Retrospectives”, some of the initial ones had obscure questions like “if the last 2 weeks were a chocolate bar, what would it be?”. My mind is just like “wut”, whereas everyone else on the team came up with an answer, even if they just chose their favourite chocolate bar and forced certain elements into it. “There were some really smart solutions to problems so I chose Smarties”. When I failed to answer many questions over the months, some people moaned that I wasn’t participating, but I just got frustrated with that line of questioning.

“These blogs perfectly highlight the fact that everybody, and how we each experience the world, is different. Depending on how our brains are wired, we think, move, process information and communicate in different ways. We all have a responsibility to create an inclusive working environment where diverse minds can thrive. Everybody should feel safe, supported, and able to perform at their best. Therefore, it is important that we firstly recognise an individual’s differences, and work to harness their strengths and talents whilst minimising the challenges they may experience”

I think some conditions do have strengths and weaknesses. As far as I know, certain types of autism can lead to some great ideas since they have a different way of thinking, but then can be awkward in different social situations. One person wrote a blog on their life and observations with autism.

Here are some key takeaways from their blog:

  • Autism is a spectrum, which means that everyone who is autistic can have a wide variety of signs and symptoms, and how it impacts individuals can differ greatly.
  • Everyone uses phrases that have subtle implied meanings. For people with Autism, the implied elements simply disappear, and everything can be taken at face value. So an example they gave was if they put a jumper on, and someone asks “Are you cold?” they would answer “no” because they are now warmer. 
  • Their responses to questions can often seem rude or abrasive, yet they were only literally answering the question they were presented.
  • If you ask many questions quickly, they will then present an answer to each in the order you gave them. They are insistent in processing all information sequentially, and will want to answer all of them.
  • Sensory overload: They despise being touched, they feel overloaded by background sounds, and will need to be alone to recharge after a long period of social interaction.
  • They often talk over people

I was looking on our Sharepoint for the additional neurodivergent resources. I came across some strange statements:

“Most neurodiverse conditions are classified as disabilities, but it is important to note that not every neurodivergent person identifies with a disability, to avoid stigma and isolation.”

Is it really possible to “identify” with a disability? Like the autism blog described, they didn’t want people to treat them differently but they acknowledge their social awkwardness, and understand others need to be aware of their traits in order to not be offended, or to try and adapt their line of questioning. I assume that is the point the statement was trying to make.

“Diversity is important for any organisation to develop, and understanding neurodiversity comes with huge benefits.”

That’s another one that needs more explanation. I think some people can come up with interesting ideas if they have something similar to autism, but a lot of other neurodiverse conditions are only negative. The way you “benefit” is to try to reduce the impact of the negatives. The statement by itself sounds like it is only positive to hire neurodiverse people, when that is not the case.

I saw a recent BBC article where the caption claimed that Down’s Syndrome is “an ability not a disability”. I get the sentiment, and that people often misunderstand the condition, but I don’t think anyone really believes it is an ability. I’ve seen a lot of this reframing in recent years: Things that were considered “mental health” conditions are now framed as normalised/part of someone’s identity, so is a positive thing that should be celebrated. Then not only is this mentality being pushed by mainstream media, it’s now being pushed from inside company culture under the guise of Diversity, Equity, and Inclusion.

16 weeks work

Some teams post fortnightly updates on what they have done on our internal social media platform Microsoft’s Yammer (Now named Viva Engage). No matter what they post, managers seem to respond with positive comments.

So here is an example. On team stated they had completed:

3 user stories. 1 dev investigation. Improved code coverage.

Then attached was there code analysis report which stated:

  • 0 Bugs
  • 0 Code smells
  • 100% coverage on 1 new lines to cover
  • 0% duplications on 8 new lines

I never know how to make sense of these stats. The duplications mention 8 new lines, but yet the code coverage mentions 1 new line. It can’t mean it is still to cover when it states they have 100% coverage.

Their video demo stated it was “Sprint 8” which means it’s after 16 weeks of work. They logged into their application and there are 2 buttons (not functional).

My Work

I’ve been working on a game in Unity and have also reached the 16 week mark. I have only been working on it sporadically. Early on, I might have worked a few hours and many days per week, sometimes working several hours at a weekend. Other weeks, I have just worked on it for 3 hours or so in one afternoon only.

I have written loads of code for the AI state machine. Your units can automatically move in a formation, break away in certain conditions. Then the defending group of units have their own behaviours, and work together in their own way. Some behaviour is configurable so I have the logic and UI for the player to change it. There’s controls for the cameras, game speed, pausing, save and reloading. A few options for volume and a few graphical effects. There’s some miscellaneous aesthetics such as animations, particle effects.

I am a single developer working fewer hours, and I have to play-test it myself. Compared to a team with a few developers, a few testers and different managers assigned – all working a 9-5 day, 5 days a week; and all they have is a menu and a title banner.

Hackathon Progress

Another comparison is to compare the progress of developers during a “hackathon”, or “game jam”.  Developers can often put together a prototype, or a fairly fun game within a few days…

Developers during hackathon: We built an entire application in just 3 days. Developers after hackathon: Adding that icon is going to take 3 weeks.

Mark Dalgleish

Conclusion

Recently, I’ve been thinking about this a lot. I think if you start with no code, then any code you write has a much bigger impact. You also don’t have to work out how it works alongside other code.

So the more code there is already, then the longer it takes to write. So if the Hackathons are productive, then you can write something fast. Same situation with my Unity game, and since I am working on it myself, then I have no one slowing me down.

The other reason why working on my own is great is that I can set the process. Due to the 90/10 rule, I think it is best just to get it 90% done, then move on. If you change your mind of how something works, it isn’t as big of a time waste. If it turns out to be good, then you improve it later, alongside other features when you are changing code in that area.

So going back to this original team who did 16 weeks work and got nowhere – even though it’s a new software product, and should be able to code fast – I think they are slowed down by their insistence that everything has to be perfect and has all the extras like Unit Tests. So they could get a feature 90% complete quickly, but then they are told to spend several days perfecting it for that last 10% of quality. Then they are messing around with non-functional stuff like the Deployment Pipelines and miscellaneous processes. When you are months away from releasing, I don’t see the point in dedicating so much time to how you are going to deploy it, so I have been 100% focussed on features and gameplay.

I think this could illustrate how process can severely slow you down, and striving for perfection can also lead to inefficiencies. I think my idea of “90% quality is good enough” could be a winning approach, then you can always perfect the features if you are ahead of schedule. If I keep working on my game, I will worry about how to release it when it is close to a releasable state (ie how to get your game listed on Steam).

Burndown Chart: tasks

Colin said that our Sprint Burndown chart wasn’t accurately reflecting the work done. He said we were overrunning with each Work Item which meant that we would have 0 points for one Sprint, then we get the full value in the next Sprint – which shows as a sharp drop on the Burndown chart.

I told him that’s how the Burndown charts work – but he said they want more accuracy. I argued further: If the requirements haven’t been met, then it’s not complete, so you haven’t added value to the software – i.e. you have made no progress.

A few days later, our Scrum Master had been in a meeting with him and was instructing us on his new process. Colin’s idea apparently was to add a “task” for each day and link it to the Work Item. At the end of the day, you mark the task as closed. 

I’m like “eeeeeeer wut”. So now it tracks your daily work.

I told her she must have misunderstood. Adding a task per day is just counting the amount of days in the week. I suppose if you take a day off, then you won’t count that day.

I questioned it, and she agreed that it didn’t sound right. So she goes back to Colin. No, he really does want a closed task per day, but also said to create a task even if you are on holiday.

Wut.

:all-the-things:

add tasks to all the things! 

So they want effort more accurately tracked, but are now just counting days, even the ones you haven’t worked. Surely if you create a chart, it’s just gonna be a diagonal line with no fluctuations.

What are we supposed to write for the task’s title and description? “Carried on working on it 7.5 hours”.

I just refused to do it, but the Scrum Master did the admin on my behalf. The idea lasted about a month.

I find that Burndown Charts often look unclear anyway. Here is one from another team:

So what are we even seeing here? The chart to the left shows Tasks, although the chart doesn’t seem to show the correct Completed figure – it shows as 0%. However, you do see the average is 46 which I think is per day – which illustrates the ridiculous number of tasks that teams were creating anyway.

The chart to the right shows User Stories but I think it’s not the number created, but the total points assigned. So one might be worth 1 point, but another could be worth 8 – it depends on how complicated the work is. I think this is a typical Burndown where the first few days nothing is complete because the developers are working on fixes, then the tester will get it in a few days. In the second week, more items are completed. There were even 4 points removed, presumably a change of requirement or maybe it was deemed redundant.

This is another chart that a team posted to boast about their progress. This example is a bit more unclear, but I noticed the Tasks Burndown (start 12th September) is not for the same time period that the Stories Burndown is (start 29th August).

The Stories Burndown looks interesting doesn’t it? It looks like only a small amount of work was done and then when it gets to the end of the second week, they add even more work. I did theorise that maybe they didn’t officially start the project until after 10th September but what does the 72% Completed mean? That seems to imply they are ¾ through their project. ¯\_( ͡° ͜ʖ ͡°)_/¯

Training

Cost

One of the software testers was saying that they have been asked if they are interested in participating in a C# Programming course, with the aim of gaining skills to possibly allow them to write automated tests.

My opinion is that a 3 day course probably isn’t going to teach them anything that a video course wouldn’t (such as LinkedIn Learning or Pluralsight which we have access to). Also, there’s plenty of free resources like Microsoft’s own websites.

I was shocked at how much the training courses cost:

  • Programming Foundations (3 days) – £2975.00
  • The C# Programming Language (4 days) £4425.00

Maybe these courses include some kind of mentoring (which give an advantage over online videos), but given we employ loads of developers, surely a couple of people would be willing to volunteer to run some sessions internally. It would be much cheaper as long as they can spare the time.

Earlier in the year, to transition to a different form of Agile development (SAFe), we were sending some Product Owners on a training course. But not all of them. The ones that were sent were expected to then train the others. Nice money saving tip there.

Agile Training

Even when you go on training courses, how much information do you even retain? We did hire a SAFe trainer to present to the entire department, giving a general overview, but it was about 3 hours long and I couldn’t focus because the content was boring.

A week later, I was discussing how we currently worked and wasn’t sure where some responsibilities lie.

Colleague: Why are the roles/responsibilities so blurred? Where are the clear definitions of who does what?
Me: If you turned up to the training and listened, then you would know...but I turned up and didn't listen

Another colleague said that the training apparently costs £900 for 1 person – and it was for everyone in the department. Crazy.

Compliance Training

Every year, we have to complete some basic training courses. It just involves reading pages of information, then completing a multiple choice test. We have so many of them that we basically do 1 or 2 per month. There’s often a few questionable questions that we end up having a laugh about.

Fire

“If you hear the fire alarm, wait a moment to see if it is just a test.”

That’s not the normal advice is it? I’m sure the previous training has always said that you should be told the exact time when a fire alarm test is going to be. Any other time you hear the alarm, then you leave the building promptly via the nearest fire escape. If you are supposed to wait, you may as well use that time to grab your belongings. How long is a “moment” anyway. It never stated how you verify it is a test.

Security

Natalia’s Instagram has been hacked. Should she change her password first, or tell her customers

Why haven’t the hackers changed her password already? If they haven’t, surely you need to do it before they do. It only takes a minute to change your password. Surely, that comes first, then you can tell your customers. The training said you should inform your customers first.

you don’t have to follow the same level of security for all of your accounts.

Is that even good advice? I mean, most people probably do it like that, but everything should be secure. If someone can gain access to one of your accounts, they may be able to use that to get extra information about you to help them hack into your other accounts.

It is okay to write passwords down, but not on post-it notes.

I’ll write them down in a book labelled “Passwords Do Not Read”. Seriously, what does that advice even mean? A good password is one you remember. But writing it down is probably better than not being able to get into your own account. Maybe that is the point but the course didn’t explain it well.

Me 14:57:
someone follows you into your workplace and asks you to hold the door as they have forgotten their access card. Should you stop and challenge them?
-to a fight
-Rock paper scissors
-to a quiz
-Pokemon duel
Paul 14:57:
LOL
Are they actual answers??
Me 14:57:
no, it was true or false

Work Environment/Health & Safety Training

Good posture requires you to keep your feet flat on the floor or on a footrest.

Don’t footrests make your feet at an angle?

I love doing training about good posture whilst leaning forward at an angle. I do find it hard to sit like the training implies. It seems unnatural to have everything perfectly straight. I tend to slouch and constantly change position throughout the day.

The air in your environment should not be uncomfortably dry – you shouldn’t find your eyes or nose drying out.

is that even a thing?

Welcome to this course on Display Screen Equipment (DSE).

“Take appropriate action to prevent ill health when using DSE”

Do we really need an abbreviation for that? Can’t it just be “monitors”. It makes it sound like we work with asbestos or some hazardous material. 

“Your wrist and forearm must be supported when using a pointing device”

I’m trying to picture someone using a laser-pen with their wrist and forearm strapped to a plank of wood.

There was a section on different decibels of various environments. Libraries are apparently fairly noisy…

Me 16:20:
which is louder, a library or living room?
Andy 16:20:
libraries are notoriously quiet
Me 16:21:
have you done this Health and Safety training?
the library is louder. Even a wooded area is quieter
Andy 16:21:
this sounds rubbish
Me 16:21:
what happens if you have the TV on
or is that with the tv on
because it's a lot louder than a bedroom
Andy 16:22:
there aren't any of those areas at work
maybe a 'wooded area' at a push
Me 16:23:
did you know a conversation is louder than an office?
Andy 16:24:
haha shut up now
Me 16:25:
well, that's one way of reducing noise!

How can a conversation be louder than an office when offices contain several conversations? Is it comparing a face-to-face conversation vs a silent office?

Later on, there was a question about why water is bad for electricals. Since it is multiple choice, some of the answers are a bit silly.

Me 16:32:
Water can increase the power of the electricity and cause the equipment to work too fast.
Andy 16:32:
haha
Me 16:32:
I once overclocked a PC by spilling a drink on it
we should log a ticket - "build server is performing slow and needs to be watered"
Andy 16:34:
do you mind watering our build server while we're away on holiday and feeding the Load Balancer?

Bribery and Corruption

There were various scenarios and you have to state if it is a bribe or not…

“An offshore agent was dishing out bribes”

I think you have just given away the answer.

“We uncovered inappropriate payments…”

Sometimes I think these training courses have no effort put into them. It’s innappropriate, so I would say it is a bribe.

There was a question where it says something along the lines of: “Sean happens to have a relative who works for your company, and Sean is bidding for a contract. The company wants to accept Sean’s offer because he has put forward the best proposal. Is there anything wrong with this?” Options are:

  • Yes, Sean should not have sent the offer because it’s unprofessional
  • We will look conflicted if we do any future work.
  • Not at all, provided Sean has the skills that we’re looking for

I selected the last option, but I was wrong, it is the second option. An explanation was provided “recruiting people who are related to employees, clients or suppliers is not prohibited, but the appointments must always be made on merit and in line with company policy.”

Wait…I was correct then. It is fine to accept Sean’s offer.

Environment Training

This last answer made me laugh:

Why is it important for our Company to care about the environment?
A) To increase our productivity and cut costs
B) Because the environment is an invaluable source of resources that are necessary for our continued business
C) To take part in the latest management fad despite it having no real benefits

MANAGEMENT FAD.

Renaming “Master” in “Scrum Master”?

During the Black Lives Matter movement, the “tech community” debated whether the “master” branch (in terms of source control) should be renamed to “main” or similar. This was then adopted by GitHub as the new default.

Recently, I wondered if the same debate was had for “Scrum Master” in terms of Agile Development. The “Scrum Master” is a responsibility to organise the Agile meetings such as the Daily Scrum aka Daily Standup. The scrum nomenclature was adapted from Rugby.

I found a thread on scrum.org which argued for and against, but the community definitely settled on keeping the name. The difference between a “master” code branch, and a Scrum “master” is that the Scrum Master is about mastery, and not a master/slave relationship. So it’s the same word but different meaning and origin.

Thank you for your input and we will pass it forward to Ken and Jeff. Please remember as Ken and Jeff have always said, the role of Scrum Master is one of Scrum mastery and not in any way related to being the owner of the team as the team is self-organizing and self managed. Scrum Master  a role and not a job title taken from the ideas of the master carpenter which dates back thousands of years.  GitHub on the other hand literally used Master and Slave meaning that one controlled the other. 

That said, a lot of things are always being discussed and considered and your courage to bring this forward is greatly appreciated.  

Eric Naiburg

I’m sometimes embarrassed to tell people what I do because of how arrogant or self-important I think my job title and role make me sound. Whether one agrees the name should be changed or not, public opinion on the word “Master” exacerbates this problem.

Simon Mayer

Piotr Górajek calls people out for virtue signalling.

I will put here a little different perspective. IMHO this is ridiculous to push for change words only for the sake of pushing for it. How do you come to an idea that one word, put out of its’ context, should be changed because of “racism connotations”? Each word have a lot of meanings

Piotr Górajek

The word master is clearly a person that masters the framework, a coach, a person that has a mastery or “expertise” on something. With this line of thinking why we do not rename the Master degrees from Universities? MSc titles should be renamed as well?

Alexander Leanza Bøhnsdalen

There’s a good amount of sense in what Alan Eustace says

I wanted to observe a couple of things.

It seems like most, if not all of us, engaging in this conversation, are white. On what basis can we evaluate the impact of the terms we’re discussing?

Changing terms/language alone will not eradicate systemic and institutional racism. And yet language and symbols are powerful. 

Language changes over time to accommodate shifts in cultural sensibilities. There are plenty of examples of this.

Personally, as I mentioned above, even before recent world events, I have disliked the term “Scrum Master” for some time. I have not found it helpful, and continually have had to explain what is, and what is not, intended by the word “master”. 

Alan Eustace

“Organizations choosing not to respond to #BLM in a productive way will cause negative perceptions ranging from being perceived as tone-deaf (best case); indifferent to institutional bias; or racist (worst case).”

Phil Bryant

I’m not sure on Phil Bryant’s view. It defintiely seems like virtue signalling, and I’d say it’s quite tone-deaf changing things that don’t need to be changed and drawing attention away from the real issues. People are protesting against police brutality and we are trying to rename Scrum Master into Scrum Facilitator or something.

Now consider a team with a white Scrum Master. Every day, the members will hear their leader referred to as their Scrum “Master” – unless we make a change. As Agile practitioners, “We value responding to change over following a plan.”

Phil Bryant

Now consider a team with a non-white Scrum master. WHAT ARE YOU GONNA DO ABOUT THAT PHIL!?

The problem with choosing another word is that many other words can also have some kind of offence if you really study them. Sean Hoegaarden says

Scrum Wizard will be a problem for the same reason as Master (KKK), Scrum Captain too (slave trade ships), Scrum Samurai is obviously cultural appropriation, the Scrum Alchemist has antisemitic reminiscences… I hope we will not end up with something like an Agile Clown…

Sean Hoegaarden

Can I suggest we go to the home of where the terminology “Scrum” came from – i.e. Rugby.

The key role in a Rugby Scrum is the “Scrum-Half” for example.

Mohamed Hesham Jurangpathy

Sorry, but if someone starts calling me a Scrum Hooker instead of a Scrum Master I’m not only going to be offended, but probably initiate some fisticuffs!

René Gysenbergs

In conclusion, if the name is deemed inappropriate or irrelevant by the community (and we need non-white people to be part of the decision, rather than white folk just virtue-signalling), then the Scrum community can look to change it. However, deciding on a new name that doesn’t involve cultural appropriation or cause any other offence – seems harder than first thought.

20 Patterns to watch for in your engineering team

Pluralsight have a free book “20 Patterns to watch for in your engineering team“

There’s no point in pasting the entire book in my blog, so I’ll just give the initial paragraph to highlight their ideas.

They are mostly negative ideas, or can be in certain situations. However, there are some positive ones such as “Bullseye Commits”.

PART 1 Work patterns exhibited on an individual level 

1. Domain champion

The Domain Champion is an expert in a particular area of the codebase. They know nearly everything there is to know about their domain: every class, every method, every algorithm and pattern. 

2. Hoarding the Code

This pattern refers to the work behavior of repeatedly working privately and hoarding all work in progress to deliver one giant pull request at the end of the sprint. 

3. Unusually High Churn

Churn is a natural and healthy part of the development process and varies from project to project. However, Unusually High Churn is often an early indicator that a team or a person may be struggling with an assignment. 

4. Bullseye Commits

This pattern is relatively common in most teams, but it often goes unrecognized: an engineer understands a problem, breaks down the project into smaller tasks, and submits code that has little room for improvement.

5. Heroing

Right before a release, the “Hero” finds some critical defect and makes a diving catch to save the day. More formally, Heroing is the reoccurring tendency to fix other people’s work at the last minute.

6. Over Helping

Collaboration among teammates is a natural and expected part of the development process. Over Helping is the pattern whereby one developer spends unnatural amounts of time helping another developer to get their work across the line.

7. Clean As You Go

A codebase is continuously evolving by nature, but it doesn’t evolve evenly across all aspects. A Clean As You Go engineer will notice and refine shortcomings even if it’s not essential to the task at hand. 

8. In the Zone

This pattern is exhibited by engineers whose work is, in a word, consistent. They have a knack for getting in the zone and shipping high quality work week in and week out. Their work is reliable and predictable in nearly every way. 

9. Bit Twiddling

Bit Twiddling is like working on jigsaw puzzle to the point where everything looks the same and you’re not making progress anymore. You might pick up the same piece, try it in a few places, rotate it, put down, only to pick it up a few minutes later. 

10. The Busy Body

The Busy Body is an engineer who skips all over the codebase: they’ll fix a front-end problem here, jump to some refactoring, then fiddle with the database over there.  

PART 2 Work patterns exhibited on a team-wide level 

11. Scope Creep

Intuitively, we all know what Scope Creep is — along with its associated risks. Still, there are plenty of different definitions for the issue so here’s what we’re focusing on:

Scope Creep (noun): a pattern
whereby the originally agreed upon
scope increases or changes after
implementation has begun. Often,
though not always, Scope Creep
happens incrementally and thus invisibly 

12. Flaky Product Ownership

Miscommunications between Product and Engineering can easily lead to Scope Creep. Flaky Product Ownership, however, can show up slightly different in the data and also generally requires a different approach 

13. Expanding Refactor

Expanding refactors happen when a planned effort to improve or revise a section of code triggers a dramatic widening of scope. 

14. Just One More Thing

“Just One More Thing” refers to the pattern of late-arriving pull requests. A team submits work, but then—right before the deadline—they jump in and make additions to that work. 

15. Rubber Stamping

Rubber Stamping is the process by which an engineer approves their colleague’s PR without giving it a substantial review. 

16. Knowledge Silos

Knowledge Silos are usually experienced between departments in traditional organizational structures, but they also form within teams when information is not passing freely between individuals. 

17. Self-Merging PRs

This pattern refers to when an engineer opens a pull request and then approves it themselves. This means no one else reviewed the work and it’s headed to production! 

18. Long-Running PRs

Long-running pull requests are PRs that have been open for a very long time (more than a week). A PR that doesn’t close in a normal amount of time (within a day) can indicate uncertainty or disagreement about the code. 

19. A High Bus Factor

“Bus factor” is a thought experiment that asks what the consequence would be if an individual team member were hit by a bus. 

20. Sprint Retrospectives

Retrospectives are a common practice that offer an easy way to continuously improve: take time to reflect, as an individual or a team, on a project, action, or occurrence

My Thoughts

There’s some good observations here, and the book does go into how to spot these aspects and what you can do to counter the negatives.

Where I work, we used to focus on having “Domain Experts” which is the “Domain Champion” idea. In recent years, I think managers have drastically swung the other way which leads to “The Busy Body” who knows a bit about many things but doesn’t specialise; so now we have the opposite problem.

There are a few areas where we still have a “Domain Champion” and they tend to get work related to that area if they like it or not. Even when it does get initially assigned to someone else, they take too long and then say “the deadline is approaching, I think the Domain Champion should do it”.

I always complain we don’t have many developers that are willing to do Code Reviews, or at least; do them properly, so you end up getting “Rubber Stamping” which is like having no review at all.

I personally like to “Clean As You Go”. It’s not a good idea to go far out of your way to change code that didn’t need to be changed. Doing so can dramatically increase the risk of introducing a bug and is “Scope Creep” since more areas now need to be tested. I do some “Heroing” from time to time, mainly because I do the most Code Reviews so I spot more opportunities to improve things, or point out bugs in their code.

Recently, with people quitting or moving teams, the Bus Factor has been severely lowered. Currently, I am the only Developer on the team, so if I take time off; then no work at all is getting done.

Change to avoid change

Where I work, we go for long periods with barely anyone leaving the business, then we seem to be hit with several at once. There’s been a few people leave recently when we announced we would switch from the standard Agile process to SAFe.

With this restructuring, some roles did change but I think it was mainly people that weren’t affected like Software Developers.

I was talking to one of my colleagues, and he said 

“Why are people leaving? it sounds like we will still be using the same technologies”

Developer

The thing is, Developers will leave if you make them use different languages, and Developers will leave because they want to learn something new, so you cannot win.

I think some people may be leaving because they don’t believe our new software will ever get finished, then they have used the news of the process change as a final trigger to leave.

It seems quite stupid to me though – a change in management/process often makes people leave, even though leaving means you are dealing with a new management/process anyway in your new company.

It happened when we moved from Waterfall development to Agile. It also happened when we moved offices, and we have moved 3 times; even though it’s always been 10 minutes walk at most to the new location. If you come by car, it’s not even a problem unless the parking situation is different.

“OMG IT IS DOWN THE ROAD, I AM LEAVING to an office further away”

Stupid staff member

I remember with one office move, I was in the new office kitchen and talking to a Developer who was leaving. He said “I’m sick of these office moves”. I pointed out that we were literally standing in the new office, so he has already gone through the hassle of moving. He said he was only here because he had to serve his 3 month notice period. Yet he was moving to a new job that was probably further away from his house, and would more likely to have more job pressure because it’s very relaxed where I work. Also, since we had moved office, you could essentially guarantee we would stay there for at least 2 years because of the building lease. At a new job, you will more likely have to move offices within that time period.

In my mind, a change should be an encouraging aspect to make you stay, unless one of the changes has a negative impact on why you liked the job. In my experience, it seems a lot of people don’t see it that way.

Crisis Meeting

Apparently my employer has recently made a big deal and sold our software to a large group of users, but the users now want to reverse their decision based on other customer’s opinions of our software. Not sure why this group of customers only found out these opinions after making the deal.

We had a meeting with the new Head Of Development to discuss what we can do about it. The overall aim is that we need to repair our reputation: fixing major bugs, improving performance, improving the user experience in general, and making it clear to our customers that we value their opinion.

He initially stated that he wants more bug fixes, especially performance improvements and delivered in smaller, but frequent releases. He states that the current process doesn’t work and we should ignore it and come up with a new one.

Sounds great in principle, and a desired philosophy of Agile Development. However, Release Management stated it wasn’t possible to update the entire customer-base so quickly. This is partially due to the way some users work, and some contractual obligations. Both of these problems pretty much come down to the idea of essentially wanting close to zero downtime, so they want to choose a specific time to accept our updates, and they like this to be around once a month.

So the discussion turned to the development side. It seemed we were in agreement that we need higher-skilled staff to target these important bugs (we love throwing Juniors at these important issues), and we would also like to work in Domain based teams. Examples of this team idea is that you’d have one team that exclusively handles the Reporting module, and another handles Registration module etc. This way you can have a fuller understanding of all the configuration, features and the codebase; so can fix/enhance the software faster. Essentially you specialise, rather than going with the jack-of-all-trades master-of-none style. We also wanted more Testers since some teams have produced a lot of fixes recently but the Testers couldn’t get through it. To be honest, I expected that some Testers were just working slow and the fix isn’t necessarily to throw more staff members at the problem (just have a stern word).

The response from the Head of Development was that “the business” has decided on the team sizes and who is in those teams – and they won’t change. 

So to summarise – we are asked how we can make dramatic changes to the way we work, ignoring the current process… then get told we can’t do our ideas. We’d shot-down his suggestion, then he shoots down ours.

I think he shot down our suggestion because he is too focussed on the current process and structure, and he isn’t taking his own advice by ignoring it and coming up with a new idea. To be honest, it is easier said than done, and I think his way of thinking is – how to preserve the current in-flight projects? You can’t simply restructure the entire department without dealing with the current projects.

What you can do is just make the current project teams bigger and let them take the project and some bug fixes. With a bigger team, they can easily carry on with their project work, and with the extra people, they take on live Bugs, fixing “Technical Debt”, adding more automated tests etc.

I get confused how we get told these “Service Improvement” teams (teams that deal with bug fixes only) are the most important, yet it’s the Project teams that get the most experienced developers and the most attention. He has limited the “Service Improvement” teams to 20 developers with only 4 with Senior rank, one of which isn’t good enough to be Senior. Then most of the other developers are essentially Juniors. 

How can you deal with important bugs with a lack of talent? It’s frustrating that he arranges a meeting to ask how we can solve our way of working, but then he doesn’t listen to the feedback.

If he wants a quality product and to deliver faster, then we need the staff and process to actually achieve it.

The Changes #1: Attempt To Replace Manual Testing

When it comes to Testers, we have hired some fairly non-technical people as “Manual” Testers, but then on certain recruitment drives, we have hired “Technical” Testers which performed manual testing but also have the scope for Automation testing.

When we announced that we would soon be starting projects that will build our next product, managers stressed the importance of defining new processes and upskilling with new programming languages. Moving into the “new world” where you expect things to be automated; there isn’t much need for non-technical people.

I did warn one of my Tester friends about this – that his days could be numbered, but he didn’t listen. He waited for several months, and then seemed to think “damn, I’d better get learning because there is literally no work otherwise“. Meanwhile a few people requested a promotion so they can be a manager, which is unfair really; but there’s always people that benefit from restructuring.

Anyway, another year has gone by and the projects have been a disaster. I don’t think they really went through with their “no need for manual testing” approach, although some people did move back to support the existing product to do manual testing on a familiar product.

In comes a new CTO and a new Head Of Development, and now, yet again, their new idea seems to be 100% Automation. 

I expressed my concern to my manager. It didn’t go to plan last time, and you may find that some manual Testers simply leave the business since they have no plans/desire, or might not have the ability – to do automation.

Earlier in my career, I used to do manual testing and it soon became a tedious and boring job. If you actually find people that do it for a career, then they are probably worth keeping around. In my opinion, you always need manual testers.

Another thing is that you are assigning an inappropriate job title to those people. The automation testers have the weird job title of “Developer In Test”. If you are currently a non-technical, manual “Senior Tester”, how can you suddenly be a “Senior Developer In Test”? This implies that you not only have technical skills, but you have achieved Senior level in it. It’s a joke. Demoting the Senior to the basic “Developer In Test” would make sense but would probably cause them to be disgruntled and leave.

When I previously wrote about job titles, I used Colin as an example. I’d say he was an underperforming Developer, but got promoted to Senior. Simply calling him a Senior doesn’t mean he has better skills. Then another couple of years pass, and somehow he gets promoted again to Principal Developer. I wasn’t happy about that, and questioned my manager. He could only explain it as “we had a vacancy and a strong need for a Principal in the team”. But if Colin was already in the team, what good does promoting him to Principal do? He doesn’t level-up like a computer game character and gain extra productivity, coding skills, code reviewing skills and leadership. We needed to recruit externally to add another person to the team, but also increase the skill level.

So with these new changes, I asked my manager, “why are we changing job titles?” and he said “we are following a new Agile framework that the CTO is implementing”. Surely we can still follow the framework without copying job titles word for word? All it does is cause some staff to be disgruntled.

When another manager was explaining the team structures, he said

“there’s a thin line between “Software Engineers” and “Developer In Test”

Manager

He said that means that Developers can help Testers but then seemed to struggle how to justify how Testers can help Developers – because it turns out they aren’t actually the same.

Conclusion

  1. New managers like Heads of Departments or CTO’s love making changes.
  2. 100% Automation is a dream. I think you always need Manual Testers.
  3. Changing job titles can cause people to become disgruntled.
    1. It could feel like a demotion.
    2. It could feel like more responsibility for the same pay.
  4. Assigning a job title to someone automatically doesn’t give people those new skills.
  5. Testers don’t have the same skills as Developers.