Treat others the way you’d like to be treated

Some of the rules of life are seemingly simple, and one I’m particularly passionate about is treating others the way you’d like to be treated yourself.

I’ve been hearing a lot of stories recently about work place interactions that contradict this simple guideline;

• A friends manager has started coming in half an hour late to work as he’s started going to the gym, but still leaves at the same time as previously. All the while keeping a ‘lateness’ spreadsheet on her and the rest of the team.
• Another Scrum Master is having difficulty because the direct manager of his team has started booking in the whole team for ‘Team Bonding Sessions’. He says he doesn’t know what’s more headshake worthy, that they are scheduling team bonding, or that the session is only 15 minutes a week.
• In an old position, the management team would go for lunch all together at 12pm every day – whilst my team and I had to organise between ourselves to make sure our duties were always covered. Though we never did understand why they so urgently needed the cover for an hour whilst we were only in the kitchen or a short walk away with smart phones on us. But it did mean that we never got to socialise properly as a team, and never became much of one, where the management seemed to like their group lunches.

I can’t profess to know this works all the time in every situation, but it stands to reason that if you enjoy flexibility in your work day, or the opportunity to bond with coworkers over lunch, those around you do too. Can anyone honestly say their preferred way to bond with their team would be a scheduled weekly 15 minute fun session?

On a smaller level – this happens with bitching, badmouthing, gossiping or assuming the worst about someone. If someone in your team is working from home more than staffers usually do, I’ve seen others jump to the ‘They are doing no work’ conclusion or whisper ‘they are taking the piss’. But surely if something was keeping you WFH for a while, you’d want someone to talk -to you- about it if there were any concerns, and not to others, encouraging them to assume the worst about your behaviour. Can you honestly say you assume the best of other’s intentions, whilst expecting it from them for yourself?

Retrospective #6 – Nightmare Team/Dream Team

Question: Did you have the opportunity to do your best this Sprint?

“The point of continuous improvement is not to increase velocity, it’s the build a great agile team.” @gilbroza

Nightmare Team/Dream Team

With the mind of giving us an opportunity to define the team we want to be, and give us a resource to refer back to in future so we can hold ourselves accountable for becoming this ‘dream’ team. The below isn’t all based on how it is now, and can be theoretical.

Nightmare Team

• If the team wasn’t protected from management/politics/stakeholders: Micro-management, bosses interfering, multiple managers/POs so no consistent priority, outside noise, managers that aren’t open to learning or advice from ‘subordinates’
• Lack of Communication: Team that doesn’t talk to each other, lack of coordination, poor communication, people being afraid to talk about mistakes.
• Bad Team Manners: Working alone, not working as a team, no fun allowed, people who don’t get on, pedantic attitudes, not helping others when possible, not seeing each others strengths, ego’s in the team, a blame culture.
• Lack of routine: Constant change of scope, dishonesty, routine disrupted, changing priorities of tasks.
• Deadlines without enough notification: Constant time pressure for no clear understandable reason, deadlines to meet, unrealistic deadlines, Overtime all the time because of deadlines.
• Lack of resources: Staging down, lack of resources, not all resources in place = added pressure and inability to do our best.

Dream Team

• Appreciation and Flexibility: Everyone motivated to work (because they enjoy what they do), fun, work hard play hard, work/life balance, work joins up with personal interests, feedback from Users (appreciation), recognition for work (sincere). The team never hear from a Users point of view about the things they develop for them.
• Treating each other how you want to be treated: Everyone respects each other in the team, everyone in line with everyone, having the same goal, team spirit, everyone gets along, T-shaped people, willing to help others, committed to one goal, be a team who pulls together.
• Communication and Trust: Support idea sharing, argues well, openness x2, ask for help, no fear if you make a mistake, problem solving done by whole team.
• Healthy Work Environment: Realistic deadlines, better planning, hear from the business sooner when they want us to work on something, no scope creep,
• Team owns the Product.

How to phrase asking about the work that isn’t being done

Regression starts tomorrow and we need everything to be done by close of business today to make sure our next big release goes well. Everything is in testing par one ticket which we spoke about in Stand Up this morning, but as of late afternoon, it’s still sat in ‘To Do’.

This release has invovled mutilple Scrum Teams, and taken alot of co-ordination, so when it comes to the ‘Go/No Go’ meetings, people are asking me multiple times a day if we feel like we’re on track, are their any blockers? are we confident the release is ok to go.

We know a Scrum Master is not a Project Manager, we know a Scrum Master is not a Manager full stop. But I can’t tell you how natural it is to me to want to grab two team members and ask what’s going on with that ticket? Why is the top priority ticket on the day of done sat in ‘To Do’, hours before we need to start regression? Maybe it’s the parent in me.

