Community Blog

One of my favorite sayings is “Inspection without adaptation is waste”. For continuous improvement it is important not only to identify things that did not go so well but to also change something in the way you are working. If you change nothing, the inspection did not have an impact at all and is a waste of time and energy.

In the past few months I have heard several of my clients said that Scrum does not work and ask me to fix it.

Many organisations wrestle with the seeming incompatibility between agile and release management, and they struggle with release planning and predictable delivery.

Many teams are struggling with delivering modern software because they are not building with Test First Principles. Test First gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.

In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).

The Scrum Accountability Game is an interactive and fun game that you can play with others to reimagine the accountabilities in Scrum. Compatible with the new Scrum Guide 2020. Have fun! #scrumon

What's good awesome people? I hope you are well and safe wherever you may be when watching today's vlog.

What should the Development Team do when the Product Owner asks them to do work that was not planned during Sprint Planning?

One of the most common questions that I get in my classes is: What should the Development Team do when they've finished all of the planned Sprint Backlog before the end of the Sprint?

What is up awesome people? In this vlog, I am doing something different to all of my other vlogs. The topic technical debt does not get talked about often in the agile space even though some of the agile manifesto signatories like Ward Cunningham and Martin Fowler have concerns about it. 

What's up, awesome people? I hope you are having a good weekend. Recently, many people asked me how to write a perfectly detailed user story...

Without skilled developers, the Scrum Framework is no more than lipstick on a pig.

Scrum is a straightforward framework to develop complex software products in a complex environment but hard to practice.

Continuing to grow your skills is vital in a field where technologies, frameworks, and skills change so rapidly. So what do you do? How do you get other developers in your team excited about their craft?

Hello awesome people. How was your week? In today's vlog I would like to talk about one of the most important aspects of Scrum, that is the Definition of "Done".

Often we work harder in Scrum teams, but not necessarily smarter. Therefore the way we work has to change. Five tips for more effective agile work.

Should the PO really balance the level of technical debt? I just had this conversation yesterday at Sweden's "big" agile conference, Agila Sverige.

The other day, I picked up my son from soccer and he had a huge smile on his face. I asked him how it was and he answered with an even bigger smile “Awesome!”.

Some people just happen to learn more from short movie clips. And they can be a great way to bring some humor in. Also available as a Youtube Playlist.

Warning - this post is not about Scrum. It is about Technical Debt in my home!!! Please do not judge me!!

Software developers are mostly guys, happy to work by themselves at night in dark rooms. And they turn coffee, cola and pizza into code. Right?

DevOps es un área de mi interés desde hace varios años. En Diciembre de 2014, en la CAS de Barcelona, di una charla en Inglés sobre la experiencia haciendo que DevOps fuera uno de los pilares de la agilidad en la DVLA -Una suerte de DGT británica-.

One of the most important things we can do to help individuals and teams improve is coach them to embrace the agile mindset. The Manifesto for Agile Software Development provides values and principles to help guide teams in navigating the complexities of product delivery.

Hello great people of the world. Welcome back to Professional Software Delivery with Scrum (PSD) blog series with yours truly. This time we're going talk about how to use Scrum And DevOps. I am interested to discuss this topic because it's quite common I get a question from someone in the agile community, "Should I use Scrum or DevOps?".

I would like to discuss Scrum and XP because I often get a question "When should I use Scrum or XP?" from people in the community.

There is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review.

One of the most common critiques about Scrum that I've heard from smart software engineers are "Scrum does not care about technical practices, Scrum is for wimps". I've also heard managers down the hallway say that "Scrum is for wreckless developers because its main concern is only about fast delivery".

There are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code, but modern source control systems are about way more than code.

The PSD training teaches the whole Scrum Team on how to do real Scrum. They work in Sprints, create Done software and use the appropriate tools and practices for it. It is a unique experience on how really good Scrum feels like.

As the saying goes, it’s not about the destination, it’s about the journey. The same could be said about DevOps and its implementation in an organization. Yes, the result is magic since it aims to deliver daily business value, but the journey is even more interesting. This journey is full of organizational, technological, but especially human discoveries.

Comme dit le dicton ce n'est pas la destination, mais la route qui compte. On pourrait dire la même chose pour DevOps et de son implantation dans une organisation.

Pour avoir un aperçu de la perception et compréhension des personnes de quelque chose, il suffit de regarder les réseaux sociaux.

To get an insight into people's perception and understanding of something, just look at the social networks.

Recently discussing design and programming with an external programmer, he explained me his approach of defensive programming. But before going in detail of his explanations, Wikipedia help us to define the defensive programming: