Continuous improvements helps us make the process and product better. It helps us improve our response time and product quality, and make our processes simpler. But how do we make time for these improvements? Whether the company is small or big, it’s hard to find time with regular frequency. There are so many things to do – so many fires burning. Here are 7 tips on how to squeeze in continuous improvements.
With improv, what you see is what you get. There is no script and no hiding. The feedback loop is short, and brutal. You see and hear what is emerging at the same time as the players. It is very transparent. Just like Agile. Improv players adapt and adjust the show based on feedback from the audience. Unity in improv begins with a self-forming group of people (a troupe). What can we learn from three key improv values to drive transparency, adaptability, and unity? Have a look, and you’ll find some real examples.
If the people feel unsafe in a retrospective, it will have serious impact on the effectiveness of the retrospective. But how do you even know if the people are feeling safe or not? You can ask for a safety score, i.e. how the people on the team are feeling about safety. What if the safety score is low? You shouldn’t ignore the low score. What do you do? Here are a few ideas.
Quite a few tools have been around to detect some level of the technical debt. Some help with code analysis or test coverage. Some claim to provide “absolute” information, like the violation of a coding standard, and other help detect bad code and design smells. Each situation has its own context and each team have their own view on what is acceptable. Here are a few tools that can help you assess and manage technical debt.
The test-first approach, test driven development (TDD), gets a lot of attention. But some people doubt that it gives them the visibility and coverage they need for the most important business cases. Sounds like a valid argument. Behaviour driven development, BDD, aims to solve this issue. It helps us focus on the behaviour of the system rather than its technical specifications. But how do we get started? Here’s a quick description of BDD and a short example to help you understand how it works.
Nexus is one way to scale Scrum. But how to set one up? Do we know when does it work best? What conditions need to exist to make it a success? What are some characteristics of a Nexus implementation? Here are 6 short tips to get you going.
Should you use the burndown chart, or the burnup chart? People have different opinions. Some select a chart based on their specific scenario. Does it really matter which one do you use? The question we should ask is – what do these charts actually tell us, and what can we do as a result of that? What’s the real use of these charts?
Is it a good idea to take on a “stretch goal” each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team “hopes” to complete if the sprint goes well. Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity. Should you aim for a stretch goal? Mike Cohn provides his perspective on stretch goals.
LEAN
Kaizen: 7 Ideas for Continuous Improvement
Continuous improvements helps us make the process and product better. It helps us improve our response time and product quality, and make our processes simpler. But how do we make time for these improvements? Whether the company is small or big, it’s hard to find time with regular frequency. There are so many things to do – so many fires burning. Here are 7 tips on how to squeeze in continuous improvements.
kanbantool.com
AGILE
What Improv Can Teach Us About Agile
With improv, what you see is what you get. There is no script and no hiding. The feedback loop is short, and brutal. You see and hear what is emerging at the same time as the players. It is very transparent. Just like Agile. Improv players adapt and adjust the show based on feedback from the audience. Unity in improv begins with a self-forming group of people (a troupe). What can we learn from three key improv values to drive transparency, adaptability, and unity? Have a look, and you’ll find some real examples.
agileconnection.com
What If People Don’t Feel Safe In a Retrospective
If the people feel unsafe in a retrospective, it will have serious impact on the effectiveness of the retrospective. But how do you even know if the people are feeling safe or not? You can ask for a safety score, i.e. how the people on the team are feeling about safety. What if the safety score is low? You shouldn’t ignore the low score. What do you do? Here are a few ideas.
benlinders.com
Tools For Assessing Technical Debt?
Quite a few tools have been around to detect some level of the technical debt. Some help with code analysis or test coverage. Some claim to provide “absolute” information, like the violation of a coding standard, and other help detect bad code and design smells. Each situation has its own context and each team have their own view on what is acceptable. Here are a few tools that can help you assess and manage technical debt.
scrumexpert.com
Getting Started with BDD
The test-first approach, test driven development (TDD), gets a lot of attention. But some people doubt that it gives them the visibility and coverage they need for the most important business cases. Sounds like a valid argument. Behaviour driven development, BDD, aims to solve this issue. It helps us focus on the behaviour of the system rather than its technical specifications. But how do we get started? Here’s a quick description of BDD and a short example to help you understand how it works.
blogs.atlassian.com
Scaling Scrum – How to Start a Nexus?
Nexus is one way to scale Scrum. But how to set one up? Do we know when does it work best? What conditions need to exist to make it a success? What are some characteristics of a Nexus implementation? Here are 6 short tips to get you going.
blog.scrum.org
Real Value of Burndown or Burnup Charts?
Should you use the burndown chart, or the burnup chart? People have different opinions. Some select a chart based on their specific scenario. Does it really matter which one do you use? The question we should ask is – what do these charts actually tell us, and what can we do as a result of that? What’s the real use of these charts?
dzone.com
Should Teams Aim for Stretch Goals?
Is it a good idea to take on a “stretch goal” each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team “hopes” to complete if the sprint goes well. Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity. Should you aim for a stretch goal? Mike Cohn provides his perspective on stretch goals.
mountaingoatsoftware.com
Share this: