Co-Creating and teaching the new Scrum.org Professional Scrum with Kanban class has given me an opportunity to get back to geeking out on WIP limits, flow metrics and all things Kanban. And it’s been fun!
It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban for Scrum Teams guide and the accompanying Professional Scrum with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve (Porter) and then working on getting it to market in a professional way (how else? ) with the Scrum.org staff has been a great experience and a major focus area for me in the last couple of months.
As you might imagine, together with the interest come some questions about some choices we made in the design of the guide and the class. Several are emerging as the frequently asked ones. I wanted to tackle a couple of those in this post.
Where are some of the core Kanban practices?
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
I’d like to share with you some tips and tricks of setting a scrum board I usually share with my clients. The bottom line is that too many tools have too many features that support old ways of thinking. Let’s look at the various items one by one
A common phenomenon happening in organizations implementing scrum is that something is missing – the big picture. People are saying “We used to have High-Level Designs – where are they?”, “We used to have an architecture before developing – where is it?”. The answer will usually be that as we are working with small batches we need to focus on what’s immediately coming up and so other things are getting neglected.
But this is a confusion. Nothing should be neglected. For sure we cannot neglect long-term thinking and planning.
This ISN’T Agile Marketing
First, a couple of clarifications and myth-busting. Agile Marketing isn’t reactive marketing. Agile Marketing isn’t about how you react in a Marketing/PR crisis (ask United about those) or real-time opportunity (you can ask Oreo about those). I don’t mean that you can not/shouldn’t deal with those when you’re doing Agile Marketing, but it isn’t what Agile Marketing is about.
Agile Marketing also isn’t “We just get things done without any real process.” Being super-responsive and saying “yes we can” all the time isn’t Agile Marketing. (Especially if it means unsustainable pace).
Finally, Agile Marketing also isn’t Scrum, Daily Scrums/Standups, Sprints, Scrum Masters, Kanban Boards. It
Over the years we at AgileSparks have been leading the charge when it comes to creating mashups and hybrids of approaches such as Scrum, Kanban, SAFe, LeSS, and whatever. Mashups and hybrids can be very attractive as they can be an excuse for taking what you like from each approach and leaving behind the hard stuff. In mashing up approaches you need to make sure whatever set of practices you end up with is cohesive and effective. Coming up with the smallest set of practices that is still cohesive and comprehensive and brings in the best of the Scrum iterative world and the Kanban flow-oriented world is a result of years of work in the trenches.
I recently started working with Steve Porter, Dave West, and others at Scrum.org as well as Daniel Vacanti of Actionable Agile (And a long-time friend and AgileSparks partner) on bridging the Scrum and Kanban worlds. We believe the time is right to put behind the arguments around which approach is better and help both Kanban and Scrum practitioners realize that actually they are stronger together.
Sometimes it is right there before us and all we need to do is to reach out and take it. Improvement opportunities are there – all we need to do is learn how to identify them and invest the minimal time to turn the opportunity into something real.
A good indication of an improvement opportunity hanging around is when something really good or really bad happens.
For example, I am working with a client where seven development teams are struggling for some time to better work together. One of the problems we were having was that features didn’t complete – didn’t move to Done. This week we had a deadline and the teams worked very hard and managed to get the important things done. They worked hard but you saw the spark in their eyes – They were very happy and proud about it.
At the beginning of a Scrum implementation y, you usually finds two main types of team behaviors. Those who embrace the scrum events (Planning, daily, etc.) and try to better understand them to represent one type. There are many issues and many required adjustments and the team is working on them with the coach.
Other teams view Scrum events as a total waste of time. They do them reluctantly and don’t see any value in it. What do you do? We’ve had several such cases and we wanted to better understand what’s going on there. After a deeper look into the dynamics of these teams, we reached some conclusions that let us sleep better at night.
Request for additional information and prices