OK, so you finally made it to the REAL advice.  Good for you!

While the advice given for the ‘problems’ named throughout the rest of this site really will work, those aren’t (usually) the REAL problems.  The real problems are almost always going to be cultural and/or organizational.  Instead of reiterating all of the problems mentioned throughout this site, I’ll group a whole lot of them together at once.

Agility comes from within. You just need to let it out.

On Leadership

There’s a huge misunderstanding, even at higher levels in large organizations where you wouldn’t expect this, that the terms Leader and Manager are synonymous.  Well, I’ve got news for everyone in that boat – THEY AREN’T!

Leaders set examples of behavior, attitude, perception, and service.  Managers cope and/or direct (it’s pretty much in the definition of ‘manage’).  I don’t want to downplay what Managers do.  They serve a purpose, and in some organizations that purpose is still valid and valuable.  In truly Agile organizations, Managers really aren’t needed, and they tend to cause more negative stress and aggravation, versus support and efficiency (which is what I think is their true intended purpose).

Personal experience (don’t beat me up over this, I did state it was ‘personal’) leads me to believe that there is a very large population of Managers who are very focused on personal gain or recognition.  And this is what will help me make my defining advice about the difference between Leadership and Management, or Leaders and Managers (obviously I’m advising on the side of Leadership).

Don’t seek recognition for doing the job you were hired to do – even if it’s been done well.  You were hired to fulfill a certain need that the company had.  You are obligated to do that job.  If you are not always seeking to do your best, you are committing a certain kind of fraud.  Rather, seek recognition for those you lead, for the goals they’ve met and the innovative ideas that they’ve brought to life in your product(s).  True Leaders know that success is not tied up in the things that they do or say.  It’s attributable to those they lead.

The company, as a whole, will benefit from Leaders like you.  You bring out the best in those you lead.  You set the example day-in and day-out.  You have clearly defined values and principles, and you never waver.  You lift up those you lead, rather than standing on their shoulders.  You provide an environment of trust, autonomy, mastery and purpose that compels people to seek your approval.

On Estimations / Estimating

If you think you need estimates, your box is too big.  Make box smaller.    – Ron Jeffries and Chet Hendrickson AATC 2017

On Planning and Plans

If you complain that Sprint Planning isn’t working, because you have the same discussions as you previously had in Refinement, I bet you also complain that you get to work late because you don’t have a nice enough car.

On Communication

On Teams, Groups, Departments, etc.

The importance of small, cohesive, collaborative teams is pervasive throughout all non-traditional framework models.  Currently, for Scrum Development Teams, ‘small team’ means 6 +/-3 (3 to 9) team members.  One of the most important reasons to keep the team small, is to give the team the potential for diverse ideas on how to solve problems, but limit it to few enough diverse ideas that could be discussed quickly.  Fewer than 3 team members, and you might not get enough diversity in ideas.  More than 9 team members, and you may have so many ideas that you may not get to hear from everyone.

A group of 5 people working in close proximity to one another, on related stuff, in short cycles is not a Scrum Team.

Scrum Teams are unique in that they are groups of people that are self-organizing, self-managed, have an emotional stake in each other, and a strong dedication to the product being developed.  This means arbitrarily adding or removing a single team member would have incredible repercussions on the product development process on the team.  Ultimately this often translates to a low-quality product delivered to the end customer (usually later than expected).

On Project vs Product Mindsets

Practicing Scrum with a Project Mindset vs. a Product Mindset is like playing Hockey with a Basketball.

On Change Management

There’s this Oreo Cookie in Change Management.  The top, the CIO or Senior Manager, who wants to, and is willing to change. We have the crunchy bottom that is begging for change. And then there’s this mushy middle that’s confused about if they are still part of the new cookie when it’s twisted apart.      -Chet Hendrickson

On Changing Processes

Many times, I find immature organizations (usually at the lowest team level) considering switching to Kanban, from Scrum.  As I’ve been through this many times, I can usually guess their responses when I question their consideration.  Sometimes it is because the team is too big, and Scrum dictates small teams.  Sometimes it’s because most Scrum Coaches will demand 100% co-location of Team Members, and Kanban doesn’t.  Sometimes it’s because Kanban isn’t fully understood, and is assumed to be a ‘Wild West’ of work management, where you can start work you don’t intend to finish (in the requester’s lifetime), you can take on a ton of work all-at-once, there are no timeboxes to live up to, there’s no need for reflection, and there are no metrics.

