Author: jcdejong

Posted on

My Reading Backlog

I saw some people sharing their reading backlog and thought it was a fun idea to write mine down as well. Looking back at 2018 I was quite surprised how much books I managed to read.

If you know some books I should add to my backlog, please let me know!

A small note: I have not prioritized my todo-list, whenever I finish a book I pick something from it I feel like reading at that moment and start.

Continue reading “My Reading Backlog”
Posted on

Bye Bye Velocity. Hello Throughput.

As published by Louis-Philippe Carignan on Scrum.org

The Professional Scrum with Kanban (PSK) course has now been out for more than 6 months at Scrum.org. As one of the first few trainers who wanted to teach this course when it came out, I find that it is a great way to combine the Scrum framework with Kanban as a strategy to deliver value to your customer.

Out of the many topics that we talk about in this class, I’ve found that the use of throughput instead of velocity/capacity to be a positive change. I’ve taught the regular Professional Scrum Master (PSM) course for about 6 years now and when I get to the Sprint Planning slides, we usually extend the conversation around velocity and capacity. I pull up my complementary slide deck around relative estimation, poker planning, charts to track velocity and we spend an additional hour on this topic. I answer questions around the meaning of story points, how they should be understood, tracked and used in multi-team Agile project.

In the PSK class, this conversation is completely different. When I get to the Sprint Planning slides, I point out that the throughput history is used as an input to the Sprint Planning. With a few examples, I show how easy it can be to get from your electronic Agile tracking system (Ex: Jira) or on your physical Kanban board.

I then get a new set of questions from students which I find a lot more interesting. The conversation goes quickly around the variation in the size of the Product Backlog Items (PBIs) that are taken by the team at Sprint Planning. I can also tie it back to Little’s Law where limiting work in progress will increase throughput, thus helping students see throughput linked to limiting work in progress. There are very few questions around understanding throughput. Students find it is a metric that makes sense to the business compared to story points.

While our industry has talked about poker planning and story points since almost the beginning of agility in 2001, I think it is more than time that the conversation at Sprint Planning shifts to historical throughput instead of using velocity. Maybe one day in the software engineering museum, we can see a deck of poker planning cards next to a set of punch cards.

Posted on

Differences Between Scrum &Kanban

As posted by Al Shalloway on LinkedIn

Looking at differences between Scrum & Kanban can help us see which will work better for us.

  1. Scrum requires planning the sprint. You can plan in Kanban but it’s normally isn’t done.
  2. Scrum requires cross-functional teams. Kanban doesn’t. While making it more flexible if also may miss the opportunity for team structure improvement.
  3. Scrum requires starting with its roles, practices, events & artifacts. Kanban allows you to start where you are & provides a transition model for improvement.
  4. Scrum improves by removing impediments. Kanban improves by focusing on shortening cycle time.

Teams that don’t like to be told what to do may resist Scrum. Kanban requires more discipline from the team than Scrum.

Factors to consider when deciding which to use:

  • culture– including resistance to being told what to do &attachment to roles
  • nature of work being done
  • ability to create cross-functional teams

Note that executives can better relate to Kanban’s focus on flow. Combined with its insistence on visibility, executives can better understand the importance of managing workload.

In few cases is one clearly superior to the other. Taking a blend of the two often makes sense. Doing this is not difficult.

Posted on

How to Implement Hypothesis-Driven Development

Practicing Hypothesis-Driven Development is thinking about the development of new ideas, products and services – even organizational change – as a series of experiments to determine whether an expected outcome will be achieved. The process is iterated upon until a desirable outcome is obtained or the idea is determined to be not viable.

Read the complete article here: https://www.thoughtworks.com/insights/blog/how-implement-hypothesis-driven-development

Posted on

Introduction to Scrum

But what is the Scrum methodology, and how does it work? This introduction to Scrum PPT will explore just that. Whether you’re a manager, programmer, tester, product owner, or just want to improve product delivery, check out these Scrum presentations by Certified Scrum Trainer and author Mike Cohn of Mountain Goat Software. Source: https://www.mountaingoatsoftware.com/presentations/an-introduction-to-scrum

Getting-Agile-With-Scrum-Norwegian-Developers-Conference-2014Download
Posted on

Christiaan Verwijs’ journey towards becoming a Professional Scrum Trainer

Becoming a Professional Scrum Trainer isn’t an easy task. You need to:

  • Pass a preliminary interview with Scrum.org where you demonstrate that you have at least 4 years of demonstrable, intense experience as a Scrum Master;
  • Pass the PSM-I, PSM-II and PSM-III with a 95% score;
  • Pass the Train-the-Trainer event;
  • Pass a ‘peer review’ by a group of Professional Scrum Trainers;

Read Christiaan’s full story here: https://medium.com/the-liberators/my-road-to-professional-scrum-trainer-a347f34fe65e

Posted on

Why Agile Teams Should Estimate at Two Different Levels

It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, Mike Cohn will address:

  • Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
  • Why teams should estimate the two backlogs in different units
  • When teams should estimate
  • Whether all teams should estimate

Although I think you should not try to use hours for estimation, I agree using different valuations for an estimation is best. I find using T-shirt sizes for PBIs and Story Points for SBIs work well.

Read the complete article here, and also take note of some excellent comments at the bottom: https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels

Posted on

Kick-start 3 Scrum Teams with a string of Liberating Structures

Christiaan Verwijs wrote an excellent article about how he kick-started three Scrum Teams using a string of Liberating Structures. The complete article can be found here: https://medium.com/the-liberators/we-kick-started-three-scrum-teams-with-this-awesome-string-of-liberating-structures-19b4a409cb8d

Steps he took:

  • Defined a clear goal (purpose) of the workshop
  • Used Impromptu Networking to introduce a little fun which would make it easier to make a personal connection with each other.
  • Used Appreciative Interviews to let them discover what they would need to become a successful team.
  • Used Nine Whys to discover both their individual purpose and business reason for the team’s to exist.
  • Used What I Need From You to express their needs from each other.
  • Used Min Specs to identify team needs and created a team manifesto.
  • Used 15% Solutions to identify what the first step would be for everybody to start working effectively with Scrum.
  • Used Social Network Webbing to close the day in a positive vibe.
  • Used a number of energizers and punctuations to take a break from the intense interaction of Liberating Structures.