Skip Navigation

March 2019

The Humble, The Hungry, The Smart: Beyond “The Five Dysfunctions of a Team”

Building (and hiring) a great team takes time and effort. Patrick Lencioni’s “The Five Dysfunctions of a Team” became a staple reading in an Agile community these days. And for a good reason. Agile ways of working are all about teamwork. A self-organizing and cross-functional team is in the heart of the Scrum framework. In the book, the author cites the following 5 dysfunctions:

Lack of Trust due to invulnerability
fear of conflict to preserve artificial harmony
lack of commitment leading to ambiguity
avoidance of accountability amongst the team members and consequent lowering of the standards, and the pinnacle of it all
inattention to collective results due to self-serving behaviors.

Weekly Scrum Interview Question: What Is Velocity?

What is Scrum Team Velocity?

This is a tricky one, and you need to be answering it in the context of the organization you are interviewing with and its complementary practices.

Let’s start with the basics. Velocity is mentioned quite a few times in connection with Scrum in various contexts. First thing you might hear is that the velocity is a measure of the team’s ability to deliver value to the customer. That’s quite an okay definition you might give to your interviewer. Just be ready for an onslaught of questions it might bring, such as, “What do we measure”, “How do we measure it”, “Why do we measure it”.

Velocity is recognized by Scrum.org as a complementary practice. This means, that Scrum framework does not have a prescription for a Scrum Team as to how to measure its ability to deliver value. Remember that Scrum is a framework, which can work really well with a variety of practices that fit teams needs, desires, and abilities. And velocity is one of such practices.

Agile Metrics - What Happens in Vegas, Monte Carlo

Agile Metrics: What Happens in Vegas stays…

In the previous 3 articles I reviewed some of the most important Agile metrics that Dan Vacanti’s ActionableAgile software helps you to get with ease. Those were Cycle Time with the help of the Cycle Time Scatterplot, and a multitude of metrics, provided by the Cumulative Flow Diagram (CFD). In the latest article we looked at Work Item Age and its importance with the help of Aging Work in Progress Diagram.

Looking at the Cycle Time Scatterplot we discussed the significance of percentiles and how they can be used to predict the cycle time and avoid the trap of a single-number, point-in-time answer. This is cool, you’d say, but not merely enough, and I would agree. We need better techniques to predict possible timeframes for a completion of a set of work items. And, sometimes, we need to know how many right-sized work items can be completed within a given time frame.

Let’s face it, we live in a real world, where “When Will It Be Done question” is as omnipresent as ever. We cannot bury our heads into the sands of the #NoEstimates beach and hope the questions will go away. Let’s learn better ways to answer those questions.

Mastering Agile Metrics - from Cycle Time to CFD

Getting to 85 – Agile Metrics with ActionableAgile Part 2

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot as generated by ActionableAgile software. That piece also discussed some ideas the scatter plot could bring about and conversations that potentially might occur.

Let’s take a look at another important chart and set of metrics the ActionableAgile can produce based on sample or custom loaded data – Cumulative Flow Diagram (CFD).

Agile Metrics - Scrum and Kanban

Getting to 85 – Agile Metrics with ActionableAgile Part 1

Dive into the world of Agile Metrics, spotlighting Cycle Time’s crucial role in Scrum and Kanban integration. Discover how embracing this often-overlooked metric can lead to significant gains in predictability and efficiency. This article marks the beginning of a series, aiming to demystify Agile measurements and their practical applications for today’s dynamic project management landscapes.

Start with Your Customers

One of the pillars of the Kanban Method is the mantra, “Start where you are.”, start with where your customers are, with what your work is. Which is great! For the low maturity organizations and teams, it allows to skip the requisite pain and suffering that usually come with change.

While creating their first Kanban boards with many a team, I noticed that one of the steps in STATIK is harder than the others – defining who your customers are and what their pain points are. And that is not surprising for a bit. People are usually tremendously busy, switching context multiple times a day (or an hour). They tend to build personal relationships with those who ask them to do the work. They do their best, satisfying the request and moving on. They rarely have enough time to stop and think whether the status quo is acceptable. Whether their customer pool is satisfied in general, whether they are doing a fine job at properly prioritizing the work.

This is the definition of chaos.

Do You Think You Are Done?

As a Professional Scrum Trainer for Scrum.org I get to think about the Definition of “Done” and its meaning a lot. In one of the Sprint Planning event the other week, a Product Owner asked an innocent question, “I need this small thing changed, how long that might take?” An answer followed almost immediately, “it’s just a couple of lines of code.” I heard that conversation many a time before and almost always it ended with, “of course we are going to get it done, no problem.”

To those kinds of exchanges, I always have a couple of questions. What exactly do you mean you will get it done? Do you know what getting done means? Quite often the responses are either an indignant, “of course we know what done means, we have been doing it for years, do you think us fools”. Sometimes I just get a blank stare, “what do you mean.”