Let’s face it, that last one (the misunderstanding of what Kanban really is) is almost always why teams want to make the switch.  It’s a real pity too.  Because, the team is making a VERY impactful decision without doing the least amount of investigation into what Kanban is, what it delivers, and what a team’s commitment it will be to the new process.  The biggest pity, though, is that the teams rarely look inward at their own process to see if it’s even the right change to consider.

There’s always going to be opportunity cost related to any decision made.  But here, the opportunity cost is very high.  Usually higher than the gains that switching to a completely different process will deliver.  In following through with a blind transition from Scrum to Kanban, teams usually trade one set of artificially constructed impediments for another.

In my opinion, teams should be coached through any process change, and the decisions to make those changes.  When discussing process changes from Scrum to Kanban, consider the natural progression of solving problems.

1. When we are presented a completely new problem, we can react in many different ways.  Some are controlled and predictable, but the problem with problems we’ve never seen before is that they are rarely managed well by taking actions we’ve already defined.  No.  We start out addressing the chaos that immediately ensues after the problem presents itself.  More often than not, we address that chaos by adapting immediately to the setting and taking correction to stop the problem from causing more damage.
2. Once further damage has been mitigated, now we turn to measures to fix the root cause of the problem.  Rarely is the root cause very evident.  Often, we must investigate, experiment, measure the results of an experiment, and decide which experiment to try next.  We loop around and around on this until we have not only found the cause of the problem and fixed it.
3. We’re not done there.  Now we have to address all of the resulting damage that has occurred from the problem.  It’s possible that this can be concurrent with #2, but you would need a separate team to handle it, and there’s one little thing that prevents them from truly being concurrent…  Once we know what the real cause of the problem is, and how to correct it, we need a procedure to fix the damage.  We create one.  As we fix more and more of the damage, we get better at it and cut out the waste of unnecessary action and process overhead.  We get it down to a science and make it so simple that anyone in the company can do it.
4. Once anyone can follow a simple set of instructions to fix the damage of this problem, we document it and monitor when it happens.

These progressions, from #1 through #4 follow a path through the Cynefin sense-making framework.  Cynefin is a framework for understanding where you are (conceptually) with anything, and the possible direction you may go in the future.  It doesn’t tell you how to work or manage work.  It looks at the work you are doing, and how you are addressing it, and tells you where you are.

That being said (about Cynefin, and Kanban), let’s take a look at where Scrum and Kanban are in Cynefin.  In #1, we are in Chaos.  That’s not a comfortable place to be.  That’s not where Scrum or Kanban, or anything else I can think of right now, are.  It’s a no-man’s-land of shoving stoppers in a dam to keep the flood at bay for a few minutes.

#2 is where we find Scrum.  When we are experimenting and finding solutions, making things that work, and satisfying the people that want those things.

When we’ve reduced the complexity of creating and delivering this ‘things’ to our customers…  When it’s been made fairly easy to reproduce them, and the only instabilities are minute, we can focus on creating them, as well as reducing waste.  We’re at #3, and Kanban.  We are increasing quality, reducing waste, and simplifying what we do.

When we’ve simplified everything to the point where we can trust the least responsible among us, we’re at #4.  Guess where the term Best Practices came from.  Guess!  Yeah, that’s here too.  Best Practices means we’ve ironed out all the bugs we can reasonably spend time on, created the best quality ‘thing’ for the least cost and highest profit margin.  There are Standards written and measurements taken, and people are berated for every infraction against those standards.  (If you are wondering, this is traditional command & control.)

My advice has always been (and I don’t see it changing), if you are considering a process change…  Figure out where you are (Cynefin), and what you want from a process change.  Educate yourself and others on the new process – and I don’t mean read online articles!  Attend classes, read books, and visit places where this process actually works.  Interview change management experts with proven success in the new process.  Then pay a consultant a ton of money to help you limp through the change.  (That’s only partially a joke.)