Mastering ScrumMastering

‘I am playing a bear attacking ‘poor Tsanko’ (while he is pretending scared), Georgi is a hunter to hunt the bear. The rest of the trainees improvise on different roles: a pickpocketer is trying to rob Tsanko at the same time and another tourist is taking photo of us to complete the picture… It’s all part of the improv ‘Still picture’ game, included in the ‘Thinking outside of the box module’… and we had so much fun, creating scene after scene, after scene…’

It’s been amazing six weeks. Together with Bogoy Bogdanov we delivered ‘Mastering ScrumMastering’ training @EPAM BG

The training (in workshop format only) is complete focused on improving the skills of the participants and consists of 95% practice to 5% theory. No lectures, no ppts, no long and boring talks – just gamified challenges to improve skills in the following areas:

• Communication
• Coaching & Mentoring
• Agile team dynamics
• Delivering talks

Our main goal was to innovate a training encouraging everybody to practice:

• Body language & paraverbal communication
• Soft skills, building emotional connection & rapport
• Coaching and mentoring
• Organizing Scrum events and ensure they run smoothly + facilitation skills
• Removing impediments efficiently
• Influencing decisions
• Presentation skills + teaching techniques (engage the audience)
• Creativity and thinking outside of the box

Each training day, a different topic was covered:

• Starting a new team & persuasion
• Coaching. One-to-One coaching
• Team level coaching & mentoring (Daily standup)
• Team level coaching & mentoring (Scrum events)
• Talks: deliver to engage
• Improvisation in Agile (Thinking outside the box)

And it worked amazingly well. The participants outdone themselves, had a lot of fun, and performed on top of their abilities in each session.

The feedback was also very positive (hopefully we would be able to share the video feedback too):

• 'Fun, engaging, different points of view, a lot of practice'       
• 'Very interactive, full of funny moments, very dynamic & interesting approach'
• 'We covered different topics but not strictly following a traditional way of training. We were put into different situations, where we had the chance to challenge ourselves and improvise'

To enjoy more pictures check the EPAM post.

Scrum issue #35 :: Any estimate is better than no estimate

“What do you think, how big is it?” or “How much time do you need to solve it?” – I will ask any of the two questions often, especially when urgent new story or task is coming into the sprint backlog during active sprint.

The story behind is: I worked with a team sometime ago and noticed a very strange pattern in their Scrum board. There were some tasks estimated ‘0h’ into their current sprint backlog, but those were not moved to the ‘done’ column. For me a task set to ‘0h’ remaining time means ‘done’ and I pointed that quickly. It turned out, those were items in progress: support requests, bugs or any other complex/unknown tasks which cannot be precisely estimated. At first I thought we could somehow breakdown those items and estimate the effort but most were already set at a level of just one task. For example if was a bugfix request the needed steps would be: to analyse/debug and then fix. And for complex systems no developer would be able to precisely estimate how much effort would be needed to debug and identify the cause of the issue. Even nowadays I usually hear a statement like ‘If we are lucky it could take less than an hour, if not – it could take weeks’… Not good.

The worst part is that those ‘0h’ tasks are hidden time sinks and could block some team members for weeks. In my observations this is one major reason why waterfall projects usually fail to deliver on time. I’ve seen developers stay blocked for months struggling with an issue that simply could have been ‘rejected’ after being identified as a huge time sink in less than a week.

So instead of estimating time to delivery we first estimate time for ‘spike’. For non-practitioners ‘spikes’ are time-boxes dedicated to just analyse, identify the complexity and estimate a certain issue. The time-box could vary but in my experience should not be bigger than 2-3 days. If there is still no progress after that, we contact the product owner and either offer another spike or think about workaround to be introduced in less time. Another alternative – the issue could be rejected or flagged as ‘not so important’, and the client just advised not to use the specific scenario in which it occurs.

