Matthias Seulhttps://mseul.com
Agile-Thing-Doer, Conference Speaker, Security-Dabbler, Occasional Inventor, Technology-Lover, Irregular Writer, Game-Geeker, Half-Earnest Runner. Also slightly mad.Mon, 07 Aug 2017 07:15:28 +0000enhourly1http://wordpress.com/https://secure.gravatar.com/blavatar/b62d244e785897546414fffdd4ca58ea?s=96&d=https%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngMatthias Seulhttps://mseul.com
On Co-Locationhttps://mseul.com/2017/02/07/on-co-location/
https://mseul.com/2017/02/07/on-co-location/#respondTue, 07 Feb 2017 09:58:19 +0000http://mseul.wordpress.com/?p=98Continue reading →]]>Having worked in a few distributed teams my experience has been that with large disparate time zones, with people either getting up very early or having to stay in very late, working together can be very painful.

From my perspective working on complex, emergent solutions that require a lot of communication and free expression being co-located is the most conductive and least inhibiting way to work. Sure, on paper there are technical solutions for pretty much everything, though there is one thing they did not solve: Human nature.

From what I know Humans are “designed” to work best in direct interaction. Expressing, finding, establishing and maintaining shared values and a unified vision is something that has shown, at least for me, to be very time-consuming and costly trying to do it remotely.
Especially if you’re working with a new team the issues of trust, prejudices, fear of looking stupid and general unease can take weeks and months to be resolved, if they can be resolved at all.

I’ve been working with people remotely and had – despite honest efforts – severe communication and alignment problems. Then we finally met for a week of working co-located. And suddenly it clicked. It was the actual closeness, the direct face-to-face communication that broke barriers and tore down (hidden) misunderstandings that had been existent for months.

I look at current efforts (at least in my division) to co-locate teams and break up distributed structures. I see Design Thinking Workshops that emphasize high-energy, low-friction direct face-to-face interaction. I see the difference in my daily work between remote and co-located teams.

For me this tells me co-location is not a luxury but a necessity to fully unleash teams and employees potential. Companies that are driven by innovation, not lowest-cost, should use co-location as an investment to stay competitive. And I welcome any efforts towards this goal.

Introduction

I’ve recently attended an instance of a virtual training course on interviewing job candidates. While the course and trainer were great – make no mistake here! – there was one thing that made go ballistic.

While portaying the benefits of the specific interviewing approach, about 5 slides in, the “Utilization Rate” was named as one of the most important metrics of a successful hire.

Come again?!

I’ve then asked what “Utilization Rate” meant and it was exactly as I feared:
The amount a hired person was being busy on a given project.

Utilization is good for machines

Coming from regular business education I know that a lot of traditional management practice revolves around making sure resources are used to their maximum efficiency.

After all if you pay a resource for time you may as well make sure you’re getting the most output in that time.

This works well on the factory floor. With machines.

If you are renting, let’s say, a assembly robot, for a rate of 1000$/day flat you better make sure that robot is assembling like hell distributing the fixed cost over more pieces produced.

This theory worked well there so why not transfer it into the office?

People are not machines

The difference with people is that people are not machines.

People are not steady in their output, not do they perform the same under 50% workload as they do under 90% workload.

If you look at the concept of “Slack time” this describes that when doing time management you should always have more than 20% of buffer available for dealing with interruptions, unplanned work or plain socializaton.

People with near 100% utilization are very rigid in their schedule and unable to cope with rapidly changing requirements. They also become robot-like having zero time for their colleagues, which actually hinders them in getting things done, as the informal (social) networks are oftentimes the key differentiator between someone who could and someone who can.

Looking at other literature, for example “Focus” by Daniel Goleman, a key factor in creative, breakthrough thinking is the ability to be able to control the flow of your work including time with no specific commitments.

Furthermore – looking into all the learning and community initiatives – all of those make you more connected, knowledgeable and ultimately a happier person. When should you do all this if you are near 100% utilized? In your off-hours?

Keeping skills and networks active and cultivated makes sure that people that are effective today will STAY effective tomorrow.

Truth be told – going for high utilization will give you better results in the short term. But with our rapidly changing world constant investment must be made in education and personal development.

With near 100% utilization there is no time to make that happen. In the long term this will mean that any “resource” will become less effective and fast.

Trust

Why even care for utilization?

I believe it comes from the thinking that a manager has to know that everyone is busy. But why would that be necessary?

If you assume your workforce is made up by Theory X people you have to assume people will try to trick you as soon as an opportunity presents itself. That would require a lot of command & control because you cannot trust a Theory X person.

Fortunately no human being is a Theory X person.

All human beings are Theory Y people, striving for purpose in life, trying to get enjoyment and fulfilment in what they do.

You have so many talented people in your teams. People with rich experiences, a large inventory of education and perhaps even a healthy amount of humor.

How come you trust these people to arrive at work every day, navigating 66% of the rest of their life on their own, but as soon as they have entered the office floor you treat them like unreliable, greedy, selfish idiots that need constant supervision?

You already have the team you need to get the job done.

Trust in their ability to solve the issues in your project. Give them the freedom to act without having to come to you for approvals constantly.

Establish an understanding of and and agreement on the goals and why they are worth achieving and the rest will come naturally.

Measure by Results

In the end it does not matter that everybody was very busy on your project. It does not matter that you can show that all of your resources were 98% utilized.

The only thing that matters is what the project can deliver and if the results are what the client & business need.

