Agile Learning from the Pro's

[#1]

Over the past few years, I have had the pleasure of working with a very bright and amazing team. One of those teammates is @Carolyn McNicoll , who has taught me some important ideologies of Agile that I had missed in the past.

• Real Flow Metrics (actual data, not arbitrary numbers)
• Continuous Improvement

These two ideas are crucial in any circumstance. We need factual data to make informed decisions, rather than relying on arbitrary numbers. Once we have actual data, we can continuously improve our products and processes.

🏃 This makes me wonder: do we need sprints, or can we adopt a pro-Kanban approach to keep things moving? Many teams have aligned with Scrum and sprints to achieve success. Changing this approach today might cause interruptions in processes and lead to lost time due to changes in procedures or functions.

I don't have the answers to these questions. What I do know is that if we don't try, we won't know. Agile has helped me realize that we must experiment to see what works, because if we don't, we'll never know. This is why continuous improvement helps teams get better. We challenge the status quo.

[Frode Nilsen]

I think Kanban is a nice work form if doing Continuous Delivery. Scrum is useful to force a delivery at every Sprint end - deliver what is completed.

With Kanban it is to easy to wait for the last missing piece (forever).

[Carolyn McNicoll]

Thank you @Aaron Geister _Trundl_ !  We were the dynamic duo for sure!  Flow metrics work with both Kanban and Scrum, but what I've learned and experienced over time is that Scrum works best if the team has control over the work they do and don't have the constant interruptions of support, continual addition of work, or changes in priority after a sprint has begun.  Kanban works great if the team follows the pull system and controls WIP.  They need to understand how the system works best, and then follow the policies the team agreed to, so that nothing sits forever on a board while team members are pulling in other work.  Most teams I have worked with over the years started with Scrum because we were taught early on that having the container of the sprint and the accompanying events would help us get the work done.  But in reality, that wasn't the case.  In Scrum many teams carry over work to the next sprint, again and again.  The underlying problem that is a theme across the teams and companies I have worked with is that the company didn't reorganize for optimal ways of working.  They didn't take the time to form cross functional teams, so they end up with teams that have handoffs and dependencies, just like before they "adopted" agile methods.