After spiking, the issue could turn out to be huge and require more time than one sprint to be entirely developed/fixed. In that scenario we split it in terms of value and deliver as much as possible to the end of the particular sprint. The remaining part is up to the product owner to prioritise.

Another possible outcome is to identify the issue as being blocked by another issue. It is put on hold then and the Product owner decides what the priority is as usual.

For a complex/unknown story, the developers usually assign a lot of hours to the tasks (just to have some buffer). This is somewhat ok – but it is important to reduce the remaining hours accordingly as the level of knowledge increases. Don’t just log hours – look at the ‘time remaining’ value on a daily basis and adjust it. This way there is a much better transparency on the progress and the real risks for delivery by the end of the sprint are clearly visible.

Scrum issue #21: Grooming sessions are important

“We haven’t done any proper grooming session since two sprints” – one of my team-members was pointing out on the retrospective. He was right, and although there was a good reason behind, I put it on top of my list items to fix immediately for the next iteration. After all we were so good at grooming before that particular project…

The story started two sprints ago where a major project was introduced for my team. We were all very happy, and started breaking it down together with the Product owner into epics and stories for the next couple of iterations focusing heavily on the upcoming sprint. Then it was my idea to substitute the grooming sessions each 2nd and 3rd week (of our 3-week iteration) with show & tell sessions every Friday. I explained everybody the good practice when we have an important project and need regular status/issues report we just do something like mini-sprints during each iteration. Each of those mini-sprints would last exactly one week and end on Friday with a two-hour show & tell session. The session should have been used for status catch-up (1h) and 1h for grooming the next iteration items. It worked almost good… except that two of the teammates could not fully contribute to that particular project stories and started doing others.

And of course the whole show & tell session time was occupied with discussions, questions and preparation for the particular project items and no time left to discuss the other stories (present and future). And the two guys felt isolated and not appreciated enough. My bad. It was really a focus and lack of time issue. So nowadays when the particular project is going on more smoothly we dropped the show & tells, have the regular grooming sessions and don’t mess them up with status and current situation catch-ups. If the product owner needs to know how we are doing – he is just welcome to join the daily stand-ups even remotely when he is not physically available at our location.

*** Backlog grooming (for non-practitioners)
It’s a time-boxed session for the team, the product owner and the scrum master to discuss, clarify and break down epics into stories or complex stories into smaller stories in preparation for the next sprint. All those activities are done during the backlog grooming session:
- Set priorities on the items
- Discuss and clarify
- Break down (refine) complex items
- Add acceptance criteria
- Estimate stories
- Rise possible risks and issues
- Set items to be spiked (additionally researched)
- Estimate (roughly) how many stories could be taken into the next sprint (if the priorities do not change before the sprint planning)
- Delete obsolete items

Scrum issue #08: The Product owner can’t provide enough details

It’s going to happen, sooner or later, but what I would like to write about is the scenario when the issue becomes a repetitive habit.

In some organisations, the role of the Product owner is some sort of promotion or higher step in a corp. career path. A good example would be a development department (a couple of teams), developing complex software (the platform) for internal use within the company. As expected, there would be many clients/users/stakeholders using the platform within the different departments, e.g. the management, sales agents, marketing folks, project and account managers, IT, SYS, HR, etc… They all are going to provide requirements and feedback to fill into the platform backlog. So far, so good.

Let me engage your mind with a tricky question. Who is the most appropriate person for the role of a Product owner in this scenario? To your surprise in many similar cases the manager of the development department will be given the honor. As a result the guy will be overwhelmed with emails and other comms full of requirements and features to feed into the platform backlog. But as he is already a manager, with a lot of responsibilities, do we expect him to clarify and negotiate all those items? Hell, yeah… but it simply does not happen.

As a result during the Grooming sessions you will get used to hear something like ‘And here is a very important story for the next sprint, could you guys groom it a little bit and estimate’… then the team start asking questions and the answer is ‘It comes from Melinda – the chief of Marketing and unfortunately I can’t offer any more details than what she wrote, maybe you could find some time and talk to her before the next sprint planning.’

