A team I am working with is in the storming stage of its development.
Finally.
It’s been some time that they have been forming, carefully learning each other, sometimes from afar. Each person was doing their own stuff, limiting their interaction to consultations. Every person to their own.
When we build the team’s board for the first time there’s many times the question of how to represent work in progress, how to show what’s going on between “Ready/Committed” (The backlog of the sprint, items ready to be developed) and “Done”.
There are usually two main options.
Organizations reorg all the time. And again. Why do they do that? Setting cynicism aside, organizations reorg to adapt to new realities, to new demands. A team of 5 people that grew to 20 people needs to split to smaller teams. A business group dealing with a fast-growing market needs to come up with a new strategy to cope with the demand. A startup of 20 people will need a different structure than that of a company of 100 people. As business demands change there is a need to adapt the organization’s structure.
Reorg is an expensive venture, yet organizations do it again and again. Because they have to do it – they have no choice.
When I was a kid cars didn’t have seat belts in the back seat. We used to fly to and fro all over whenever the
The Email Inbox – The real Personal Kanban frontier
I’ve been struggling for years with visualizing my personal work using Kanban.
Using a physical board isn’t that practical since a lot of the time I actually do my work I’m not at my office.
I then tried Kanban tools such as LeanKit, Trello (and even AgileZen…). This worked pretty well for a while, but I kept falling out of it. Something was missing.
TL;DR – Looking for SAFe exam questions? Sorry, move along, nothing for you here… If otoh you’re looking for some tips on how to properly study for the exam that seems to have worked for dozens of my students for the SPC exam and other SAFe exams, hang around….
I’ve recently been teaching quite a bit of Implementing SAFe classes. Students are always interested in some tips and tricks on how to prepare for the SPC certification exam, especially since it’s a non-trivial exam even if you attend a class with trainers that know what they’re doing and if you listen and participate throughout. The vast majority of my students pass the exam, but it doesn’t hurt to know how to study.
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 …)
Request for additional information and prices