Posted on

Agile – What’s a Manager to Do?

Agile - What’s a Manager to Do?

As a manager, when I first started learning about Agile development, I was confused by the fuzzy way that Agile teams and projects are managed (or manage themselves), and frustrated and disappointed by the negative attitude towards managers and management in general.

Attempts to reconcile project management and Agile haven't answered these concerns. The PMI-ACP does a good job of making sure that you understand Agile principles and methods (mostly Scrum and XP with some Kanban and Lean), but is surprisingly vague about what an Agile project manager is or does. Even a book like the Software Project Manager’s Bridge to Agility, intended to help bridge PMI's project management practices and Agile, fails to come up with a meaningful job for managers or project managers in an Agile world.

Posted on

Bad or Good? Behavior Driven Development within Scrum.

I wanted to explore the possibility of using JBehave to formalize scrum's definition of done. The idea being to encapsulate a definition of done as a JBehave scenario. So in true scrum style I decided to timebox 4 hours of work dedicated to JBehave.

From a scrum point of view BDD can be used to turn the definition of done into a test artifact. The team produces scenarios for each task. With JBehave a scenario file describes the required behavior and test steps it will need to pass to be considered done. I.e Given some prerequisites, perform some action and expect some results. See the JBehave project for more detail as this is only a simple example.

Posted on

Product Owner Anti-Patterns

No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. Therefore, the following list of some of the most common Product Owner anti-patterns might be a starting point to reflect on the role; maybe, there is room for improvement?

If you recognize some anti-patterns in your daily work, why don’t you ask the rest of the Scrum Team for support? For example, run a Retrospective with teammates and stakeholders on how the team is doing regarding figuring out what is worth building.

Posted on

20 Sprint Planning Anti-patterns

TL; Dr: Scrum Master Anti-patterns

Sprint Planning is a core event that defines how your customers’ lives will improve with the following Product Increment. Learn more on how to improve its effectiveness by avoiding 20 common Sprint Planning anti-patterns.

The Purpose of the Sprint Planning

Scrum’s Sprint Planning aims to align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish their forecast. 

Posted on

Scrum Master Anti-Patterns

The reasons Scrum Masters violate the spirit of the Scrum Guide are multi-faceted. Typical Scrum Master anti-patterns run from ill-suited personal traits to complacency to pursuing individual agendas to frustration with the team itself.

Read on and learn in this post on Scrum anti-patterns how you can identify if your Scrum Master needs support from the team.

Posted on

Roman Pichler: The Product Owner [Video]

HoA #38: An Introduction

In this energizing 38th hands-on Agile session, Roman Pichler delves into your questions on the role of the product owner. The topics range from product manager vs. product owner vs. business analyst to the right size of a product backlog to linking product vision to product goal and sprint goal.

The Ask-Me-Anything With Roman Pichler on the Product Owner

During the session, Roman addresses the following questions:

Posted on

27 Product Backlog Anti-Patterns

Scrum is a tactical framework to build products, provided you identify what is worth making in advance. But even after a successful product discovery phase, you may struggle to create the right thing in the right way if your Product Backlog is not up to the job — garbage in, garbage out. The following article points to 27 common Product Backlog anti-patterns — including the Product Backlog refinement process — limiting your Scrum team’s success.

The Product Backlog According to the Scrum Guide

First of all, let’s have a look at the current edition of the Scrum Guide on the purpose of the Product Backlog:

Posted on

SAFe’s NPS Score as a Scaling Framework Is -56

SAFe® has always been a controversial topic within the agile community. Therefore, back in 2017, I ran a first survey on the Net Promoter Score® of the Scaled Agile Framework SAFe®. The result back then was -52. 

Four and a half years later, I reran the poll: SAFe® has been through several iterations, and many more agile practitioners have experienced working with it. However, the question still is: Would you recommend SAFe ®?

Posted on

The Product Mindset

Product Owner Interview Questions: The Product Mindset

If you are looking to fill a position for a Product Owner in your organization, you may find the following 82 interview questions useful to identify the right candidate. This 8th set of Product Owner interview questions addresses the product mindset.

The questions are derived from my sixteen years of practical experience with XP and Scrum, serving both as Product Owner and Scrum Master, and interviewing dozens of Product Owner candidates on behalf of my clients. So far, this Product Owner interview guide has been downloaded more than 10,000 times.

Posted on

What Is Agile Development? Part 1

Much of the software development world has adopted new methodologies, such as agile, that enable them to deliver changes and updates to critical systems more quickly and efficiently.

In this 2-part blog series, I explain what agile development is and how it helps deliver software faster and then explore how you can implement this approach in SAP.

Posted on

How to Sabotage a Scrum Master

How to Sabotage a Scrum Master: 44 Anti-Patterns From the Trenches To Avoid

