“What interaction have you had with varied stakeholders?”

One of our apprentices said he needs to fill in an “evidence” piece which questions aspects he has experienced on the job. Since he has mainly been studying for exams and filling in forms, he hasn’t had much chance to actually do any real work. So he wanted me to help him come up with ideas of what he can write about.

I don’t think we have that much interaction with people outside the immediate team really, but it really depends on how you interpret the question. I guess this particular question is just about stakeholders which includes anyone with an “interest” in the software.

I always thought it was annoying when we got asked questions like this on appraisals; usually the focus being on people outside your team/department. It’s not part of our job really, since we have a hierarchy so you would just get your manager/team lead to either arrange a meeting, or perform the action on your behalf.

The key thing for developers is to raise questions about requirements with a Product Owner. So if the requirements aren’t clear, or your investigation has uncovered new information – then the solution isn’t as simple as people imagined it would be. Then you could then agree on changing the requirements with the Product Owner, or creating a new “work item” with the additional requirements to implement at a later time.

Maybe you would need to talk to an Architect to come up with an overall solution to a complex problem.

Sometimes we email the UX team for UX designs or to ask the Technical Authors to write us a nice user-facing message to display in a dialog box.

Ideally, in a perfect world, these things would be alongside the requirements since you would think there would be a process before it comes to us. But we never really work like that.

In a recent project, the requirements were vague anyway. It was more like “Feature doesn’t work for certain users” …they want to select a Proxy user and that user’s details are sent in the message. So I made those changes but then you realise that they could want to use the feature, but maybe haven’t configured it correctly. So you need to tell the users. So I’ve put in a message box to tell the user certain config is missing from their user. I’ll need to get the Technical Authors to write the actual message. It should also be confirmed by the Product Owner that they want it to work like that.

A Tester then found another potential issue and suggested we add a default behaviour in a certain scenario, but that would be something the Product Owner decides. Do you want to switch the default, or do you want to just tell the user this method is invalid, and they have to manually switch to a different method? But then maybe we would want to ask the UX team what they think the user flow should be.

I guess the conclusion here is that it’s always hard to know exactly what the system should do. You end up having some requirements but then when you implement it/prototype it, then you realise that there are other scenarios that you should also take into account. So sometimes it is an iterative process: there is a bit of back and forth with the conversations between these stakeholders.

Haven’t done a weeks work

I’m currently finishing off a project where we have been assigned a new Project Manager. She hasn’t made a great impression so far.

The Testers haven’t been available over the week, but personally, I did complete the development on 3 items that I’d estimated to be 8 days work, so really that’s 1.5 working weeks of work. So in my mind I was ahead of schedule by half a week.

The Testing hadn’t been done, so we hadn’t fully completed the items, so technically, we get 0 points there. However, I was ahead from my side.

Then in our project meeting (which the Testers also couldn’t attend), the Project Manager stated that she was very disappointed because “we haven’t done a week’s worth of work”.

I told the Testers what she said and they were outraged because they felt “it wasn’t her place to comment”.

A few days later, she sends me a message like:

“could you please quickly pop intot eh knban BOARD AND MAKE SURE YOU HAV PU SEOM NUMBER OF DAYS AGAINST EACH OF YOUT ITEM SO I CAN SEE HOW LONG SOMETHING TOOK ETC”
Project Manager

Did she type that without looking at the screen? So bizarre.

How To Make Your Team Hate You #3

I was thinking about the colleagues I’ve legitimately despised (and it’s not just my opinion), and most of them have something in common: they have either been promoted, or told they will get promoted if they prove themselves, resulting in a change of behaviour. So here is story number 3, and hopefully the last one since I don’t have any more drafted up.

The Situation

I was once on a project where I was the only software tester. Usually, when it’s a proper project where it is going to span 3 months or more, then we would have at least 2 testers assigned.