That is why in Agile we have empowered teams that focus on goal attainment while the manager steps back. That is why we focus on servant leadership to ENABLE all of the workforce to do the best they can.

Establish goals that are worth attaining.

Explain the why and listen for questions and new perspectives you might have missed.

Create a shared understanding and agreement of the road ahead.

Get the heck out of the way.

Be available and open to answer questions on the way and help out if someone is in trouble.

“Would you have any pointers to any internal or external information you recommend on guiding/teaching scrum masters on how to be an effective one?”

This very straightforward question actually has a complex answer.

The main cause for this is that the role of the Scrum Master is, intentionally, not something that you can map to some of existing clear-cut roles of Project Manager, Team Lead, (People) Manager. It also has some restrictions that are required to keep the role effective.

So before I delve into dishing out recommendations, I first want to deconstruct the role that is a “Scrum Master” from my first-hand experience and point-of-view.

Overview

As said before the Scrum Master role is a hybrid. It has been intentionally crafted from different pieces of other roles and received new responsibilites. As such many people, especially if they transition from traditional roles (e.g. as a Project Manager) struggle. I’ve seen quite a few attempts at “mapping” existing processes and behaviors to the new role. My take is, if you actually “succeed” in doing that, you miss out on the chance of a profound change in the way you work and thus forfeit many if not all of the benefits this brings.

So with that in mind let’s not try to see what role is similar to a Scrum Master or how you can best map your existing stuff – let’s take a look what a Scrum Master, in my opinion, should focus on.

The Scrum Master’s responsibilites are broken up among three areas, all in equal measure.

1. Process

Knowledge and application of Scrum within the Agile Mindset. Understanding the different elements and artifacts, why they have been created and where to apply them.

2. Coaching

Enabling others to understand and implement the Agile Mindset. Understanding their issues and offering support in resolving them. Helping the team and stakeholders to achieve mastery in their craft.

3. Leadership

Offering guidance and a clear vision where needed. Ensuring organizational alignment across all levels. Establishing and maintaining communication between involved parties. Creating transparency where ever possible.

Beyond Process Ownership

The first thing that might be surprising is that the responsiblities go beyond pure “Process Ownership”. Although the Scrum Master is usually introduced as a role to whip the team an stakeholders into shape the role needs to quickly transcent that singular focus if to be able to unleash to the team’s full potential.

Just owning the process alone but not being able to foster understanding in the “Why” and communicating the results will just lead to people blindly following it “because Scrum says so”. How will you ever achive wide acceptance or continuous improvement if nobody gets why you are actually going Agile (Leadership) and addressing their concerns (Coaching)?

Providing Coaching without knowing the process can cause you to miss the realities of the business and denies you the tools to model the day-to-day work (Process). Also if people do not follow your leadership why would you even make suggestions (Leadership)?

Finally assuming leadership is not something reserved for those carrying a “Manager” title. Everybody can take up leadership if the cause is worthy and the time is right. That said a Scrum Master is the embodiment of a “Servant Leader” – working not to order people around but to offer assistance and then get out of the way as quickly as possible. To provide leadership you need to understand the issues people are facing (Coaching) and have the right tools to offer solutions (Process).

In the end it all comes together to form a whole, rounded role that goes way beyond Process Ownership.

No Discliplinary Power

In my opinion the Scrum Master cannot be someone with disciplinary power over the team members.

The Scrum Master can also not (asked to) be part of the performance review process for team members.

Why?

The Scrum Master’s goal is to unleash the power of the team. To that end the Scrum Master must work on neutral grounds and the principle of confidentiality when talking to to team members, especially on touchy subjects.

Sometimes team members may be hesitant to name issues openly if it concerns their work, mistakes or other people – especially if the person they are talking to is supposed to hand out their performance rating at the end of the year.

A first-line manager cannot be a Scrum Master. Avoid this at all cost.

No Part-Time Job

If you look back up at the three responsibilities you see topics that are as vast and diverse as can be. Many companies today are hiring people for full-time Scrum Master jobs.

And for a good reason: It is a full-time job.

To enable a Scrum Master to actually be able to fill out all of these responsibilities the time has to be available to do so.

Just adding Scrum Master responsibilities to an existing “Developer” or “Lead Developer” role might sound obvious but is also wrong.

The dual role automatically creates a conflict on time allocation starving both roles for focus and attention. With the constant context switches and lack of depth you will not see a 50:50 split – rather something along the lines of 20% and 20% is more realistic. Around 60% will be getting lost because of interruptions and the person becoming quickly overburndoned and entering a purely reactive state, working down the ever-increasing stack of “stuff to do”.

This not only increases stress but also a creates a liability for the team and the business as both cannot rely on the person to both deliver the development and Scrum Master commitments.

If you want somebody to become a Scrum Master make it a full-time job.

Also: A good Scrum Master can handle two teams. An excellent Scrum Master can handle one team.

Mindfulness Required

Just as the Scrum Master is not just a Process Owner the person owning the role is not just an employee – we’re (thankfully!) working with human beings. And this requires a surprising knowledge of the human self.

Mindfulness is a broad topic oftentimes stretched to cover different areas of conscious behavior, recognition of (inner) body signs, empathy and vision.

For me mindfulness starts at the self – recognizing that you are more than just your intellect and logic. Accepting that your emotions and instincts are not something to be turned-off or pushed away. And finally listening closely to what your body is very subtly trying to tell you. If that sounds like new-age feel-good mumbo-jumbo… well, let me tell you that ignoring all of this for too long could lead to you being at an all-time high stress level until you suddenly get nosebleeds in meetings and almost collapse from exhaustion. All the while being completely confused why you are all-time angry and your damned body refuses to play along.

This is not a place you want to go. Ever.

The problem with a lot of that is many people – including me – have learned to suppress their needs over so many years that the natural signals are no longer properly recognized or automatically subdued. This is not a process that happens in a few weeks or months. It takes years to manifest – or “learn” – until it has become a state that feels completely “natural”.

A Scrum Master being lodged in between many parties and having to negotiate sometimes really tough topics needs to have a lot of mental and physical buffer to take almost anything with a degree of calm and professionalism. This calmness cannot be enforced or upheld by pure will. It is something that requires the Scrum Master to ensure regular de-compression from stress and work-related pressures.

To do be able to achieve this state is is neccessary to properly and honestly understand where one currently is. How stressed am I really? What do I REALLY need now? What is my body REALLY needing now?

This requires careful approach, reflection and – especially – time.

This creates a shared responsibility both for the Scrum Master to establish practices for Mindfulness as well as the surrounding business to give the space to do so.

Failing to do so could jeopardize entire teams by subjecting them to overworked, stressed-out Scrum Masters.

It’s About Succeeding Better

You might have heard of other projects that did things that I have recommended against and still were considered successful. And I have no doubt that they were successes.

But have you ever asked yourself it there is only a binary state of Success/Failure or if there are degrees?

What if the projects you heard of where successful with only 20% of their potential realized? Where would the projects be now if they could have realized 50% or even 70% of their potential?

To come full circle with the initial question about become more effective a lot of the options here are not about “just” succeeding.

They are about Succeeding Better.

I invite you to try them out for yourself and let me know in the comments or via email how it went for you.

Schism

Something is amiss in Project Management Land and it’s not the usual “Traditional PM vs. Agile PM” squabble. It’s a lot more fundamental as it goes to the core of every project:

The measure of success.

This is different from the question of goal attainment, a topic which in my opinion has been examined from a lot of different angles and can be measured to a satisfactory degree, from the very basic following the SMART / INVEST criteria to fully-fledged project scorecards. No – this is not about goal attainment, it’s about finding out if we’re are targeting the correct goal in the first place.

“A major cause of the disconnect between completion and success of strategic projects is that most PMOs still rely on the same old metrics as a proxy for success:
Operational measures such as on-time and on-budget, and stakeholder satisfaction.”
– Matt McWha, CEB IT Quarterly Q3 2014

“We’re all familiar with the phrase “what gets measured gets done,” but what if we’re measuring the wrong things?”

– Andrew Horne, The IT Scorecard Disconnect, How Metrics Can Derail Your Strategy

Could it be that over the years we have become utterly efficient at checking for goal attainment and lost contact to WHY we’re actually pursuing these goals?

The Curse of Tradition

Tick the checkbox next to each of these requirements and the project is golden and we can move on to the next task. If only it were that simple.

Traditional KPIs usually miss one central aspect: Short and long term contribution of the project to business success.

Not true you say? Well tell me – when does a project end? Does it end when the delivery is complete? When the customer has paid?

What about long-term effects such as market share? Reputation? Or even more down-to-earth things as ongoing maintenance / support costs?

All of these effects contribute to a business’ success but very few projects are monitored beyond the hand-off to the customer – and even if they are it’s usually with the wrong metrics or the wrong intentions.

Long-Term Effects

All of these issues create the problem of a business closing off projects one-by-one but ultimately stumbling towards doom.

What we need is not blindly following a plan but an examination of long-term effects on the business. This requires new KPIs such as:

Project Fit with Customer’s Needs at Time of Delivery
Delivery is not about what the customer wanted twelve months ago but is needed now.
On average 33% of all requirements change within 12 months. Was the project able to keep up?

Effect on Business Reputation
Did the business reputation bloom or suffer during the project?
What are the long-term implications on the brand?

Development of Turnover Time and Cost for Change Requests
How fast was the project team able to integrate change requests?
What was the cost associated with each change?
What is the trend of the turnover time and cost?
Did the project team get more efficient over time?

Team Knowledge Accumulated and Shared
What new skills have been brought into the team?
What is the level of existing skills?
Has knowledge been transferred between individual team members?
What new ideas and developments have started as a side-effect to the project?
What is the long-term implication on the business’ ability to deliver?

Ratio of Participation in Innovative Development
What’s the ratio of projects targeting an innovative market compared to those targeting a saturated market?
Is the business just treading the ground it already knows or is it pursuing new endeavors?

Level of Project Sponsor Engagement
How did the executive sponsor’s engagement develop during and after the project?
Where they engaged? Did it seem that they recognize the project’s importance or were they mostly just walking piggy-banks?
Do the projects align with the corporate vision? (Usually goes hand-in-hand with high sponsor engagement)

Market & Mind Share Gained
What was the effect on the market share of the business? Will it be able to look back on an expanded market share?
Perhaps by winning over return customers and creating positive word-of-mouth/references?
Did the new product capture new market share? How did the market share develop over three, six or twelve months?

Long-Term Project ROI
Was the project actually worth the investment?
This is not just adding up costs and comparing with project income – it’s also about measuring the impact on future business.
Did the project drive the customer away or did it actually increase the prospects of new contracts?
Who said that the project will only pay out once?