You’ll be happy to know I didn’t do that – I knew enough to know what I shouldn’t do, and asked for help from another Scrum Master at the company about what I -should- do. Turns out it’s a question of phrasing.

• Is there anything I can do to help you on this ticket?
• Are there any blockers that have come up today which I can eradicate?

The goal being that the team themselves in future 1. notice and 2. ask each other these questions to be self-organising and take ownership of the product.

Hello World!

After 52 posts I’ve made a jump from Tumblr to WordPress.

Tumblr is a great deal of fun, and I love that you can just input a relevant gif easily, which really suited the tone of my posts but it also feels quite contained. The way I’ve found a lot of great blogs is from google, whereas it didn’t look like any of my posts would hit google from Tumblr.

As much as my posts are for me to daily inspect and adapt, I’m hardwired to engage with people, especially with my Community Management background.

Joining WordPress was a lot easier than I remembered, and I’ve even managed to import all my Tumblr post over – though admittedly they need cleaning up.

So Hello World! And also, goodbye for a time :p For the first time since I started the new position, I won’t be posting everyday as I’m on holiday for a week. I’ll be back in a week, have fun whilst I’m gone!

Following up with Retrospective Actions

I’ve been feeling pretty great about our Retrospectives, on the surface they seem to be doing a lot of good. Lots of discussion, input from everyone, laughter, food and some interesting actions to come out of them. It’s always been noted that actions speak louder than words, and for the Retrospectives to go well, the actions have to be followed through. Which I thought was happening, though here and there, meetings would go a miss or get pushed back.

One particular example is the action, “Kick off Knowledge Sharing sessions on a Wednesday” – designed to fill the afternoon where we sort of have ‘free reign’. It’s after the Wednesday morning release, but before the next Sprint starts on Thursday morning. It was well-meaning enough. Come Wednesday afternoon the meeting didn’t happen.

I’ve spent some time trying to figure out why, and stumbled upon this brilliant blog “Finding Marbles“.  So I’m glad for the challenge as it introduced me to Corinna and her excellent blog/tools for Scrum Masters.  Using the ‘SMART’ theory made noticing where I could have improved a piece of cake.

• Specific: ‘Knowledge Sharing Sessions’ was not specific. During the time we should have been in the meeting, I spoke to individual Team members, and it turns out they all have different ideas on what ‘Knowledge Sharing’ even means, what it was meant to achieve or how it should be presented – down to personal differences in learning styles. So when everyone was nodding their heads in the Retrospective, they were agreeing to different things, all met by the vague goal I wrote down.
• Measurable: All the team had different ideas on what the session was meant to achieve, and different takes on the phrase ‘T-shaped’; ranging from knowledge about another area, ability to help out, > ability to actually do and pick up a ticket in an unfamiliar area to their usual expertise.
• Achievable: Nope. This was an important learning. The meeting was set for Wednesday afternoon, when we believed we had some flexible time to improve the team. In reality, by Wednesday afternoon, after a morning of meetings in the form of Retrospective and Sprint Planning (plus this particular Wednesday an extra refinement session), all our brains were too fried to go into a fourth meeting, whether we wanted it or not. I talk a lot about ‘Energy Management‘ and this should have been a red flashing light for me.
• Relevant – this is the one we 100% got, the action had its heart in the right place and was a good one for the Retrospective.
• Time-Bound: Again, no – I previously had no set plan to follow-up on this. I do check in with our Retrospective Actions daily, but it feels like the Team should be aware of a ‘Review’ date as it were too.

There were two suggestions in the ‘Finding Marbles‘ blog post I linked to which I actioned immediately on this one. I deleted the Weekly ‘Knowledge Sharing Session’ meeting I’d original put in, and I created a ‘Trial’ session on a Thursday Morning. The Trial Session is centered around our QA, which I’ve set up with him (assigning the action to someone in the team is another suggestion from Corinna!) to demonstrate his work on a particular ticket. I have to be honest, I still don’t have ‘Measurable’ down – but the team were a lot happier with this more specific, more realistic action.

Retrospective #5

Question: If you had any Superpower, what would it be?

Flying. Time Travel. Telepathy. Flying. World Peace. Tell the Future. The Force.

“Shared Goals, Shared responsibility, Shared Accountability – Shared Leadership” @danielhsloan

Today we spoke about our joint aims, created from an overall amalgamation of everyone’s KPIs (Key Performance Indicators). Team ‘Standards’, we’ll talk about another day – the standards we want to hold each other too, like a ‘No Blame’ culture.

Our KPIs fit clearly under 3 headings; Quality, Agile and Team. So we talked about the last sprint and what + or – behaviours we have focusing on these three.

We talked about our Definition of Done in laymens’ terms, (taking into account our company’s definition) as we’ve recently taken on a new Front End Dev, and not everyone was absolutely clear on what this was.

• Code Complete
• Acceptance Criteria Met
• Peer Review and Merge
• Testing Complete
• Automation Test Complete (if possible)
• Security Compliant

Actions: Talking about how we can improve Quality, Agile + Team by 1% this sprint.

• Front End to link up with UX before they start a task, and when they have a rough ready after.
• Scrum Master to look into Architect’s Process
• Team empowered to make Architecture Decisions.

Team Goals

I mentioned in my last post that it’s KPI period, so what I’ve done is accoste my team for theirs and interestingly enough – across all programmers, testers, our product owner and myself, our goals are very similar.

I’ve been able to split these into 3 sections; Quality, Agile and Team. Which will be apart of our next Retrospective.

The reason I’ve done this is because I think it’s important the team knows what each other’s motivations and goals are so we can help each other succeed.

Mindtools talks about goals and ‘Forming, Storming, Norming and Performing’ – “Forming a team takes time, and members often go through recognizable stages as they change from being a collection of strangers to a united group with common goals.“

There’s also a good article on Gamasutra on Agile Teams which mentions, “Follow a shared vision and purpose: Everyone on the team understands the goal of what they are working on. Great teams have a unified cause. When one member has a problem, the entire team will pitch in to help them out. As a result, great teams deliver value because they focus on the whole rather on their own parts. Great teams are committed to their goals. They’ll go the “extra mile” to achieve a goal that they believe in.”

Now we haven’t chosen our ‘Key Performance Indicators’ and we will be doing a separate session on our Team’s purpose at a later date which the team can have more ownership of but this is a good start. A shared commitement.

Key Performance Indicators of a Scrum Master

I’ve spoken a few times about how it’s difficult to tell how you’re doing as a Scrum Master. Even those that have to ‘score’ me are having trouble figuring out how to make SMART goals and how those will be judged! 

Alas, after a lot of chats – we’ve cracked it a little, so here we go. 

• Agile Appreciation; this one includes tasks around coaching Scrum Methods to the team and those outside of it, ensuring sprint commitments are met, and that no service issues are created due to our work, my team self-manage, and that I foster an understanding of several terms in the team including MVP, emergent design etc. 
• Team Culture; Team members not acting as a group of individuals but instead acting as a Team, Team actively coaching each other, evidence the Team wants to become/is becoming T-shaped, and a No Blame culture among others. 
• Stakeholder Management; improve communications internally and externally, tie up the process with the Ideas Process, coaching the Product Owner and others. 
• There’s a few stretch goals as well – one interesting one is about picking up a 2nd Scrum Team…. Intriguing. 

Automation Testing

“@maaretp: I repeat myself a lot but remember a mantra: Tester’s don’t break products, just illusions people have about them. #agile2015”

There was a debate yesterday on how much a Scrum Master should know about Automation Testing.

• In favour was a case for how the Scrum Master should have an understanding so they can better promote the best practice between Product Owner and Tester. An extra champion as it were.
• Against was that a Scrum Master is not a ‘task master’ – that she or he doesn’t need to know how Automation works, they just need to facilitate a meeting between the PO and QA. That it’s the QA that should be pushing for time and importance on Automation Testing.

There’s a really interesting read here on an Automation Engineer becoming a Scrum Master, who talks about implementing Automation as part of fostering change in his Scrum Master role.

“I created 2 new automation testing frameworks for my team. I helped the team to start utilizing my automation testing framework using Selenium WebDriver and C#. Furthermore, I am the first individual in the entire corporate to utilize cloud based cross browser testing using an automation testing framework. Finally, working with another colleague, I am helping to add a new test case management tool to our suite. By having power as the ScrumMaster, I believe that I will further excel at fostering positive change in the organization.”

I also have the pleasure of working with a Tester come Scrum Master, who believes that what is good to know is how User Stories should be written – to allow for Automation Testing on all of them.

• “Given That”, “Then”, “When”

For us, automation is something which we time-box for the beginning of the sprint, where our lovely QA doesn’t have User Stories to test. Then each story has an ‘Automation Test’ task on it where the QA deems it needed. Having said that, it’s true that if the Sprint Goal is in jeopardy, or something needs to go – it’s always the Automation first. Because of this it’s important to make sure we’re holding ourselves to ‘Code Complete’ by Friday (2 days before Release/Sprint End).

This is my 52nd post – which means if I were posting these articles once a week, I’d had a year’s worth of content. Incidentally the quality of my musings can’t hold up to once a week, so this marks 52 days of learning about Agile and Scrum. Huzzah.