I was well excited to show that I could handle this responsibility. The project went well, and I was well proud. That project was actually a prerequisite for something bigger, and yet again, I was looking forward to the challenge of the follow-on project.

Collectively, both projects were going to be a replacement for part of our software, but it was going to be phased over time. Therefore, it was important that the old version still worked.

So I looked at what the current system did and wrote all the features down. I then spent ages looking through all the Test Cases, comparing these to the features that I documented. Then I had to write the Test Cases that were missing. This probably took around a month of preparation.

Since the new version needed to do what the old one did, but might have done it in a different way, I basically had to duplicate every test, then start changing the steps accordingly.

Having this 100% complete test coverage worked well, and I knew people would be thankful for it in the future. Anytime a feature is changed, you know there are tests that you can run for your manual regression tests. I think every tester has been annoyed at some point; when they think a test should exist, but it doesn’t, so they have to begrudgingly write it.

I’ve done the work for them. I don’t think any other area of the system had this level of test coverage. No one can be annoyed about this can they?

As we moved onto the second project, I was told another Tester, Barbara was joining the team. I’m not sure if I was told explicitly, or if I just heard rumours, but I’m pretty sure I knew it was the case that – if Barbara did well on the project, then she would be promoted to Test Lead. Based on my performance over the years, and based on the project I had just finished, I think it should have been obvious to promote me to Test Lead. Maybe I was slightly annoyed, but I don’t think that had any affect on what happened next…

The Conflict

So Barbara joins the team and looks at the test cases. She wasn’t happy. Despite having that 100% test coverage, the tests were “too granular”. She says that when it comes to testing a particular feature, we would end up adding maybe 10-20 tests from my pack. She only wanted to run 1 or 2.

So she starts complaining at me, telling me I’ve wasted my time and I need to rewrite them. She likes the idea of “end-to-end tests” where one test actually tests several features and could describe what a user would do over a 5 minute period.

For example, I may have written a test that describes how to create a document, then another test how to print a document, then another test on how to email a document.

Her way of testing would be to include all the instructions for these 3 features and put them in one test – since a user may log in, create a document, email it to someone, then print a copy out for themselves.

I argued that my way is better, because if there is a bug involving email, you can just pick out the short test involving email. I’d be annoyed if I had to test printing it when it has nothing to do with the email bug fix.

“But that’s not how we did it in my old team!”

Yeah, but you aren’t in your old team. You’ve joined this one, and this is our process.

She used this statement multiple times about different aspects of how we work. I kept on explaining how if we work “agile”, we are supposed to come up with a process that suits us, and agree as a team. This process suited us, or at least it worked perfectly well before she joined our team.

Yet she comes in, kicks off a massive fuss to try and put her stamp on the team, and bypasses the correct channels for these decisions; which would have been the Retrospectives. I would have been happy to debate it in a meeting, rather than her dictating what I should do in front of everyone.

What Barbara did next was – run off to her manager, who happened to be my manager as well. But because my relationship with my manager was simply a professional one, and Barbara was very chummy with her, then our manager instantly backed Barbara.

So then I had to plan out which features made sense to use after each other. I spent 3 or 4 days planning this out. I spent more days writing them. I only wrote about 7. How many test cases did she write?

Zero.

Didn’t practice what she preached.

I was fuming.

When it came to testing the new features, she often volunteered to test the easier items, and gave me the harder items. I didn’t mind, because if she wasn’t on the project, I would have just done them all anyway.

What was infuriating, was that the next day, she would chat some nonsense about how she was too busy so didn’t have time to test it, so then asked me to test it instead. So I’d end up doing all the work. It’s just that it would take longer because I’d finish my work and have nothing to do, then the next day, I’d have to do her work that she was supposed to do. So the result was that we had 1 extra tester in the team, but productivity had halved.

She did this for weeks. It wasn’t a one off. Often, I’d look at her monitor and saw she was sending personal emails, doing online shopping, or just looking at news.