Okie-dokie… in Agile we are used to the team effort and support and as we love our Product owner we accept him as part of the family, even if he is not developing and delivering stories. And we are going to help him, either the Scrum master or somebody from the team is going to speak to Melinda, clarify the stuff and contribute to the story or the acceptance criteria. In the best possible scenario it works … almost ok.

And let me explain why… The role of the Product owner in Scrum is similar to the role of the Executive in PRINCE2, or the Lead project manager for a project. He is the budget holder, and he is responsible to approve the requirements, the priorities and deliveries negotiations with all the clients, users, parties and stakeholders. He also is solemnly responsible for the approval of the deliveries. Difficult job indeed. In our scenario the Product owner should trust the team’s ability to catch Melinda’s explanations completely and to manage her expectations well. Surprise, surprise – in the end of the sprint the story delivery and approval only led to a new story (rework of the last sprint item), and Melinda communicated she is not happy with the delivery. And it happens again and again with different stakeholders.

What could be done better?

• Convince the Product owner to dedicate more time understanding the stories, the business value and the use cases. He needs to work closely with all the clients and users. Will be difficult – he is a manager already spending a lot of time, for example with the higher level management (his boss)
• Invite Melinda for the next grooming or planning session to explain the story and negotiate acceptance in the presence of the Product owner. Sounds good … if Melinda is available. (if not - ask for a somebody to represent her)
• Invite Melinda for the sprint review. Still the Product owner will approve the story, but Melinda might come up with a follow-up story and requirements based on the functionality delivered
• Don’t be afraid to ‘interrogate’ the stakeholders – for example ask the ‘five whys’ to get to the root of the use case and what the users really want to achieve
• Negotiate deliveries with the stakeholder. Almost all features consist of more and less important parts – reduce scope and commit to deliver only what is needed today (and tomorrow)
• Have the Product owner presence be some sort of assurance (to the stakeholder and the team) regarding the clear commitment
• Assign more Product owners (be careful). It’s not ideal but for a complex product like ‘the platform’ there might be a product owner for each team and a ‘chief product owner’ to resolve conflicts (for example priority ones). Those ‘team-product-owners’ should be empowered and would be expected to dedicate full time working with the clients/users/stakeholders and the team on the other side
• Don’t rely on written information only. It’s all about conversation and negotiation for each story

And to answer the tricky question above:
The most appropriate person for a Product Owner is a business person, who communicates to clients and users on a daily basis. A person, who communicates clearly, negotiates with ease, manages own time well and is not afraid of taking responsibility for his decisions. Account manager or project manager, business analyst, even sales person in some cases could make a good product owner. Technical knowledge is usually not required, and user empathy and the ability to clearly understand what the user would like to achieve is. Depending on the product you would expect at least 50% of the person’s time to go for PO activities (in our scenario it would be at least 95% to manage the amount of stakeholders).

Scaled Agile Framework (SAFe) overview

Agile principles are very easy to adopt and very difficult to follow entirely. For example the ongoing philosophy explaining why is it better to deliver just a few high-quality-tested-working-shippable features in two weeks; over tons of non-tested and arguably working items in three months to a manager who just promised the earth to the client… Or the never-ending resistance when evangelizing team-work and condemning story-per-person bad practice.

One particular instance has always bothered me too – how to scale Agile properly. Self-management, self-organization, quick and efficient decision making without higher authority work well in small teams (up to 7-9). Good examples are guerrilla squads – they are very efficient in utilizing terrain and other advantages against outnumbering opponent. It’s also true that armies (or large groups) cannot efficiently self-organize and self-manage – there is a good reason for the complex hierarchy in the army.

Recently, I was lucky to have been commissioned to review and summarize one of the most famous frameworks to scale Agile – SAFe and although the final overview document is huge I will try to summarize it even further in this post using three flags to categorize my points (good, not so good and ugly).