As more and more projects shift to the Agile methodology more focus is put on the entire team’s performance and delivery. This in turn means it does no longer matter if you as an individual have completed all your assigned tasks if the team as a whole has failed to succeed. While the approach of “we’re in this together” is definitely a large step forward when delivering value and results it becomes problematic when managers are required to do individual performance assessments of each team member.

While I do not have the perfect solution I want to give some insight in my personal experiences and opinions on this topic.

There is no Team in I

The main problem with the situation is that Agile promotes “one team” thinking which is tremendously beneficial to the performance and success of a project. On the other hand high-performers want – and to some degree – deserve to be recognized for outstanding work. The issue of if and how to reward individuals in a team environment is a tough cookie on it’s own that I’ll skip in this context.

What I do want to emphasize is that in an Agile environment the individual rating of team members is made even tougher as you technically need to separate the contributions to the team result. Also the question comes up: “If I emphasize team results and team achievements, what do I set up as hard, measurable success criteria in the Performance Assessment?”.

For both questions there is no ideal, one-size-fits-all, silver-bullet solution. But there is perhaps a way to be both Agile and be able to recognize performance fairly.

Hard Facts for Everyone

When it comes to hard, measurable business results I would always recommend to do this on a team level. This means goals like release dates, quality metrics, X amount of leads converted into contracts, etc. should always be defined for the entire team. These global goals then go into each team members’ Performance Assessment goals. The important part is that everyone on the team has to have the same shared goals. It’s not okay to cherry-pick or let team members choose their own selection.

If you cannot define goals that can be applied to the entire team then it might be worth investigating why people with widely differing goals are put together as a “team”.

It might be preferable to openly discuss and define these goals in the entire team so that everyone can contribute. In the end it’s important that every team member can commit to the shared goals and be evaluated by them.

Using this technique you can enforce the “one team” spirit while at the same time laying hard ground rules for evaluation.

Going Soft

It’s pretty obvious that successful project work is a lot more than just following a set of defined, measurable goals. It’s also HOW the team approaches new challenges, works together and gets the value delivered.

This touches upon areas such as problem solving skills, inter-personal communication, knowledge-sharing and the general work values. As these things are less easy to define and may differ from the assigned/perceived role of a team member things will get difficult at this point. I would recommend splitting Soft Skills into two groups: General team rules and individual expectation.

The general team rules should encompass how the team approaches a given situation, it’s work ethic and conduct. This includes things like “We will share knowledge” or “We will identify the root cause instead of treating the symptoms”.

If you have defined the general team values when initially creating the team AND WRITTEN THEM DOWN – good job! If not it now would be a good time to have the team define these general values and write them down (e.g. as a poster on the wall) so it is clear HOW the team accomplishes it’s goals and goes about the daily work. You should make it clear that the team will be evaluated on each individuals follow-through on these rules.

It’s important to note that these rules should be a guideline and that it is okay and normal if people are not always 100% or even 80% on track – we’re still humans not machines.

For role-based expectations, e.g. if you have a team lead, architect or someone with a special role on the team you should define the expectations as you would with every personal goal – direct and in private.
As it is clear that these expectations are tied to the individual and the individual’s role this approach does not conflict with the general team rules and you can draw the line more clearly.

Matching Expectations with Reality

When it comes to comparing the expectations with actual results the approach largely depends on what you are evaluating. The hard, measurable team goals can be checked during sprint review and delivery gates. The approach will be more or less the same as with every other business goal. For the “Soft” values and skills things get very different very fast.

Any kind of evaluation of the softer goals requires experiencing how the team acts. This means attendance at the regular team events such as Scrum Meetings and Sprint Reviews is pretty much required. How will you evaluate somebody if you haven’t seem them in action? But by all means do NOT visit the meetings taking notes on each members performance! It’s more about getting a feeling where the strengths and weaknesses are. If you are not directly involved in the project because you are “just” the line manager make sure that you regularly check in with the project manager / product owner involved. Also make sure that the PM/PO understands what criteria you are evaluating team members on so you can get meaningful feedback and not just a general “performance was pretty okay”.

Another tool at your disposal are 360° reviews. These kind of reviews take in feedback from peers, managers, people-managed and the person in question to form a better picture of the performance. If you want to do this make sure you understand how the review process works as it is quite different from the regular manager-evaluates-employee approach and also be open about your intention to use it.

In the end you should be able to combine business results with feedback on the individual’s “softer” values to create an accurate evaluation without counteracting Agile’s spirit of teamwork.

“Gotta Keep ’em Separated”…. really?

So here you are, setting up your new project. And what do you need? A couple of Devs and then some people doing QA? Right?

Wrong.

In past many software projects have separated development and QA or “testing” duties into different teams. This trend has been changing over the last few years to have only one team with devs and a couple of QA’ers.
It’s a step forward but we’re still not where we want to be:

A single, unified team able to take on the different duties as needed.

And here’s why it matters:

1. Goal Orientation

Separating Dev and QA even if it is just by assigning these duties to specific people immediately creates differing goals for these groups. Devs will want to release software, to complete their stories and move on with the next task. Who blocks their progress? The QA’ers or “testers”. The QA’ers on the other hand have the goal of providing test coverage and preventing defective deliveries from being released. So they have to “clean up the devs’ mess” all the time.

Who of these people actually has the unified goal of both RELEASING and having GOOD QUALITY? Usually no-one.

If there is no-one specifically assigned to Dev or QA duty it no longer becomes a matter of coding something or getting it tested – it’s now a team goal to deliver results.
The difference might be subtle but it’s actually quite the game changer.

2. Flexible Assignments

Depending on how a project might progress the Devs might actually deliver new functionality faster than QA can cope with testing coverage. While unit tests should be present given a TDD environment (more on that later) the system and end-to-end tests also need to be done and they can be a huge time-sink. In other cases QA might be comfortable keeping up with the Devs but (or because) they are falling behind in their project plan.

Neither situation is ideal. And instead of having to bring in new staff it’s a lot easier to shift people into different areas as needed.

And this is A LOT easier if no-one clings to a specific position in the first place. That way workload is automatically balanced as needed by the team and project as the overall success (see #1) is a shared goal.

3. Skill Mixture Needed

When looking at test-driven-development it becomes clear that a developer can no longer concentrate on just creating code. A considerable degree of testing knowledge is also needed to provide the necessary (and effective!) test coverage.

When looking at the QA side the times of grinding through a sheet of manual tests is coming to an end. Initiatives such as CI and DevOps mandate fully automated testing from day one. However this testing automation does not magically appear, it requires a lot of coding on the QA-side of things. This requires a considerable degree of programming knowledge.

All things considered a developer can no longer work without testing knowledge and a QA’er needs programming knowledge. Mixing skills and knowledge in a team is therefore absolutely necessary.

The Bottom Line

Modern projects require a team that is aligned with a shared goal – to deliver a high-quality product on-time. Constantly changing needs and requirements make it necessary to be able to shift workloads quickly and flexible without being tied to specific people or teams. And with the TDD/CI requirements of modern DevOps-driven projects the skill separation between Dev and QA has become non-existent.

It’s okay to bring in people with different skills together – but in the end it requires a combined team effort to be successful, not the combination of a few loose parts.

What if you could estimate about 40 Stories in just 10 minutes?
“Impossible!” you say? Well then – read on!

What are estimations really?

They are an attempt to guess what the future will bring based on a multitude of factors such as experience, hard data, gut feelings and the likes. Estimations are also always wrong. How much depends on the subject and the person or group estimating. But nevertheless they give us a valuable guideline and basis to do a conversation.

With that established let’s take a look at Magic Estimation, originally introduced by Boris Gloger on the South African Scrum Gathering.

Idea behind Magic Estimation

As established estimations are usually wrong but a valuable guideline. However time spent on estimations helps do the right things in the right order but does not directly contribute towards the project goal. A team can be very busy for months estimating this and that and not produce a single line of code. Magic Estimation tries to harness the wisdom of the crowd to quickly estimate a large backlog – and by quickly I mean “within minutes”. It therefore reduces the time spent on estimations while retaining their value.

Prerequisites

You’ll need a backlog that has stories in a shape that they can be (at least roughly) estimated. Following the “Story Maturity” method described in an earlier article of mine can help you with that. Apart from that you’ll need a team of five to ten people and 15 minutes of time.

How-To

Print out all stories (one per piece of paper) or fetch the story cards currently in our backlog – it’s important to use paper. This will not work using a computer.

Shuffle the stories and put them on a stack face-down

Prepare a table where you designate areas to a specific story point. You could start with a “1” area and then go upwards. The idea is that people can place the story cards in that specific area to indicate their estimation

For the next 5 minutes follow steps 5 to 9

Every team member picks up a story from the stack

IN COMPLETE SILENCE quickly skims the story and decides in which area on the story point scale to put it

NO DISCUSSIONS

Whoever placed his/her story picks up a new one from the stack

Repeat until all stories are placed

Write the current estimation on the story paper

IN COMPLETE SILENCE everyone can move any number of stories to a new location (**)

As soon as the story was moved strike-through the prior estimation on the story paper and write the new one down

Do this for 5 minutes

Collect results

(**) As an alternative of moving the stories around you can also shuffle the stories into a new stack and repeat from step 5.

Collecting results

Stories that have only one or two estimates (with one crossed out) on them will retain that estimation for this session.

Stories that have more than two estimates on them will be gathered and need to be looked over, as there seems to be widespread disagreement on the effort required. You can schedule the discussion for a later date or address it directly.

And with that you’re done!

The Bottom Line

Magic Estimation allows you to quickly get estimations for a large stack of backlog items. These estimations are rough – yes – but they will give you a feeling where you are with your project.

They can also trigger a lot of healthy discussions without spending too much time on backlog grooming – giving you more time to work on you project instead of sitting in meetings.

In the past we treated Stories mostly like a rough idea with more details to follow as needed. Scrum states that you do not waste time on unnecessary detail and documentation. So this handling fits right? Wrong. A lot of people understand the lowered volume of documentation in Scrum as “do no documentation at all”.

The difference is on the emphasis on “unnecessary”. This means leave out anything that you do not need or will not need in the immediate future – but still do EVERYTHING else.

For Stories this means you need to look at your stories regularly to find out what they are in and if they are ready to be tackled in a sprint. If do not track this status closely you might end up with a lot of rough ideas that lack refinement or details at the time they should be put into a sprint. In the worst case you look at your backlog and marvel at all these stories and elements in there – without knowing that most of them are missing crucial refinement.

The end result is that you will spend a lot of time in your planning meetings trying to salvage the situation or –even worse – do not spend the time and have the team work on unclear requirements and scenarios. To get around this issue my teams and I developed a story lifecycle called “Story Maturity”. This lifecycle tracks the story from inception to sprint-readiness and sets ground rules for each step.

Story Maturity

So how does this work? First of all we acknowledge that stories are living documents that evolve from a raw state into an actionable item. However this does not occur automatically – a story does not ripen like good wine – it requires effort. Some stories will be a no-brainer and easy to refine some others require more attention – but either way you and your team will have to spend the time on getting them in shape for the sprint – BEFORE the actual planning meeting starts!

Story Maturity follows a set of status values and rules for their handling which are outlined below:

Initial

The story has just been discovered. It lacks necessary detail and may just be a snipped that you wanted to put in not to forget it. Stories in the initial state always go into a special backlog. This may be the overall backlog or a “fountain of ideas” backlog where new stories gather. Do NOT put them into Release Backlogs or Sprints or you might otherwise end up with a lot of clutter that needs to be weeded out.

Stub

This story has received some work but is still missing crucial information. For example the actual story is missing (“As a …. I want to….”) or the Acceptance Criteria were not filled out. The Story remains right where it is and will have to be worked on – usually by either the Product Owner or the discoverer of the story idea.

Unclear

This story has the necessary filling but something is still unclear. Perhaps the requirements are not properly measurable, perhaps the goal is not clear. This state is usually set if during planning a lot of questions or conflicting views were raised. You put this story under close watch and get the responsible people together to make it more precise. The story remains in that state until the responsible people have agreed that the story is clear enough to be estimated.

Estimation-Ready

The story is clear enough to run through a quick estimation. This means it has the actual story, description and acceptance criteria filled and can easily be understood by all team members. A story in this state can be PROMOTED by the Product Owner (and ONLY the Product Owner) to move from the “Fountain of Ideas” into a regular Release Backlog. The creator of this story should either pitch the story before the sprint planning meeting or do an impromptu elevator pitch of no more than 60 seconds to get a story promoted.

The next step is to do a short poker session of about TWO MINUTES. Yes, two minutes. No longer. Do a quick poker session and if you have estimates that are very close together (no more than one step apart, like 5,5,8,8) you either take the majority or the higher number. If you see a discussion breaking out or if the estimates are wildly distributed the story many not be as clear as it should.
The team should then decide if they want to spend the time now to make discuss the story or if it has to be put to “Unclear” and will not be part of the sprint being planned.

Depending on the situation a team might immediately continue with the Pre-Estimated step if the story is likely to be tackled in the current sprint. If it goes back to the backlog this is where you can stop and move on to the next item.

Pre-Estimated

This state means that the story has passed through a pre-estimation session with all the requirements for it. The story is usually in very good shape and can be plucked from the backlog. To get it “Sprint-Ready” the team has to do two simple tasks:

Check if the story is still applicable and clear in its current state

Do a final poker session

If both of the above tasks are completed the story can now be set to “Sprint-Ready” and put into the backlog of the upcoming sprint.

Sprint-Ready

This story is good-to-go!

Story Promotion

The Product Owner is accountable for both a project’s success and failure. He or she should therefore be the only person that can have a final say on what gets in a release and what does not. Therefore newly discovered stories do not just waltz into the release or sprint backlog – they have to be pitched to the Product Owner.

The Product Owner should regularly look into the separate “Fountain of ideas” backlog and be open to people trying to pitch their stories. However at the end of the day the Product Owner has the final say on the contents of the release backlog.

That way you can ensure harnessing the full creative force of your team and stakeholders while not diluting your backlogs with unrefined ideas.

Benefits

What this story lifecycle called “Story Maturity” gets you is transparency on the work necessary before a story can be tackled and a clear indicator if you can dare put it into the next sprint or not. By following these indicators closely and being very honest while doing so you can cut down the time necessary to spend in the planning meetings.

We went from three days planning to less than three hours following that lifecycle.

The Bottom Line

By acknowledging that User Stories are a living document that evolves with the right amount of effort you can create a meaningful easy-to-use backlog that will show you exactly what is ready to be tackled and what needs additional work. You also reduce the time spend in planning meetings feverishly trying to cobble together work items.

In the end your team will spend a lot less time sitting in meetings and a lot more time doing what they love: Creating meaningful software.

„These are your five top priority items.“– „Which one is the most important one?““All of them.”

Or something like this:

“We have to set the priority to High – all Medium or Low items will most likely not make it anyway.”If so you’ve likely been in Priority Hell.

Priority Hell is a place where every single item is of utmost importance, where there is no clear distinction between all the “High Prio” items, where Priorities like “Very High” or “Urgent” have reared their ugly heads. Priority Hell is also a place where everything is being worked upon but nothing gets beyond “Almost done”.
Priority Hell is a scary place.

The Root of All Evil

You might ask yourself why I cast priority in such a bad light even though it is supposed to give us guidance on how to proceed where to concentrate our efforts. And you are right that priority in general terms is GOOD. Focus is also good. But avoid flailing around aimlessly in hopes of tackling the right things first. What’s bad is the way priority is implemented and used in most of the current work processes.

For the sake of this post I’ll concentrate on the implementation of priority in Rational Team Concert – acknowledging that it is used as the main choice in project tracking and collaboration inside SWG and a lot of teams already use it. However all of the critique can be applied to other tools such as MS Project or even Excel.

Now let’s look at how priority is implemented:

You usually have three options: Low, Medium and High.
Since you can assign the category freely what becomes High or Low is entirely up to you. Sound good so far? Read on.

Opportunity Cost

What prevents you from setting everything to high? Nothing – and over time there will be a lot more things on High priority that you would imagine. The reason for this – in my opinion – is that the freedom to assign everything to high alleviates the need to make a hard choice and to weigh elements against each other. Economists refer to this as opportunity cost, meaning the lost value of the option you discarded. And make no mistake – by having to choose between two elements in terms of priority makes you take into account the risk that the lower-prioritized element will maybe not make it. It’s a lot easier to just assign both to “High” priority and assume you do not have to make a choice.

Assume that you have your list of elements and got about six elements with “High” priority – which one is the most important one? Which is the second-most important?
“All of them are important, silly!” you shout in anger – but what will that get you? Your team will start on all of them in parallel either rigorously multitasking or splitting the resources across the different elements.
Following the stream of recent publications one can assume that multitasking is one of the biggest efficiency killers of the modern work era – that’s why for example Scrum dictates that no changes to the team or plan are made within the sprint and that team members are assigned to a single team only. The same with splitting resources – assuming that your workforce is not large enough to create six separate teams to work on these items you will most likely starve certain items from manpower and knowledge.

Both factors cause work to progress slower and less efficient ultimately leading to the situation where everything is “almost” or “80-90%” done but nothing is really finished!

If you are working with a small team of about four to nine people (managers excluded) it is absolutely necessary to avoid starting multiple tasks at the same time – otherwise your resources will be spread too thin. Scrum for example suggests that instead of fanning out the ENTIRE team will tackle the top priority story from the backlog before moving on to the next one.

A Question of Leadership

For that you will need a clear distinction of priorities. A ranking has to be established that also addresses the order of items within a priority.

This ranking is a mixture of both the technical need of the item and the overall business need in terms of the project.

This integration is a leadership objective that needs to be covered by the Product Owner to be successful. On most teams the Product Owner has detailled business knowledge but only limited technical insight. For a knowledge worker this is just the other way round: She understands an item on the technical level but may lack the business knowledge. Only by integrating both the business need (following customer value, strategic alignment, etc) and the technical need (architecture requirements, technical constraints, etc.) can a reasonable piority be established.

It ultimately boils down to the team, with the Product Owner in a leadership role, to steer the project to deliver the right value at the right time and not build an imaginary ivory tower.
This steering towards delivering value is what relative prioritzation can deliver.

Relative Prioritization

A team following a ranked list of elements can focus efforts on achieving the highest, unfinished element on the list before moving on. This ensures past work is actually completed before opening the next can of worms. Also you are directly following customer (or Product Owner if you will) value – achieving the most critical elements first.

Ranking – in Three Easy Steps

Okay – “Easy” might stretch the truth a little. Doing the changes is easy living them might be more challenging.

Step 1: Get rid of traditional priorities

This first step forces you to let go of traditional priorities as it effectively blocks access to and knowledge of it.

Step 2: Use the “Ranked List” view for all planning and sprints

Then set the “Ranked List” to be used as the default view so you have a clear picture of the project priorities at all times.

Step 3: Work with ranking for prioritization only

The last step is to step up on the discipline side by only addressing the top element on the list and only that.

If the element is too small – think about bundling work differently so your entire team can work at least a day on a single story.
If some people cannot contribute to an element find out why. The most common reason is lack of skill in a particular area. If so actually take this as an opportunity to do skill transfers using techniques like Pair Programming.
If the element concentrates on a single area of work but will later be integrated with other components find out how you can do a little slice of integration now. Agile & Scrum prefer doing a “vertical slice” or “End-To-End” approach by creating a sliver of integrated functionality on all layers of the project instead of big, separated chunks.

Apart from the tackling of work you will also focus on ranking new elements as they come it. If you let them rot at the end of the list – chances are they will not be picked up in time if your team follows the “Top element first” procedure diligently. By doing ranking close to the item’s creation you are also working on a fresh memory what this item was all about – thus reducing the time to remember or fetch information later.

Both parts of Step 3 will not only ensure completion of elements in the correct order it will also surface issues you might have with team skills, work package size and alignment with the “end-to-end” approach.

The Bottom Line

Traditional prioritization in the broad “High”, “Medium” and “Low” categories leads to ambiguous item priorities. Which one of the “High” priority items should be addressed first? Should all of them be addressed at the same time? Also the addition of new requirements and work items can bloat a category severely leading to the “Everything is High” syndrome.

The result is too many open work items, everything “almost done” but nothing really finished and a lot of time and resources lost on multitasking.

A way out of this situation is to do away with the traditional prioritization categories altogether and adopt ranking.
Ranking ensures that a clear and unambiguous order of work is established, items are prioritized in relation to each other and the team as the ability to focus all efforts on finishing the most important work item first before moving on to the next one.

]]>https://mseul.com/2016/12/13/why-traditional-prioritization-is-evil/feed/0mseulScrumerfall (or: You’re Problably Still in Waterfall)https://mseul.com/2016/12/12/scrumerfall-or-youre-problably-still-in-waterfall/
https://mseul.com/2016/12/12/scrumerfall-or-youre-problably-still-in-waterfall/#respondMon, 12 Dec 2016 09:41:30 +0000http://mseul.wordpress.com/?p=62Continue reading →]]>The transition from classical project management and development to Agile & Scrum can be quite drastic, turning the way work is done on it’s head (TDD) or even doing away with some things altogether (long isolated phases).