Then when it came to the stand-ups, where we stated to the rest of the team what we had accomplished; she then claimed that she did the work.

I was fuming. How could she say that when I was standing there with her? It’s plagiarism, and absolute lies. I complained to my manager. She refused to do anything. I was so tempted to walk out.

I’d never had that feeling of not wanting to go to work before, but some days I just didn’t want to go. I actually started looking for new jobs.

Sometimes when Barbara was away from her desk, I’d be ranting to my team. We were a close bunch on the initial project, but it just didn’t feel the same way. Soon I was brought into a meeting with the project manager who seemed to suggest I should apologise and try and get on.

I don’t get it. We were all close and worked well together. We delivered a project successfully on time. A new team member joins. Testing productivity is halved. There’s massive friction. Who do you think is the problem? You could easily verify my claim that she wasn’t doing the work. The test case runs are audited. My name would be on every one.

It seemed that Barbara had just sweet-talked everyone and they were determined to promote her regardless. As a Test Lead, you are supposed to have testing skills, people-skills and some management skills. Barbara wasn’t showing any of it. She was refusing to run test cases and she was causing friction. Productivity of the testing side was lower than when it was just me on my own.

Epilogue

So what happened in the end? Well, I was a bit unsure what I wanted in my career. I initially wanted to move up the ranks as a Tester, but it wasn’t happening. I did get the craving to be a Developer, and considered becoming an Automated Tester. I requested a change of role to a Developer since the Automated Tester role didn’t exist in the company. I’d be in the same department, but I knew I’d switch teams so would be away from Barbara. I just had to put up with another couple of months working with someone I despised.

I did get my internal move in the end. Barbara got her undeserved promotion. Years later she got made redundant. Better late than never.

For more in the series, see: How To Make Your Team Hate You #1 and How To Make Your Team Hate You #2

Shelving, failed restart, then restarting a project

When we entered lockdown, there was a small project that was identified as urgent, and very helpful to our users due to the current situation. Originally, they estimated a simple change. So we make a change to one file. When testing it, we realise it didn’t send the information in the outbound messages to a third party. So we made further changes which were a few day’s work.

We then had a meeting with a few different types of managers. They wanted to know about our progress and they wanted estimates to finish the project. I thought it would only take a few weeks to test. However the Tester said it would take 3 months which I think he was just being extreme to cover his back. He did explain it was more complex than I had thought, but still – it was clearly over exaggerated. The Managers didn’t like the idea of having a Tester tied up for that long, so the project went “on hold”.

Months later, I was invited to a meeting to restart the project. A Project Manager was ranting that there was a financial incentive to get the feature out by the end of the year (2020), but if we deliver it late, then we miss the bonus. Even if we restarted straight away, we had left it too late – there was no way the testing could get done, and deploy in time to meet such a deadline.

The Tester stressed that my solution is just a prototype and needs to be reworked. In reality, it was fine as far as I was aware, but he was just buying extra time if we needed it. It was the Testing side of things that needed the focus. We needed to test these extra configurations, but a prerequisite was that we needed to understand how they were set-up.

I couldn’t really do much work until the Tester had done this extra testing to see if my solution covers all the different configurations he had come up with. However, the Tester was busy with some other work so he couldn’t do that for a few weeks. A few weeks later, a Product Manager messages me to ask when the project started. I delivered the bad news: “It hasn’t”.

A few more weeks go by, and we have a meeting with a new Project Manager. So we discussed the story so far with him. It was also announced that the Tester (who has all the knowledge about this project) would only be partially available – so needs to pass on his knowledge to another Tester.

Another week or so goes by and another meeting was arranged. We have a new Project Manager.

Ridiculous.

She starts making all kinds of demands about having all the usual Agile process. (User Stories with estimates etc). However, it’s a weird project because we have basically done the development and we just need to test. All this process seemed a bit overkill to us.

We had another “Project Kick-Off” meeting, and the Tester asked the Software Architect about setting up all these different configurations. The Architect then said the Tester had misunderstood and there was actually only 1 configuration.