One of my favorite exercises from my Professional Scrum Master classes is how to best sabotage a Scrum Master as a member of the middle management. The exercise rules are simple: You’re not allowed to use any form of illegal activity. Therefore, outsourcing the task to a bunch of outlaws is out of the question. Instead, you are only allowed to use practices that are culturally acceptable within your organization.

Read on and learn more on how to best sabotage a Scrum Master from the exercise results of more than ten PSM I and PSM II classes. (I slightly edited the suggestions for better readability.)

Posted on

7 Formats for Great Team Retrospectives

A team retrospective is a meeting at the end of a sprint, project, or milestone where the team reflects on the past work cycle and identifies improvements. It involves celebrating achievements to raise the team spirit, gathering feedback on challenges, and planning how to execute better in upcoming sprints or projects. Retrospectives are essential for continuous improvement and team growth.

Retrospective meetings are structured to facilitate team discussions and beneficial outcomes. They usually start with an introduction, then input from each team member is gathered, presented, and discussed, and finally, the next steps are determined. Gathering input usually happens in parallel. Guided by the questions of a retrospective format, each team member writes up their thoughts on sticky notes and puts them on a whiteboard (or the digital equivalent in remote meetings).

Posted on

Overruling the Product Owner?

There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if the stakeholders (who bring the budget that is funding your Scrum team) insist on calling the shots by overruling the Product Owner’s prerogative to define the composition and the ordering the Product Backlog? What if your stakeholders suffer from the “my budget, my feature” syndrome?

Join me and delve into the effects of overruling the Product Owner in less than 140 seconds.

Posted on

Scrum: The Obsession with Commitment Matching Velocity

The Obsession With Commitment Matching Velocity

Despite decades-long efforts of the whole agile community—books, blogs, conferences, webinars, videos, meetups, you name it—we are still confronted in many supposedly agile organizations with output-metric driven reporting systems. At the heart of these reporting systems, stuck in the industrial age when the management believed it needed to protect the organization from slacking workers, there is typically a performance metric: velocity.

In the hands of an experienced team, velocity might be useful as a team-internal metric. But, when combined with some managers’ wrong interpretation of commitment, it becomes a tool of oppression. So when did it all go so wrong?

Posted on

Estimates Are Useful, Just Ditch the Numbers

Many people dislike estimating work items as estimates supposedly open the path to the misuse of velocity by the managers, reintroducing Taylorism, micro-management, and excessive reporting through the backdoor. To them, for example, the proponents of #noestimates, estimates conflict with basic ideas of agile product development such as self-management, becoming outcome-focused, or leaving the feature factory for good.

I like to suggest a different, less ideological approach: estimates are useful at the team level, just ditch the numbers. How so? Estimation of work items is a fast way for a Scrum team to figure out whether all team members are on the same page regarding the why, the what, and the how of the upcoming work. The numbers are a mere side-effect, probably still valid to inform the team, though. (Indeed, the numbers are not intended to be used beyond the team level.)

Posted on

Teach Yourself Scrum in 5 minutes

I've just been appointed the CTO of a small company with less than 10 employees. Companies of this size typically don't have the luxury of hiring a professional Project Manager, hence the role almost automatically goes to the CEO of the company, since he is the product owner - Which creates a problem for me, summarised in the ingress of this article. But as the CTO, I'm also responsible for all IT choices, including infrastructure choices, so let me go through all of my choices below - Since these have consequences for the process we must follow.

Cloudless First

Cloud systems such as Azure or AWS are amazing products, with a feature list covering everything you can imagine. However, they're also ridiculously expensive, typically at least 10x as expensive as a simple VPS providing the same value from an application deployment point of view. At my last company we paid €5,000 per month for Azure, and probably something similar for our AWS account (Sigh, yes, we used both! Not my decision though!) - Let's say €8,000 per month to make sure we're within the boundaries and that I am not exaggerating. I told my developers back at that company that I could have ran the whole company on a handful of VPS servers from DigitalOcean paying no more than €200 per month in total. Nobody believed me until our CTO confirmed my numbers more or less by saying; "At my former company we ran a 300,000 EUROs daily profit FinTech company for some 200 EUROs worth of droplets from DigitalOcean."

Posted on

The Dogmatic Scrum Master Anti-Pattern

TL; DR: The Dogmatic Scrum Master Anti-Pattern

There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short "manual," this effect should not surprise anyone. For example, how do we communicate with members of the Scrum team that take the Scrum Guide literally? What about a dogmatic Scrum Master?

Join me and delve into the effects of Scrum dogmatism in less than 120 seconds.

Posted on

Should Managers Attend Retrospectives?

TL; DR: Should Managers Attend Retrospectives?

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. A classic discussion is whether it is appropriate that (line) managers attend the Retrospectives of the Scrum team. Probably, making their attendance a regular habit — or even a requirement — is not a good idea. However, what about managers that occasionally attend a Retrospective? Moreover, what if the (line) manager is also a team member?

Join me and delve into the how and when of managers attending Retrospectives in less than two minutes.
Should Managers Attend Retrospectives?