In this post, we’ll discuss different ways of planning. When I talk about planning, I mean deciding what to do or what objective to achieve.

As such, estimation and other timeline-related activities will be out of scope here ;-).

When do we plan?

In Waterfall, we start with a planning phase: deciding all the work to be done, up front. It looks a little something like this:

In Scrum, we have iterations (sprints) which have a Sprint Planning meeting at the start of each. So our picture looks a little bit like this:

In kanban, teams can do as they wish. Often this results in doing planning when it is needed (eg once all the “in progress” work is done) so it is more sporadic:

Overall, the proportion of time spent on planning might be about the same: Agile evangelists would say that because of the pivoting this repeated planning allows, the value they deliver overall over the same time period will be much higher. (I agree with them!)

One of the things I find interesting as thought experiments is applying these concepts to life. As a child, many of us have some dream of what we would like to do. As time progresses, perhaps this dream changes: in some sense perhaps this is a bit like a failed waterfall project… I hope though that we can instead see it as more like kanban planning: if you wanted to be married by the time you were 25, but didn’t meet the right person, it doesn’t feel fair to call that a “failure”.

Who does Planning?

In Waterfall, it is often a Project Manager, with the help of a few trusted Business Analysts. Perhaps the rest of the team have not even been assembled at this point.

In Scrum, the Product Owner sets the direction (and if they are a “good” team the rest of the team will be very involved too). Often the developers are involved in estimation, and in a good team they will also be involved in creating some of the stories, with the Product Owner having an overall accountability for it.

In Kanban, it can be anyone, though it is common to have someone fulfilling a kind of Product Owner role, to engage with stakeholders and understand what work will add value and be the best return on investment. Importantly, it is often those doing the work who will trigger the planning sessions (eg when they have no more work to do).

Psychology of Planning

It seems clear from Self-determination theory that those doing the work being involved in planning will lead to more intrinsically motivated workers, who actually want to work. This is particularly true in creative work. If you are interested, I would really encourage you to read up on Self-determination theory and see how you can apply it to your team to help them be more fired-up about their work.

 

 

I thought I’d share with you some of my favourite tools and resources I use as an agile coach. I find all these topics to be essential for being a coach.

Retrospectives

I love helping teams do retros, so they can reflect and improve the ways they work. But better is getting them to lead their own retros. To help, I often share my favourite retrospective idea sites:

• Retr-o-mat
• Retrospective wiki

Scrum

I try to use only the scrum guide here. Too often I hear people say things like “We must have User Stories because we are doing Scrum”, which is not only untrue by the definition of Scrum, but also may stop the team from doing something smarter (though I do like user stories in general, to ensure the team have a value focus).

Kanban

David Anderson’s “blue book Kanban” suggests a fairly rigid approach, which is worth considering and learning from. I would argue it runs counter to the philosophy of empowerment evangelised by the Agile movement.

I like the “primary sources” for this, such as this from Toyota.

Agile

Clearly the Agile Manifesto is the source of truth on this.

Lean

I can’t help but recommend Mateusz Gajdzik’s simulator tool. Don Reinertsen’s book Principles of Product Development: Flow is also of interest here.

Psychology

I tend to use coursera to expand my horizons in Psychology (as well as in other areas such as gamification or mathematical techniques), as books get out of date very quickly. I very much enjoyed “foundational neuroscience for perception and action”, “social psychology” and “inspiring leadership through emotional intelligence”. These change all the time and many of the above are no longer available, so have a browse yourself.

I also love the following videos (which I am sure to have mentioned before):

• Dan Pink on motivation
• Nudge (and I like many other RSA videos too)

Management and Leadership

The distinction between management and leadership is critical. For some “agile appropriate” tools, I like Jurgen Appelo’s work, particularly Management 3.0 #Workout.

For leadership theory, I’d recommend reading some summaries to broaden your perspective, such as this.

Coaching skills

Lyssa Atkins’ book Coaching Agile Teams I found a helpful and well-thought-through guide. Overall though, I’d suggest that in coaching there is no substitute for practice. Inspect and adapt.

I’d love to hear about your favourite resources, and any feedback or suggestions for better resources.

According to wikipedia…

Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. I’d like to talk to you about something more physical instead:

First, someone planted a hedge. Then the bushes grew into trees, weren’t good as a hedge any more, but they left anyway… and built a wall too. After some time, they wanted to keep sheep in, so added some barbed wire to stop them climbing over the wall. And now we have a (rather amusing looking) bodge: it would have been better to rip it all down and have a proper fence instead. I think you’ll agree that (whilst quite attractive with the greenery) it is a bit of a mess. Let’s translate this now into software development.

How do you know if you have technical debt?

Almost by definition:

• New features are slow
• Bug fixes are slow
• Developers say the code is crap and messy
• There is extensive documentation separate from the code itself
• New starters take a long time getting up to speed

What can I do about technical debt?

Like other Agile Coaches, I’ve seen lots of ways teams can get better at this:

• Realise as a team that there is a problem
• Allow developers the time they want to get the code good, as part of each story
• Add “technical debt” stories / work parcels
• Write (and live by) coding standards
• Write (and live by) definitions of done
• Do code reviews
• Consider trying pair programming

There are lots of other things you can do too. I’d recommend avoiding a big rewrite and do improvement incrementally if you can, as this increases your feedback. Use your noggin: If you’re refactoring code, do the most-often-changed bits first. And if your stakeholders are hesitant to invest in this, measure your Lead Time and show them how it gets better on the parts of code you’ve improved.

Any comments on this topic would be great! Do you have other ideas for removing technical debt?

I spent last week with a friend, trying to help him spring clean his house. He’s been struggling with feeling overwhelmed with all the complexities of life, and wanted some external help.

“Being lean” isn’t reading a book. “Being lean” is “being lean”. [1]

Key principles to articulate:

• Limit work in progress – e.g. do one thing at a time
• Make it visual – e.g. through a physical board and colourful post-its
• Keep inventory small – e.g. don’t waste time writing out the 50 things you wish were doing already, just write down the first 5 and crack on
• Sustainability is important – both in terms of pace and what happens after you (the trainer) are gone

You’ll notice the above are all “for example” rather than “this is exactly how you must do it.” As a coach, and as a mathematician,  I don’t care how you do it, I care that it is smart. And the above principles are either psychologically or mathematically sensible. This is also why the role of Scrum Master does not make sense, but Agile Coach perhaps does.

Cue Kanban board!

Especially with novices, this doesn’t need to take very long. As you can see, the above has been assembled (by the trainee) using a cereal box. It is very important the trainee does it themselves, so they feel ownership.

Contrary to popular belief, smaller is better. Small tasks make it feel more sustainable, and help give more endorphins as you move to “Done” more frequently. Just like a production line, which is where Kanban was famously popularised. [2]

Supporting others in their lean journey is about giving them tools, not doing things for them. If your friend wants their house clean, it might help in the short term to clean their house for them: but it will just get dirty again. The essence of this is something like “Give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime”, and it extends further to “Why are you eating fish?” and “Have you thought about farming?”

It is much smarter to give them the ability and motivation to clean it themselves, and techniques and motivation to keep it up once it is in a reasonable state. Better still is to give them the broader desire and ability to reflect more fully, to understand why this matters to them and how it helps them on a deep level (psychologically, spiritually, philosophically, e.t.c.) Or maybe it doesn’t and they shouldn’t be prioritising doing it.

Motivation is key. Without it, there would be nothing done. As a coach, your role is about inspiring more than anything else. If you can build a sustainable flame in someone, they can easily google the rest.

 

[1] https://xkcd.com/703/

[2] http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/just-in-time.html