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.
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.
“@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).
Hopefully you’ve had times at work where adereline is rushing and you go to bed reading articles on a subject that you just want to consume. For me that’s ‘Ideas Management’, more specifically Open Innovation Platforms. At one point I was such a dork about it I bought myself a lightbulb necklace and created my dream job description, “Ideas Manager”.
It turns out in Scrum, “Stakeholders” and their Ideas are just as important to us as they were in my previous role. In fact, in becoming a Scrum Master, I’ve just moved further into the Internal Ideas Process. I’ll be writing about the 4 step process in future articles. Stay tuned!
Pet Peeve’s as described as “A pet peeve or pet
hate is a minor annoyance that an individual identifies as particularly
annoying to themself, to a greater degree than others may find.“ – and I think that’s an important distinction. It’s a minor annoyance.
So without further ado, I’ve developed one since becoming a Scrum Master and it’s name is Calendar Clash.
I’ve never had to book so many meetings before in previous roles – but I’ve found that even if you book a Meeting Room, the chance of you actually securing it isn’t high – or via versa, if I book a meeting with our Product Owner, someone booking him into another meeting when he isn’t free. On Wednesday’s one meeting room is triple booked, and yet when I checked, none of those 3 meetings still happen.
But I don’t really get it, because you can view other calendars to see if the rooms/people are free before you book your clashing meeting. So this results in me spending quite a bit of time talking to people about these, or re-arranging rooms.
Google Calendar shouldn’t let you be able to do it!
#endrant
I’ll speak to our Office Manager about it and see if anything more productive can be done about it.
Agile 2015 is going on at the moment – you can read more about it here, and as much as I’d love to be there, the tweets coming out of the conference will get me through the jealousy!
Last Sprint I started a practise of nailing my personal Focuses for the iteration – to remind me what I want to achieve, especially when things can get quite ad hoc. It’s always helpful to have a record of what you’ve achieve or tried to do for both personal retrospectives or Performance Review time!
My first one went bit like below;
Team: Focused Stand Ups
Scrum Process: Talk to the PO about slicing stories differently
Stakeholders: Create a page (on our intranet) so all stakeholders can see what stories we’re working on or planning to relevant to them.
Plan for;
Retrospective on the 29th
Ad Hoc Development Session End to End on the 30th
Team Lunch on the 2nd
Scrum Coaching Session with FE Dev on the 4th
New Starter on the 4th
I found checking in with this every morning really helped keep me on track and reassure me I am actually making incremental improvements.
It’s true that your largest stakeholder is your customers – and where I work, we have direct access to all of them through our Company’s Forums. In a later blog I’ll talk about Ideas Management but today I got to use my Community Skills for the good of our Agile Process.
You see, our communication hasn’t always been the best, and I think as people become more knowledgeable – it’s becomes difficult to teach without using tech slang. Well I am currently a newbie, so it was a natural decision to post on Agile, Scrum and Beyond as I’m learning too. To bring our Community on the journey with me, with a goal of great collaboration.
Today’s article for members was on the first Agile Principle;
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Which ironically writing it felt a little like a test to see if I had been paying attention this last two months.
I gave some stats on our Company’s delivery (14 Releases, implementing 377 changes in the last 18 months) to help put our work and ‘Continuous Delivery’ into perspective.
I talked about my lack of understanding on what ‘Early’ meant “It conjured associated words like ‘incompleted, messy, unusable, basic’.“ Something I know our customers would go through that same thought process and be concerned about.
I gave some real world examples of incremental releases on some of our products, to help the concept along and then spoke about the benefits of early, continuous releases in bullet points.
Finally I posted a call to action – that our release notes aren’t just an update – they are there for feedback, to be challanged and for change to come from our customers.
The response to these threads (and I’ve only done two so far) has been phenomenal. I’ve always enjoyed unveiling more and more of the company to our members.
This is one straight from an email;
“1) That you have a dev process with customer input built into it is, itself, remarkable and laudable
2) That you are writing about it so eloquently, with such a deft tone
is a tribute to your rare talent both as a communicator in general and a
community expert in particular
3) The content and tenor of the customer responses – even those with
gripes – shows what a special place your company has managed to achieve in
their lives. And that only happens when they have people like you
interacting with them over a long period of time.
4) You know how to use a semi colon. There aren’t many of us left“
I think it’s totally natural for someone to see Release Notes, and assume that what has been released is a ‘final product’. It is easy to be critical of this final product and urge about changes when things aren’t right with it. If our Customers understand our mindsets, and how we release r.e. MVP’s and incremental improvement – they’ll know we’re ready and waiting, we’re prepared for their feedback and to act on that quickly. Criticism becomes collaboration. Joint understanding means we’re on the same side.
A couple of smaller tickets that looked like they were quick changes took days to investigate.
Making the Team Glad
Working together on one of the bigger tickets, Team Work, Great Team Work….
The Refinement sessions we did were focused and vaulable.
We finished everything on time, had the release reviews and a smooth release.
The Burn Up is beautiful, we had a really good rhythm this Sprint.
The guys felt like we were working on new interesting features.
We had a meeting about Back End Technical Debt and we’re happy about working on that and fitting it into future sprints.
Enjoyed the Team Day!
Actions
We need to be more aware of Front End Techincal Debt, we don’t have a specfic action yet, but let’s keep our eye out for one.
We’ll
be starting Knowledge Sharing Sessions on a Wednesday Afternoon – with
the ultimate goal that we can start pair programming and then eventually
someone could pick up a ticket which isn’t their usual skill.
Let’s check in with the Front End Lead about being able to test our code locally.
We’ll be testing dropping the daily refinements in favour of longer more focused ones.
On
the Friday’s we’ll be doing a Justice League Sprint Demo for our stakeholders to
address some concerns around the Joint one on Tuesdays.
At
the end of the Retrospective we reviewed our actions from previous
sessions to see if we feel we’ve done them/need them or need more work.
An extra action for the Scrum Master is to daily get the team using
HipChat to hold us accountable for previously identifying we need a
joint space to keep up communication.
“Something has been off about our burn downs – going by story points, there’s a good few examples from previous Sprints that we might be running Mini-Waterfall. Usually it takes half way through the sprint, at least, for that line to drop any.“ My Evernote notes.
For the longest time our Sprint Progress puzzled me, and after having a historical look – I realised it was due to the size of the stories in our Sprint. Too big, and we effectively had a Mini-Waterfall.
Our sweet spot is anything 8 points and under, (and even then two 8 point stories get’s a little dicy) which I imagine some might think is too small.
Mike Cohn wrote a great piece ‘In Defence of Large Numbers’ (which I’m trying to link but Tumblr isn’t playing nice), where he talks about high level estimates for those who want high level overviews, “Removing the large values from a deck of Planning Poker cards is like
deciding to strike “millions” and “billions” from our vocabulary just
because our bank balances are only in the thousands.“
And I’m absolutely with him on that. Recently in a Refinement Session we scored a piece of work a 20 in total. During that refinement session we sliced the story with the team and scored the smalled User Stories. So whilst we only have 3-5 point stories in our current Sprint, we know there’s a 20 story point project in there. We knew the project would take about half the Sprint, so that helped estimate the rest of our 2 weeks.
However in terms of tracking, for us at any rate, we don’t have 13 point plus User Stories in our Sprints anymore – and that suits us fine. No more stairs, just a nice hill slope.
Scrummastery 