Here we go:

* SAFe is an interactive framework for implementing Agile practices at enterprise scale. It is marketed as an Agile solution for programs of only 50-100 people, and in enterprises employing thousands of software developers. The expected main benefits include: better alignment on all corp. levels, higher quality software and faster delivery to market.

* There are three levels of scale recognized
Portfolio – align programs to enterprise business strategy along Value Stream lines 
Program – funding for personnel and other resources are provided and aligned to the enterprise mission. Agile Release Trains (ARTs) introduced and used to deliver value
Team – Part of Agile Release Train. Responsible for defining/building/testing/deploying user stories in sync with the other teams. Pretty much - the ordinary Scrum team

* SAFE introduces some new roles responsible for overall architecture, UX, coordination and product development, centralizing some of the authority and the decision making process inherent to the Waterfall practice (SAFe introduces a mix between Agile/Waterfall practices). The System architect and the UX person would really have big shoes to fill as a lot will depend on their decisions. The System team is also something new – responsible to integrate, test and demo the features just before release. The Release Train Engineer (RTE) is acting exactly as a chief Scrum master and is coordinating the work of many teams and the other roles accordingly.

* The most significant innovation in SAFe is probably the Agile release Train (ART) – a good scale of Agile software development allowing 5-10 different teams to work in sync on a specific ‘value stream’ (project, product, client or just Epic). The train is supposed to run in cycles and deliver value every 10 weeks. Optional releases could be done after each iteration end.

* A lot of the Agile mindset and some Scrum practices are followed. One example is that after each iteration the teams are expected to deliver fully tested / shippable and usable increment of software.

* The teams work in sync – using the same iteration length (including beginning and ending dates). I also noticed it is much better to organize dependent teams to work the same way in order to deliver potentially shippable increment at the end of each iteration.

* An example of a Waterfall practice would be the last HIP Phase/Sprint – reserved for integration, quality inspections, innovation and defects fixing. Currently the HIP phase is introduced by the necessity to stabilize the deliveries from the different teams, fix defects and refactor code. With the introduction of this phase the ability for premature deliveries is arguable.

* There will not be a huge impact for most of the Scrum teams as every team will be part of the Agile Release Train and mostly operate the way it currently does (in terms of Scrum practices). The noticeable difference will be that the team will need to take part additionally in the Release planning, Release demo and help Grooming Epics for the following Release planning… and God – those meetings are huge. Also depending on the implementation some of the integration / testing / demoing responsibilities might be stripped – and it does not sound like a good idea.

* Although undoubtedly an innovation - ART assembly will be somewhat tricky. Should ARTs be assembled by projects, products, or just a bunch of related features? It would be easier to break existing teams and interrupt their habits and well-established practices.

* All the new roles and teams will inherit the flows from the Waterfall/Centralized decision-making and management practice.
The System architect for example - would be in huge risk. It smells really bad to overburden one person with all the architectural decisions regarding a complex system. Mitigation would be to involve appropriate team-members from each team to help/support him.
On the other end the System team would really feel the pain integrating and releasing the work of the others. There is a good reason why this job is done by each responsible/delivering team in Scrum. Demoing should also be done by the appropriate team-members and not just by one separate team.

* Releases on demand outside the end of the ART cycle will arguably be possible with the introduction of the HIP phase (would not even call it a Sprint). SAFe proclaims that a release could be requested after each iteration (even after the first one), therefore in order for this to happen - the teams should strictly follow Scrum practices and deliver fully tested, shippable product at the end of each iteration so the HIP phase becoming somewhat redundant and could just be used for innovations and grooming.

* Release planning issues will be noticeable. In Agile we plan and deliver using small iteration cycles, allowing quick feedback, change of requirements and adaptation. Planning the work for the next 10-15 weeks (even on top level) would be least to say difficult. Mitigation is that the ART should not be seen as a static (in terms of scope) object but instead an Agile – negotiable / inspectable / adaptable body – still the implementation will be difficult in practice.