This meant the testing time had been drastically slashed – you know; the exact reason why the project was delayed in the first place. So all these delays, extra meetings talking about the delay, all the meetings to rearrange the project; none of them actually needed to happen. We could have just completed the project when it was first assigned, additionally collecting that financial bonus.

Estimates Meetings

There’s a meeting that (I think) happens every week, where projects/enhancements are discussed and estimated. I don’t think there is enough time to really discuss them in great detail, and the people in the meeting don’t really care because they won’t actually be developing and testing them.

The thing is, it’s quite hard to judge how long something will take even when you have a decent understanding of the requirements, because you don’t know what the current state of the codebase is until you really start to dig into it. Also, you will uncover multiple problems and come across things you never considered earlier.

I think the key thing to remember is that ‘estimates’ aren’t supposed to be exact and are only based on the knowledge you currently have, plus additional time for contingency.

Even considering that, I think most people struggle to come up with estimates – even people that are regulars to the meeting and should be experienced at it.

One day, I received a message from my manager asking me to join one of these meetings. The meeting had been going for 10 minutes or so.

I join the call, and my manager tells the Host to re-explain. I felt awkward, he probably had done a great 10 minute explanation, and then they somehow decided they need my advice. So the Host reexplains. I ask a few questions, in particular about some previous functionality that had apparently been rolled back. I wanted to know why it was rolled back rather than fixed, because that would be key in coming up with an estimate.

My manager decides that we need the previous Product Owner on the call. She joins the call, and my manager asks the Host to re-explain. This is definitely awkward now. You can tell the Host is so frustrated, and he audibly sighs before explaining for the third time.

Now the group should estimate collectively, but everyone seems to want me to estimate it by myself. Why does everyone think this is a hard one to estimate? I end up being vague and saying it was 1-3 weeks. The thing is, they usually want the estimates to the nearest 2 week period, so 4 weeks is a fine estimate. I try to push the others to suggest their own estimates. The group decides it is too hard to estimate so the Host needs to come to a future meeting with more information. He must be fuming.

I get invited to next week’s meeting. There’s 2 projects to estimate – this time brought by a different product manager. This new Host says the first project was estimated a year ago, then put on hold. It was given 16 Weeks at a “high confidence”, however, there’s no notes to explain how they came up with that figure. But it is “high confidence”, so unless we know of any complications that have happened over the year, maybe we could stick with that?

Judging by the small amount of notes and screenshot, it looked like a few day’s work to me. One person says there’s some “cross-account functionality which is against the current architecture”. So now we are all scared. One manager states: “There’s too many unknowns, so let’s come back to it”.

So the Host moves onto the next project. It’s quite complicated and requires a good 10 minutes of explanation. When she got near the end, I thought “I hope we don’t estimate it; it will be a right laugh.” When she concludes her amazing speech, we decide “we need to break it down – it’s too big”.

So that’s 2 hours of meetings to estimate 3 projects and we didn’t estimate any of them. Good work team!

How To Make Your Team Hate You #2

We were in a newly formed team, and Rob was a newly promoted Test Manager. As developers, we were planning on tidying up the code base, formatting the code consistently, and removing unused code.

There wasn’t any real testing to do, given the code was unused, but Rob insisted we spend time investigating how to test the code.

It didn’t make sense – how can you test some code that isn’t used? Unless you prove it somehow is used, of course. But if the developer could tell the tester how to prove it is used, then the developer would know it is used, and wouldn’t remove it.

For the actual, real, development work, Rob demanded that we come up with a full test plan for every planned piece of work before we are allowed to make any code changes.

The thing is, even though I know the overall aim and could explain some test scenarios up front, I will always suggest more tests after I make the code changes. After I have made the changes, I am familiar with other areas of the system it impacted, or extra changes I made to refactor the code. So it only would be a temporary plan anyway.

