Agility and Project Leadership

It seems lately that I'm finding quite a few articles on the web where people are moving away from Scrum to Kanban.  As this post from the blog "Journey of Continuous Improvement" indicates:

Some people will argue that we weren’t doing Scrum right so no wonder we had problems. But this is the crux of my problem with it – so much effort goes to doing scrum instead of channelling that focus to building better software, faster.  For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus.  I think there is a misconception that Kanban is a process and directly comparable to scrum. I don’t see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.

The section about liberating from a "prescribed process" was interesting to me as many think Scrum is about being flexible, but in reality if you're doing it "right" you have to come up with good story point estimates and plan your Sprints to ensure you deliver working software at the end of a Sprint.  Estimating is notoriously hard and even more so if you're doing cutting edge software.

In this post from "Blue Sky on Mars", it outlines a similar sentiment:

With Scrum, this sort of planning is built-in to the process. You estimate all of the stories in question, add them up and divide by the velocity to find out how many sprints it’ll take. Or, compute how many sprints you have and then you can choose which stories fit best into the time you have.

I happened to run into this discussion thread and the most interesting discussion was on the topic of just “enough up-front thinking” which this poster David Chelimsky, responds:

In regards to enough up-front thinking, there are a series of scopes to which it applies. When you’re in a release planning meeting you want to do enough up-front thinking to be able to start working on the release with confidence. This will likely include considerations like business strategy, marketplace, etc.

In an iteration planning meeting, the scope is narrower. The goal is still to do enough up-front thinking to start working on the iteration with confidence, but the considerations tend to more about the functional details of specific features that we’ve already selected in the release planning meeting. Perhaps you don’t do separate iteration and release planning meetings, and that’s fine, as long as you recognize that even in the context of a single meeting, the concerns for release planning are wider than the concerns of iteration planning.

Within an iteration the scope is narrower yet. You still want to do enough up front thinking, and perhaps you’ve recognized some design challenges that are presented by the features slated for the current iteration. In that case you call a design meeting with your peers. The goal here is stay within the scope of what you’re doing this iteration.

Then, when you get down to the minute to minute practice of doing TDD, the scope is even narrower. The focus is on objects and how they respond to events in given contexts.

At each level, we’re informed by what we know from the wider scopes, and we can’t help but consider the things we know.  We’re human, after all.  The trick is to avoid the temptation of considering the things we don’t know or are not relevant to the task at hand.

I like this idea as it outlines a form of “mental agility” that forms the basis of acting on information that you obtain “just in time” to be able to get work done.  But as the post outlines, it is still driven by the overall goals of the project and the key is to eliminate the fluff while focusing on the meat.  As I’ve critiques in the last couple posts, Agile is too focused on processes and not enough on the thinking and most importantly, the behaviors you need to adopt in order to have true agility.

Look forward to thinking “just enough” about this and posting more about it!

(NOTE: The post below is not really my personal view, more of a sentiment I'm seeing amongst those practicing Scrum, though I agree much with it.)

I really loved the idea of Scrum, really I did!  But I’m starting to realize that in reality, what was supposed to release me from the shackles of the tyranny of my Gantt chart cum waterfall ways is the fact that I’m now feeling the very same burden and overhead for which I wished to escape!

The fact is that Scrum ass-u-me’s that we are good at estimating.  In fact very good, because only then could you finish a working deliverable at the end of each Sprint.  The problem was that we’re not, yet the irony is that by breaking things down into Sprint iterations that were badly estimated, we ended up jerry rigging the estimation for the next Sprint which cause Sprint after Sprint to miss their deliverables.  Rather than get frustrated over a prolonged period of time after a traditional planning process, we would get bursts of frustrations that started making us exhausted.

On exhaustion, while it initially seemed a great idea to have daily stand-up meetings, Sprint planning meetings and all that good stuff, like anything else people show up and are enthusiastic at first, but then as time moves on and the bottlenecks start to occur as described above, you as ScrumMaster will become quite prickly and everyone working around you demoralized or bored.

And for all you “Certified Scrum Coaches”, don’t tell me that “we’re just doing it wrong” as that’s starting to sound trite.  I harbor no grudge against the Scrum framework, but like all good things it must come to an end and someone (maybe me!) will come up with a new twist to an old trick and get us all moving and excited again (Kanban anyone?).

Scrum, it's not you, it's me and hope we can still be friends.

I ran into this article by Andy Hunt on the Pragmatic Bookshelf site, which is one of the well know publishers of Agile software development books.  I particular liked the section with a quote from a software architect during an Agile workshop:

“The theater I did in college has helped me more in my programming career than half of my engineering courses.”—Grant Gainey, Senior Architect Developer

The article goes on to discuss how the improvisational skills learned in Theater are more in line with the kind of agility “Agile” is purportedly advocating.

The bigger issue that was revealed to me is something I have been thinking of for quite some time in that the field of project management, both traditional and Agile and everything in between has suffered from the tyranny of left brain thinking.

This is not surprising since the majority of people who have entered the field of project management are from construction, engineering and IT.  So naturally the focus is still on process and analysis and nothing really much on what makes us do what we do.  I know some of you Agile evangelist will argue that its focus is on people over processes, but I don’t buy that because none of the Agile methods go deeply into the humanistic aspects of why people do what they do and how they do it.

In any event, I have to admit that I have lost interest in the Agile movement and in fact am getting quite bored of it.  That’s not so say that “being agile” is not important!  In fact, I think Agile is not agile enough.

What’s needed is a broader perspective and one where we can learn from other fields.  I’m finding that the field of behavioral economics provides a lot of empirical data that supports inferences on team motivation and dynamics and  the quote above, and I may be biased since my educational background was in philosophy and comparative literature, highlights that we could definitely learn from the arts and humanities.

My writings going forward will focus on this idea of agility that will make Agile more, hmm agile.