* Collaboration must be even better than usual. There will be too many dependencies between the different teams and as I imagine, they should start working on the most important feature (from the Epic) in the first iteration of the ART in order to prepare it for release (if needed after the iteration). The collaboration and coherence must be impeccable in order to reduce waste and keep efficient and sustainable delivery.

* Self-management and self-organization would suffer. In Scrum we give freedom to our teams to choose and implement best possible solution in order to promote self-organization and self-management and increase morale, efficiency, quality and the joy of work. With top level System architect, UX, RTE and the other team dependency - a single team will just have to comply and develop what has already been decided/designed in someone else mind.

Scrum issue #17: The Product owner is too powerful

‘… and the story is a must for the next Sprint. George is the most suitable person to do it as he has the knowledge and the expertise, and no, there is no time to train other team-members in the meantime… now let me tell you what the best tech approach would be and the dependencies you would be dealing with… then you need to talk to Jane from the team in Australia to confirm… and don’t forget the tests you need to run… and the documentation expected…’ – you immediately recognise the almighty Product owner (PO). He is there to conquer, dominate and rule the world and nobody would dare to oppose him.

I worked with many POs and still can’t decide which the worst scenario is. A guy who totally does not care about the backlog, the sprint items and deliverables, the one who let everything to be decided by the team OR the dominant old-school micromanagement type of person who doesn’t let any of his powers easily.

The dominant PO would have any of those characteristics:

• High-level manager
• A person who hire / fire or promote (decide the fate of) team members
• A person who’s been with the company for a decade (at least) and knows the system/the project and the co-workers better than the entire team
• A business person who doesn’t care about Sprints, Scrum or any other fancy words. He has his due dates and scope negotiated with the client and everybody must comply with his plan
• A person who love talking for hours and nobody could even get the chance to say anything
• A person who is always in charge – he starts and finishes the meeting and talks 90% of the time
• A person who doesn’t listen or quickly ignores any remarks or attempts for such
• An old-school micro-management freak. He can’t sleep well if he has not personally assigned the daily tasks to each particular team member
• A person who always changes the agreed meeting time, clearly communicating who the boss is and that the whole team should comply with his schedule
• A person who expects little discussion and more action. A person who would never ask for anybody’s opinion
• A person who would always show-off and point how much better he is than anybody else

You would be really unlucky if you have a Product owner with all the characteristics mentioned above but even some of them could be a problem for succeeding in Agile/Scrum. In result to the described PO behaviour using Agile might turn into a horrible experience and miserable situation for everybody, expressed in:

• The team show zero initiative
• No self-management/organisation at all
• Everybody waiting for the boss to assign tasks
• Little to no interest in Daily Scrum, Planning, Grooming – the PO will take care of the planning anyway
• The Review feels like ‘school exam’. The Retrospective is just ‘PO bashing everybody’ fest
• No team proactiveness and no engagement at work
• Little to no attempt to even discuss the items expected in the next delivery
• Permanent inability to complete all the Sprint items for each Sprint
• Insufficient quality for the delivered items
• Overall team unhappiness

Although exaggerated above, as a Scrum Master you MUST act when you are dealing with a Product owner close to any of the described traits. You definitely would like to have some private time with him and depending on the case prepare for regular coaching sessions if needed. The PO should constantly be reminded/trained in the following Agile principles:

