Teams, Coaching & Facilitation
Three Hidden Problems That can Ruin Your Agile Retrospectives
Retrospectives are an essential part of any organization running agile software development. I donât care if youâre running scrum, kanban, scrumban, it doesnât matter. Reflecting on how you are doing and working to get better is essential to team success throughout and morale. And when teams donât run retrospectives, the reason is rarely about tools, or workflow or anything like that. Itâs time.
An Agile Approach to Budgeting for Uncertain Times
2020 has been particularly chaotic, but letâs face it, even in typical times most planning and budgeting processes are frustrating. They start five or six months early with promises of visionary transformations that quickly give way to tedious templates, endless financial forecasts, haggling over targets, and battling for resources.
Tips & Tricks
How Enterprises Misinterpret Agile Principles and Rush to Do Too Much
When you ask for a definition of agile, chances are you'll hear about speed, efficiency, and productivity. It's fair to expect all those things from an agile system. However, there's a little-known agile principle that holds the real key to achieving all of that. It goes like this: "Simplicity -- maximizing the amount of work not done -- is essential."
The Latest from Retrium
Webinar: Blaming and Naming: Recognizing and Avoiding Retrospective Anti-Patterns
On September 10 at 8 am EST, join author and experienced Retrospectives Facilitator, Aino Vonge Corry Ph.D., as she shares her insights the webinar, Blaming and Naming: Recognizing and Avoiding Retrospective Antipatterns, co-presented by Agile Alliance and Retrium. In this webinar co-presented with the Agile Alliance, Aino will introduce common antipatterns that undermine the effectiveness of retrospectives and share best practices to overcome each of them, as discussed in her upcoming book, Retrospectives Antipatterns.
â
Technical Agility
The Wraparound Anti-Pattern (and How to Fix It)
Experienced Agilists will recognize this anti-pattern immediately. It will look something like this:
Teams will make a very ambitious plan either quite close to or even exceeding capacity because work had not been completed last iteration. Teams will not manage risk or create contingency for unexpected demand or other interruptions due to delivery pressure. Teams will execute an iteration and not complete their committed stories to varying levels of âdoneness.â Teams will push work to the next iteration and go back to step one.
Agile Outside of IT
Agile and Architecture: Friend, Not Foe
We can refine our question to whether doing architecture is compatible with agile development. Sometimes, teams get hung up on whether there are people or teams with the title âarchitectâ but for me thatâs not the key point. People can call themselves whatever they like.