I’m guessing most people are expecting me to talk about making a decision on whether to use Scrum or Kanban. But I don’t believe that’s the biggest decision to make. The first thing when starting Agile at the team is to ask “what’s in my way of creating and delivering value?”
Although Scrum proponents hail Scrum as a good way to figure this out there are other, faster methods available (mostly just look at your current situation and see where your blockages and large queues are – see Value Stream Impedance Scorecard for more).
Common challenges are:
- developers & testers don’t collaborate well together on stories
- people aren’t interacting well with each other
- the lack of cross-functional teams is causing delays
- work is not done in short cycles so feedback is hard to get
- teams are being overloaded with work
- teams don’t know how to write small stories
Clearly Scrum & Kanban both attempt to address this in their own way and it should be clear how each one addresses these. Your choice though is to learn a framework or method that helps you with these challenges or in your initial training work on them directly – and then adopt a Scrum/Kanban approach that best fits your situation.
Why You Must “Do” Agile Before “Being” Agile
I often hear that you can get people to do Scrum but it won’t last unless they learn to “be” Agile. I suggest Scrum often fails because teams never learned how to do Agile. Scrum is a framework, a potential path to Agile. Conflating these two has many companies adopt Agile by getting certified in Scrum and hiring a coach to help them fill it in with practices
The challenge with this is that teams were already busy with their work before their training and now they have even more to do because Scrum appears to be a set of practices & meetings. They haven’t learned the Agile “doing” yet.
You obviously can’t teach the doing of Agile in 2-3 days. Agile is a method of collaborating with the customer, defining small pieces of work to do, creating them & getting feedback to ensure you’re on the right course. Yes, a new way of being is needed, but it is easier to act your way into a new way of thinking than think your way into a new way of acting.
Getting started with Agile means to take a sustainable step of doing with just enough of a framework to keep it going and to encourage improvement. The focus should be on the doing. Working together effectively may create the being. But the doing alone will be an immediate improvement.
I’ve always been bothered by the dismissal of XP as just being “Scrum with tech practices.” But the differences between the two are much greater. First, while XP and Scrum both have related values, the practices of XP are mostly centered around sw development practices (such as paired programming), while Scrum is mostly about non-domain specific team practices. Second, XP includes Acceptance Test-Driven Development (ATDD). ATDD, which is a collaboration between the Product Owner, dev, and tester and which includes neither design nor coding and is therefore, not a technical practice. In other words, Continue reading “XP is not Scrum with tech practices & knowing why this is so is more important than ever before”
I tweeted the following
If you saw a new engineer designing a long suspension bridge without attending to the wind would you say “let him figure it out, we’re Agile and that means we trust people”? why is it different in software which is even more complex?
Continue reading “Expanding on a tweet”
From the moment Scrum became more popular than XP, the software dev community has been focusing on frameworks more than Lean-Agile principles. It’s not surprising this has happened. It’s a lot easier to understand a framework than the principles underneath them.
The challenge that occurs is when the framework becomes the goal. Continue reading “Frameworks, proxies and Lean-Agile Principles”
Culture is important but it’s a reflection of decision & reward policies in a company. To be able to change it you must change the way decisions are made and rewarded.
Here are three foundations of Lean are: Continue reading “Why a good tool may be more useful than a good framework”
Do we “do Agile” or do we “be Agile”?
Ultimately, Agile is a mindset. But how do we get there?
Consider these two alternatives: Continue reading “Do be do be do – Frank Sinatra on Agile”
I was asked if Scrum per the Scrum Guide was an instance of Kanban. The answer is no because of the differences in the mindset. Scrum (per SG) has immutable roles, artifacts, events, and rules. These guide you to actions that fit within them. Kanban has principles you look at to see what to do. There are other differences in the mindsets of Scrum and Kanban. Continue reading “Frameworks are just tools. Good ones are instances of Lean”
People often conflate Scrum with Agile. But Scrum is not the same as Agile. Agile is considered by many to be a set of values, principles and way of being. Scrum is a framework consisting of roles, rules, artifacts and events. It is designed for teams to add those practices needed in order to become Agile.
XP is quite different. Continue reading “The biggest difference between Scrum, XP and Kanban”
I founded Net Objectives almost 20 yrs ago. I have always loved solving problems and having a chance to earn a living by helping others solve problems has been a very wonderful opportunity for me. Continue reading “A personal goal of almost two decades is manifested today”