A lot of teams struggle through the transition – especially while working with legacy code that did not see the light of day on the green fields of Agile development but was created under the unyielding whip of crunch time.

Leaving all that – and the accumulated habits – behind is difficult.

It’s therefore all the more compelling to map existing structures and workflows and plug them into the “new way of doing things” – and then call it “Agile”.

During every single Scrum training I received over the last years the trainers always issued a stern warning to be vigilant for signs that you are not really Agile but just pretending to be.

This creates (at least) two problems:
– You are not reaping the benefits of doing Agile & Scrum
– You are stuck with the issues of your old processes & habits

The first step to address both is to realize if you are deviating from the Agile path and then carefully plot your way back.

This blog post is based on my own experiences and understanding of the Agile & Scrum processes and intended to give you a few pointers and suggestions.
It’s not an attempt to declare what is “the right way to do it” – that is ultimately left for each team to decide on it’s own.

Without much further ado – let’s get started!

1. Stabilization / Hardening Sprints

Have you ever added Sprints at the end (or in regular intervals) where code changes are reduced to a minimum and all efforts are focused towards ironing out the bugs & integration issues?
If so you have probably created something like a Stabilization Sprint.

This kind of Sprint is more-or-less a direct equivalent of the Waterfall end phase where all QA testing and bug fixing is applied to the project. It’s where all the big integrations happen.
It’s also the time where things (latest) go south. Issues crop up like crazy, the integration fails and a storm front of crunch time is headed straight for you.