• The role of the PO is to organise the backlog – ‘what, when and why’… It’s up to the team to decide ‘how and how much’ / absolutely no micromanagement is allowed. It’s up to the team to organise how to do a specific story and what the specific tasks are going to be
• Discussion means that the team and the PO should talk evenly (or close to) – 50/50. If you feel like talking too much – stop, and ask what the team opinion is and how they see the story
• You can’t simply put items from the Product backlog into the Sprint backlog under any circumstances! It’s up to the team to decide if a story fits into the Sprint and what is doable and what is not (negotiate deliverables and acceptance criteria – No item is meant to be static in Agile)
• Back-off and empower the team – let them take the space. The team will not show proactivness and engagement if you hold the full power… What’s even worse – they would not be interested in delivering quality items
• Show interest in what the team-members are saying – help them improve their ideas, don’t reject or seize them
• Don’t correct the team even if they are wrong (well, don’t let them ruin the system though) – you could flag the issue but don’t impose your way
• Treat the team with respect and equality. Let them organise themselves, respect their will and even vision. The main benefit of Agile is that nobody needs to manage the experts – they should be led and supported, but in end it’s up to them to propose, implement and deliver the best solutions (that’s why you hire experts, right?)
• Engage the team in the long-term planning and how they see the future of the product developed
• Get feedback from the team. The retrospective is not meant to improve the team work only. It is meant to improve the Product owner and the Scrum master work as well
• Ask for team support as much as possible. Even with items primarily meant to be PO responsibility – like backlog prioritisation for example

There are many benefits in having self-organised and managed team. The productivity will increase, the items committed to - will be items delivered, the quality will be improved, better solutions will be implemented and the team will be motivated, working with fun and fulfilment. Stripping off some of the PO powers is usually just a little sacrifice for the greater good.

Scrum issue #33: Daily stand-up turns into a report meeting to the Scrum Master

That’s an issue I faced many times with different teams. At a certain point a team either gets so cohesive, each team member knowing precisely what everybody is doing, or totally the opposite, indifferent to the work of the others, that a daily stand-up turns into a report meeting to the Scrum Master.

First let’s summarise the basics for non-practitioners:
The Daily Scrum is a short meeting (usually not exceeding 15 mins.) held on a daily basis and each team member should answer the following questions, regarding the Sprint stories/items:

• What did I do yesterday
• What am I going to do today
• What impedes me

There is a lot of criticism and murmuring related to the meeting being ineffective or even useless, for example:

1. I collaborate with the team all the time and I always know what’s going on
2. My work doesn’t depend on other team-members so stand-ups are waste of time for me
3. The Daily Scrums aren’t held at a suitable time for me
4. Stand-ups feel like reporting to my first-grade teacher

And here is what I usually coach and answer to those:

1. It’s great you collaborate so well in the team. The Daily Scrum could also be used as a motivational planning and committing to tasks on a daily basis. Also the transparency for the non-team members is essential in terms of progress, risks and issues. The team is not meant to work in an isolated environment.
2. Working on a story or item independently is an issue and potential risk in any Agile team. Yeah, I know – there is no other database guru in the team but you could involve some of the developers so they have an idea (at least) what’s going on with your story or tasks and would be able to somehow help or take over if you are not able to work on the items. As mentioned above for teams – team-members should not (under any circumstances) be isolated / whether or not it seems efficient to do so.
3. And it’s up to the team to choose the best time for all and stick to it. After all, if we can’t do a short daily meeting successfully, how are we supposed to organise well, plan, develop and deliver comprehensive software?
4. The meeting is what we do out of it. Focus more on sharing than reporting, planning than chitchatting and risk identifying than rushing in.

The good practice for Daily Scrums would be:

• Use same place, same time, every day (except the Sprint planning day)
• Stay focused on the Sprint items - look at the board and the burn-down chart
• It’s a stand-up (to keep it short... and you well-fit)
• The focus is on collaboration, daily planning and identifying risks and challenges
• It’s not a report meeting to the Scrum Master

As a Scrum Master the best you could do is not act as a focus-person to encourage the team members to talk to each other and not to you. You could even sit-down (yes sit) outside of the circle and take your notes if needed. The idea as usual is to back-off and create space for the team to fill-in and self-manage/organise as much as possible.