Keynote Speakers The Mindful Manager Navigating Complexity means navigating uncertainty. Dealing with uncertainty requires emotional maturity and clarity of thought. Simon Bennett (English) https://youtu.be/nXS_oAcNJ-w Tribal
“Inspection does not improve the quality, nor guarantee quality. The inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.” – W. Edwards Deming.
A big number of bugs that are discovered in testing processes are easy to prevent. The fact that such bugs are discovered at the testing stage, which is usually at the end of the process, shows that the developers did not perform primary quality check of their work. This wastes the time of both testers and developers, reduces motivation and efficiency, and slows development. The costs go up significantly as a bug moves through traditional SDLC. For example, IBM estimates that if a bug costs $100 to fix in the Gathering Requirements phase, it would be $1,500 in the QA testing phase and $10,000 once in Production.
While we can’t expect to test everything and go our entire lives deploying a product that’s 100% error-free, we can make strides to safeguard software as best we can. Built-In Quality is a core principle of the Lean-Agile mindset. It helps avoid the cost of delays associated with the recall, rework, and defect fixing. The Built-In Quality philosophy applies Systems Thinking to optimize the system, ensuring a fast flow across the entire value stream, and makes quality everyone’s job. Built-In Quality practices ensure that each solution element, at every increment, meets appropriate quality standards throughout development.
One way to drive forward Built-In Quality is to adopt the Zero Bugs approach.
Without Zero Bugs approach, you typically have the overhead and increasing cost of fix, as well as a culture in which people are used to bugs being a standard part of their environment which only makes the backlog of bugs grow (the broken window theory).
Zero Bugs Approach means applying a policy where the team keeps a very low (optimally zero) threshold of open bugs. Once the threshold is reached, the team “Stops the line” and fixes the bug(s). Developers and Testers are pairing and therefore part of the bugs isn’t even reported in the bugs management tool and is fixed immediately. There is no Severity indication as a bug is a bug. Once you implement the Zero Bugs approach, you will no longer have to manage and prioritize a never ending backlog of bugs.
Progression bugs, which are related to new functionality, are fixed immediately as part of the Story Definition of Done. Regression bugs are negotiated with the Product Owner who decides whether to fix the issue or to obsolete it. If the fix doesn’t risk the iteration, the bug will be fixed immediately. If it might risk the iteration, then the PO prioritizes the bug vs. the team’s backlog, and the bug will be fixed at the latest as top priority of the next iteration.
The Zero Bugs approach is just one of many ways to install a Built-In Quality culture and to shift left the quality awareness.
AgileSparks offers a 1-day Built In Quality course for tech leads that covers how leading software companies are changing their approach to quality, in order to achieve speed and continuous delivery. This course pushes the boundaries of the quality mindset and challenges the thinking about quality ownership within the team.
* Boards | Trello Map your work, control your life: Personal Kanban Productivity 101: An Introduction to The Pomodoro Technique PopcornFlow: If change is hard,
Comment: We’re reposting here a classic article from the archives of Yuval’s personal blog.
What do Agile backlog items have to do with Dinosaurs?
I’ve been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)
Bringing values down to earth
Values and principles can often seem lofty and intangible so many agile practitioners prefer to focus on tools and practices. That’s understandable but unfortunate. Because values and principles have the potential to provide us with clarity and guidance that transcends what practices and frameworks can achieve. Ideally – part of your empiric inspection and adaptation process should explore whether you are living according to your values/principles. To achieve that you can try a value-based retrospective.
We are relentlessly expanding our tools set
We at AgileSparks help companies create effective, efficient and
When we talk about the benefits of working with small batches we talk about risk reduction, about improving flow, and getting quick feedback.
I call these reasons “scientific”.
I believe that the main reason for working in small batches is getting things done. The value of getting things done is mainly a moralistic one. It is good to get things done – it does good to your soul.
This leads us to the dark side of working in small batches – The Addiction.
The Kanban method is built around improving the flow of product development. It works very well when you work according to priority. It also works well when some items have schedule constraints. When many items have schedule constraints this becomes an issue.
The Motive
I was having a discussion with one of my clients and they raised the issue that what was going on wasn’t clear. Immediately I thought of setting up a Kanban board. However, when we started to do that it became clear that the main issue is how to commit to clients about deliveries.
Introduction to the Scaled Agile Marketing Series
More and more Marketing organizations realize they need to be faster, more flexible/responsive, and more collaborative to have a real impact on the business they’re supporting. More and more marketing leaders believe Agile Marketing is how to modernize their organization. Scaled Agile Marketing talks about applying Agile Marketing principles beyond one team and beyond the green fields of the unicorn internet company – in larger marketing organizations that face barriers like marketing to businesses rather than consumers and working not just in the online/digital realm but also the physical world.
In the previous article, I mapped out the essentials of applying SAFe™ (The Scaled Agile Framework) to a marketing context and ended with a cliffhanger. As you can guess from the title of this article, what I feel is missing from the list of essential SAFe elements is Flow and Kanban, which IS an important part of SAFe. In this article, I will focus on the key Flow/Kanban elements that are essential to succeeding with Agile Marketing at scale in my view. These elements don’t have to be implemented as part of SAFe by the way. Some organizations implement them on their own.
What do we mean when we say effective marketing flow
Request for additional information and prices