Once we made that point, Rob then said we should analyse the code, plan out what code changes we would make, including refactoring, and document them. When all items are documented, we could then start work.

Who agreed in the team? No one. Not even other testers. Yet, he then runs off to higher ranking managers and persuades them that it is a good idea. I think they were just good friends with him, so they backed him.

We ended up spending ages working out what we were gonna change, but then not actually do it; because we had to plan every item first.

When the time came to actually implementing our plan, you then had to spend time re-familiarising with the solution and then verifying if the proposed solution was actually accurate. The person that did the planning may not be the person to actually implement it.

We ended up being 2 months into the project and not a single line of code was changed. When we started doing the work, the “familiarising” process just annoyed people. From the start, we had stated that the entire process was dum, we were annoyed at the extended planning time, then the actual development stage just reinforced how dumb the entire thing was.

I don’t know if anything happened behind the scenes, but Rob was moved off our team at this point, and it felt like a huge weight off our shoulders.

I don’t know what Rob aimed to achieve with his idea. I think he thought it was a process that enforced quality, but he was unanimously told it was a bad idea, but yet fought to get it implemented. Surely if the team is fighting against it, then dictating that they implement it is just going to cause so much friction – that your position is going to be untenable. And it was.

The lesson here is that if you do get promoted, make sure it doesn’t go to your head. Yeah, you have to manage people, but having a new fancy job title doesn’t mean you have to go wild. You are working with people. You are still working with your old colleagues. Treat them with respect and be more understanding. I think a lot of managers gain respect by being nice and leading by example.

August Retrospective

As part of “Agile Development”, you have a meeting called a Retrospective where you look back on things that have happened over a certain time period (like two weeks), and say what happened, what went well, and what didn’t go well.

When we worked in an office, we booked out a meeting room and wrote on Post-It notes and placed them on a whiteboard. Since we are working from home now, we needed an online solution. We used the Retrospective board on Microsoft’s Azure Devops; which worked well.

There were a few interesting points I wanted to note down. One point I strongly agreed with, and the other two points I think either: I am deluded, or the rest of the team are.

“Part time Product Owner”. When our team was formed, we were told our product is really important. If it was important, we would have the correct staff in place, with a Product Owner in charge of providing us with requirements, or making decisions on well-defined requirements. At first, we didn’t have a Product Owner. Then later, we got one, but she was split between two products and we were always low priority. Due to this, some of my work ended up being shelved because I had implemented the requirements I knew about, but I knew there was much more to it, so raised questions that were never answered.

“Need to stop working at pace, otherwise we will all burn out.” This is absolute nonsense; we are so slow. This is basically a reference to what the Head Of Development said in Team Summary, but other managers have used the phrasing “working at pace”, so now people in the team are regurgitating it.

“Code Analysis work going fast” First of all, the people responsible for analysing the data were dragging it out as long as possible, see The Code Analysis Meetings (It’s a great read [if I’m allowed to promote my own blog]). Also, Colin has been leading a small team to actually fix these “problems”.
A) they are making changes manually and progress is slow. The changes are simple, and they can get Visual Studio to fix them without extra input.

B) Colin was taking days to review them, so I ended up stepping in and reviewing the code for him.

Bonus Chuckle

We get to the end of the retro, having gone through the full board. The final stage is to vote on the items that are suggestions on what to “do”/”stop doing” in future.

“I can’t see my items on here”
Becky

It turns out she has added her items to another team’s board. 🤦

I don’t get how we can go through the ENTIRE board and only then does she realise that we haven’t talked about the four items that she added.

Shape Up

A bit of a rarity on this blog; time for something positive.

I have been reading the book “Shape Up” by Ryan Singer which can be downloaded free from https://basecamp.com/shapeup

Book Summary

Shape Up defines the Agile Process that Basecamp utilises. The summary at the end of the book lists their ideas as follows:

Shaped versus unshaped work
Setting appetites instead of estimates
Designing at the right level of abstraction
Concepting with breadboards and fat marker sketches (a sketch made with such broad strokes that adding detail is difficult or impossible)
Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
Choosing the right cycle length (six weeks)
A cool-down period between cycles
Breaking projects apart into scopes
Downhill versus uphill work and communicating about unknowns
Scope hammering to separate must-haves from nice-to-haves

There’s quite a bit of Basecamp jargon in there. Some of the sections I didn’t care that much about, but there’s plenty of aspects that seem like they counter many of the problems I have witnessed when it comes to Agile development. So I think this book does provide answers.

Notes From The Book

Some key points that I liked or found interesting (this is basically me copy and pasting from the PDF):

Instead of a traditional two week sprint, they work in six weeks. This time is “long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start”.
They “focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?”
- Small Batch : This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle.
- Big Batch : This project takes the same-size team a full six-weeks.
They “give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time”.
“Pitches” are posted as Messages in Basecamp software. There are five parts to include in a pitch:
- 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
- 2. Appetite — How much time we want to spend and how that constrains the solution
- 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
- 4. Rabbit holes — Details about the solution worth calling out to avoid problems
- 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
“Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks or any pitches that somebody purposefully revived and lobbied for again.”
Backlogs are big time wasters. “The time spent constantly reviewing, grooming and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now”. Pitches therefore, do not go on backlogs. “If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.”
“It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.”
The “Circuit Breaker”: “We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. We intentionally create a risk that the project, as pitched, won’t happen. This sounds severe but it’s extremely helpful for everyone involved.”
- it eliminates the risk of runaway projects
- it means we did something wrong in the shaping
Dealing with bugs
- Use cool-down – the two week gap between the six week cycles
- Bring it to the betting table – plan it into the next cycle
- Schedule a bug smash – dedicated time usually around downtime like Christmas

Personal Comments From My Experience

So some discussion on why their approach is good:

I found with 2 week sprints there’s a lot of meetings involved for only 10 days work. You end up spending half a day planning, then there are 1 hour meetings like the “Retrospective” that happen at the end of the 2 weeks. With all these meetings, it cuts into the 2 weeks. 6 weeks makes it seem like the planning is less frequent and more worthwhile. You have more to praise/criticise when you reflect on your team’s progress during the retrospective.
Sometimes important bugs become the priority then you end up shelving your work. It would be nice to have the intense focus to ensure you finish what you start.
When we get to the end of the sprint, it is too easy just to move the work into the next sprint, so it makes the 2 week block seem meaningless. Knowing the timing is stricter will put more focus on actually delivering.
Often, bugs that you think are annoying are deemed low priority so they get shoved on the backlog and never fixed. First of all, it would be good to have the freedom to fix bugs that personally annoy you. Secondly, what is the point of having a backlog if it’s just a list of work you know no one will ever address.
- “Is this bug logged?”
- “yes, it was logged 3 years ago”.
- “brilliant”.

Remote Standup Meetings

We have a daily “standup” meeting where each person in the team says what they did yesterday and what they are going to do today. You can also highlight any “blockers” that will prevent you from completing your work.

Since we are all working remotely, we just do them using Microsoft Teams. At first we just nominated someone to speak next, but since we have around 10 people in the team, and people don’t really listen or pay attention, then we ended up with people asking: “has everyone been?” – when only half of the team has been.

When Microsoft Teams introduced the “Raise Hand” feature, we used it as a flag to show who still needs to talk. Still, Colin says “who is next? Matt have you been?”. Yes he has been, why don’t you choose one of the 6 people with their hands raised?

Another point which illustrates that people don’t listen, is when I say something like “I’ve sent a Pull Request for my work but no one has reviewed it yet, can someone review it?”. Then three hours later, no one has reviewed it.

