Collection of Original Articles
The articles presented here provide an in-depth exploration of Agile approaches and tools. They also serve as supporting material for the training courses I deliver. I hope you enjoy reading them.

IMPLICATIONS OF AI FOR PRODUCT MANAGERS
After the introduction of AI, most Product Managers are buried under an avalanche of new features waiting to be validated with users and released later. Some companies address this problem by simply no longer testing new features with users and

VELOCITY IS NOT A TEAM COMPETITION
The Velocity metric has a rather poor reputation due to frequent anti-patterns associated with it. In this article, I describe the role of the Velocity metric in a multi-team environment, what it is not for, and how we can use

AI INTEGRATOR AS A TRANSITIONAL STRATEGIC ROLE
Continuing in the spirit of the previous article. AI has redistributed workloads within the development process. These have shifted from programming toward prototype verification. Companies are slowly adapting to this, but the process has proven to be much more complex

AI PRODUCTIVITY GAP: AN ADDITIONAL CHALLENGE FOR SCALED AGILE ENVIRONMENTS
In a previous article, I described how, as a result of AI adoption, the bottleneck in software development has shifted from waiting for user story implementation (programming, code review) to user testing. With the use of increasingly advanced AI tools,

AGILE WORKS FOR US. BUT STILL…
INTRODUCTION This article is inspired by my own observations, a somewhat prophetic warning in the book The Lean Startup, and the confusion that artificial intelligence has brought to the development cycle. The article has two messages that are mutually independent

TUCKMAN’S TEAM DEVELOPMENT MODEL
Development teams are often expected to be effective “right out of the box.” Management: “After all, our they are all experts (and well-paid ones at that)!” It is often overlooked that development teams do not achieve working synergy overnight; rather,

WHY DO ALL DEVELOPMENT CYCLES LOOK SO SIMILAR
INTRODUCTION The Agile world loves creating new models, diagrams, and cycles. Scrum has its own cycle of events, Lean Startup talks about Build-Measure-Learn, Lean UX uses Think-Make-Check, and Deming introduced PDSA. At first glance, these appear to be different approaches

SM AND PO COUNTERPARTS IN OTHER FRAMEWORKS
Development teams use a variety of Agile and Lean approaches. These are largely based on common foundations. The most important are: incremental development, allowing for frequent feedback and creating the organisational conditions to activate the creative potential. There are, of

PM² – The European Commission’s project approach
Large corporate systems often tend to standardise project approaches. Sometimes this is justified and simplifies processes, but sometimes it is driven by mistrust and a desire for control. Outcomes depends on circumstances such as diversification of product and service portfolio,

DAILY STANDUP AND 3 QUESTIONS
Many development teams do not practice Daily Standup or Daily Scrum . Rejection is usually due to a misunderstanding of the event’s function and incorrect implementations. The result is the belief that Daily Scrum is a waste of time –

SCRUM PATTERNS – THE SPIRIT OF SCRUM
“Scrum is a light-weight process framework which is simple to understand but difficult to master.” The above statement is a well-established mantra of Agile practitioners, consultants and evangelists. It is true, but it is of no value in itself. Scrum

WHAT IS SCRUMBAN
Team members dissatisfied with Scrum sometimes say that they will “just switch to Scrumban“, because in Scrumban, you don’t need to plan. This is a common belief. Scrumban will somehow keep all the benefits of Scrum, but it will save

ADAPTIVE LEADERSHIP THROUGH TEAM DEVELOPMENT
In a recent article, we learned about Tuckman’s model of team development. The article focused on the model itself and the characteristics of team dynamics in its specific phases. This time we will build on the topic by looking at

CFD INTERPRETATIONS
The Cumulative Flow Diagram (CFD) is used extensively in most Agile frameworks. It was popularised by Kanban, where “Visualise the flow” is one of the six leading practices. CFD shows the amount of work that is currently in a particular

AGILE CONTRACTS
This article is intended as a reference in the search for the most appropriate type of Agile contract, given the dynamics between the client and the contractor. Content Challenges of Agile contracts In the case of development initiatives, the constant

BURNUP vs. BURNDOWN CHART
Burnup and burndown charts are visual tools for displaying completed work and work remaining in the Product Backlog. Some teams use both. In my opinion, this is unnecessary, as the burndown chart is less flexible and can be fully replaced

DORA Report 2025 – Adjustments to the Software Development Cycle for AI
In this article, I summarize the findings of an extensive (142-page) study titled DORA State of AI-assisted Software Development Report. It was conducted on a sample of more than 5,000 developers. Due to the novelty of the subject, this year’s

TRAINING, COACHING, MENTORING THROUGH ITERATION – PART 2 – TOOLS
INTRODUCTION In the previous part of the article, we explored the focus and intensity of coaching depending on the iteration phase and the role played by the Scrum Master in this process. I also discussed the apparent difference between a

TRAINING, COACHING, MENTORING THROUGH ITERATION – PART 1
In the previous two articles, we learned about Tuckman’s team development model and later, how a leader adapts their team guidance approach based on the achieved development stage. In this post, we will briefly look at how the Scrum Master

COLLOCATION AND OSMOTIC COMMUNICATION
Agile approaches support the thesis that face-to-face communication is the most effective way of transferring information. The effectiveness of different media is shown in the table below. Collocation Constant (and effective) communication is advocated by the first value of the

EVOLUTION OF DEFINITION OF DONE
What is Definition of Done? Definition of Done (DoD) is an agreed list of activities that the team performs during an iteration for each item taken from the Product Backlog for development. DoD is a quality measure that every functionality