When following the concept of Scrum that only code that is covered by exhaustive, automated tests and accepted by the Product Owner is allowed into the release code how can that happen?

Well in theory it should never happen. And here’s where theory ends.

Stabilization Sprints and integration issues are a sign that automated, isolated quality control (TDD, Continuous Integration) is lacking.
This is an issue most often found with legacy code that wasn’t written to be properly tested. It could also hint at a team relying a lot on manual tests.

Either way you are highly vulnerable to unexpected stability issues and late-game deal-breakers.

To address this issue is to ensure high unit test coverage, deploying a fully automated CI system and doing a full test/integration cycle daily if not more often.
Some teams automatically integrate & test code every 15 minutes.

If you already have all that implemented find out what is causing the need to spend two or more weeks on hunkering down and squashing the bugs & quality issues.
Because you should be release-ready at the end of each sprint.

2. Sprint Zero

Have you ever added a Sprints with the number zero to your planning? Or even multiple ones (Sprint 0.1, Sprint 0.2)?

This kind of Sprint usually comes up when a project is something requiring a lot of upfront research and preparation. It includes clarifying the requirements, researching on technologies, setting up the development environment and so on.
Sprint 0 is an equivalent of the Plan/Design phases of Waterfall.

Now here’s where it gets controversial:
I think that spending time on research and preparation is time well-spent and it seems, depending on who you ask, the Scrum world is undecided if Sprint 0 is okay or not.
However let’s think about what Sprint 0 actually symbolizes: No customer value delivered. (That’s why it’s not Sprint 1).

And that – in my opinion – is not a good idea.

The goal of Agile & Scrum (and especially XP) is to get you writing code and generating value as fast as possible. Sprint 0 gives up on the focus on delivering customer value entirely.
It turns the entire time spent into sunk costs – essentially forcing the Product Owner to commit resources & time for Sprint 0 and at least another Sprint before value is created.

Instead of doing a Sprint 0 try a regular Sprint and use the time for prototypes and to implement the brutally simplest thing to do – even if it’s just a big fat hack.Initiatives such as Hack Days yield mind-blowing results in just a single day. And they show what is possible and what is not by creating code that you can run and toy with.

And if you now think “Ah, but Hack Days are different” – what’s the difference? If you can be highly productive in a single day, what keeps you from doing the same in your regular project?
What can you change to enable it?

3. Sprint Length

How long are your sprints? 8 Weeks? 3 Months? Do your “Sprints” look more like a month-long death march?
Also did you ever extend the length of a Sprint because not all Stories could be closed at the regular end date?

If any of the above rings true you might be still working with the time scale & behaviors of regular project planning.

Scrum defines Sprint lengths to be exactly 30 calendar days.
Agile in general is more flexible depending on methodology used – going from seven days (XP) to six weeks (RUP).

With Agile teams can deliver smaller increments a lot faster than using regular project planning.

Both of the teams I guide as a Scrum Master are on two-week sprints. Both deliver solid customer value at the end of each sprint.
We had a lot of discussions on the right Sprint length and also tried out one week and three weeks but in the end two weeks were the ideal time frame.

Before that? Well … we were taking months between deliveries.

If your team is at the very limit of four/six weeks and still struggling – it’s not time you’re fighting, it’s most likely code quality (see 2.)

Lastly one personal remark on sprint extensions:
Do not extend the length of a sprint after it has been started. I did this once with one of my teams and it confused the hell out of people (“The sprint ends this week – right…?”).
We also de-synced from other teams leading to even more confusion down the road. While the underlying reason (a lot of people where away on holidays then) was sound the course of action was not.
It would have been better to look at the time frame ahead of the planning and check with the other stakeholders to see if there are any unexpected side-effects.

The Bottom Line

The transition from traditional project planning to fully embracing Agile & Scrum is long and can sometimes be difficult as it forces you to break with established processes & habits.Not allowing this break to happen can cause you to be stuck with the worst of both worlds.

Three common signs that your team is still in the transition phase are Stabilization Sprints, Sprint 0 and Overlong Sprints.

If you consider yourself “doing Agile” and encounter any of these signs – it might be wise to check where you actually stand.

Do you deliver customer value quickly? Can you ensure that after every Sprint you have something stable? Something created to easily find the acceptance of the Product Owner and Stakeholders?
Concepts such as Test-Driven-Development, Continuous Integration and ultimately DevOps show a way to be ready. Every time. All the time.