I think the problem is often that people are so focussed on what they have to say, then they don’t listen. I was watching a video about it and the guy reckoned the “walking the board” method gains more attention. This method is where you look at your “Kanban board” which shows you all the work your team is doing. Then you can go through each item in turn, and the relevant people can then speak up. I still think you’ll have the same problem since you know that you will have to speak when it gets to your work.

There are a couple of people that seemed to nominate people without even looking at the attendees, so then they end up in embarrassing situations where they say “Rob can go next”, but Rob isn’t actually on the call. Sometimes it was well-known that they don’t actually work that day because they are part time.

We also have someone in our team that just deals with Test Environments so isn’t directly involved in our work. We did raise the point that it is stupid for him to attend the stand-up meetings but our manager said he wants it to continue so he feels part of the team and also gets to hear the team talk. I guess that is a good point – since we are at home, we don’t get to hear our colleagues speak much.

His updates are so boring, and he delivers them in a really bored tone. I often think he doesn’t have much work to do, so just says words to blag it:

had to restart some servers, and upgrade some RAM.
signed off some policies, and am looking at patching some security vulnerabilities.
I sat down with Dan for a bit and went through some tickets. Got some other tickets. Need to review some policies. Still need to complete some security vulnerability patches.
Busy doing environment stuff, mainly security updates which I’ve almost finished. Just need to do some Virtual Machines today. There’s about 40-50 clients so that’s going to take the full day, maybe tomorrow as well.
Catching up on comms, am currently resetting a password, and then gonna look at some more environment tickets.

How long does resetting a password take? Is any of that actually useful to the team anyway? He may as well just say “Environments stuff” then choose the next person.

Another thing that always happens is when you pick someone to go next and you are met with silence. So you say “you are on mute!”, then a few seconds later “oh yeah, sorry I was on mute”. Here are some classic “mute” scenarios that I wrote down:

Becky: “Good morning Colin”
*few seconds of silence*
Colin: *bland tone* “good morning”
Becky: “You sound down, Colin”
Colin: “I said ‘good morning’ but I was on mute, so that's my second attempt.”

James: "Can everyone see my screen ok?"
*silence*
Becky: "yeah, sorry I was on mute"
Colin: "yeah, sorry I was on mute"
Matt: "yeah, sorry I was on mute"

Matt: "Colin, have you been?"
*silence*
Matt: "You still have your hand up"
*silence*
Matt: "you are also on mute"
*silence*
Colin: "I'm on mute? how did that happen?

And a bonus scenario:

Becky: "this meeting has started early!"
Colin: "who started it?"
Matt: "it was you Colin"

Conversation With My Line Manager – A Project Review

My manager asked me how the project is going. I was honest with him. I stated most of my concerns.

First of all, the teams aren’t well defined. We have some User Stories that seem like they would sit better with the team handling Authentication. We also have work that shouldn’t be much work on our side, as long as the UI Controls team have created the controls we need… but they haven’t – so that work has to be marked as “blocked”. Then you also have what I call “Team Duplicate” who are just duplicating our work.

I ask my manager what Team Duplicate is for, and why they just don’t merge with my team. He doesn’t give a straight answer, he just says:

“trust me, there is a difference”.
Line Manager

He is leading that team, and he can’t even explain their purpose.

I also said we don’t have many User Stories that are true User Stories. They have that name because they are from a User’s point of view. They should be defined like “As an admin user, I want to manage member’s privileges so they can access confidential records”. They shouldn’t be “As a menu, I want to provide options for the user to click”. Seriously, we do have some written like that.

My manager said my opinion was interesting, because someone else had said the same issues to him.

“Oh, so are you going to do something about it?”
Me

“No, it’s not my responsibility”
Line Manager

Brilliant. Multiple of his line reports are complaining about big problems but he won’t feed it back. Why can’t managers manage all of a sudden? They were fine last year. Now they have all given up and forgot their skills.

I could raise the issues myself I suppose, but it didn’t used to be this way. Also, part of my problem is the team he is managing, but he doesn’t agree there is a problem there.