Software Project Management: Agile, Lean and Kanban

Hire the Best

by Pawel Brodzinski on May 15, 2013

I took a part in a panel discussion at GeeCON about presence of women in IT industry. One of my arguments on why we should hire more women sprung an interesting comment:

I can’t agree with ‘hire woman even if she is a worse candidate’

Pawel Wrzeszcz

In fact, I’d agree with such a statement. I would as I wasn’t proposing hiring worse candidates. What I was pointing out was that I would hire less skilled or less intelligent woman over man. Why? Simply because she would be a better candidate.

Now, you may be confused so let me point two things. A typical hiring process is about individual traits. How much a candidate knows, what skills or traits he or she possesses, etc. Then, once we hire them, we put them on a team where key things are how one acts as a part of the team and how they help the team to get better. A very different thing.

If something I need to make my team more effective is more empathy and a different cognitive style I’d do the right thing focusing on these characteristics (which, by the way, promotes women over men). What almost all hiring managers would do instead they’d hire the best possible coder (which typically promotes men over women). Was he the best candidate?

On some accounts, I guess…

Let me rephrase: was he the best candidate in that specific context?

Definitely not.

He might have been most skilled and most intelligent candidate, which doesn’t make him the best. Not even close.

If sport teams had the same hiring strategy as we do in IT industry they would be hiring only people for one position, possibly only stars. Can you imagine a football team (proper football, not American one) with 11 world class forwards?

Yes, this is a dream of many hiring managers in IT.

We forget that building software in vast majority of cases is a team sport, not an individual effort. And we don’t get points for having the most awesome person on the team but for what the whole team has achieved.

So my challenge here is to rethink what “the best candidate” really means. We should be thinking more in terms of improving our teams, which is was more than simply hiring the most skilled person at hand.

Hire the best still stands true, but we should first answer the question: the best for what?

Tagged as: great team, recruitment, team management

{ 11 comments }

What Makes Teams Better

by Pawel Brodzinski on May 13, 2013

I’ve heard these experience reports a number of times: when a woman joins a team the whole team dynamic changes. Usually there is sense of improvement in team performance too. Unfortunately, most teams I know couldn’t report measured improvement as they didn’t have reliable measures in place. Anyway, the experience is very consistent.

It is, unless we talk about a pure-male team that simply rejects any woman who joins. And does that a few time in a row. I know such teams too but I consider them dysfunctional.

Anyway, let’s put dysfunctional groups aside. My own experience is purely positive too. I mean anytime that a team gained a new female member it was an improvement. At least that’s how I felt.

Interestingly enough, it’s not about having a woman in a team. It’s about having as many of them as possible. The research done by Anita Woolley shows that the more females in a team the better collective intelligence of this team is.

At the same time, the same research shows that collective intelligence beats the crap out of individual intelligence. Even more so if our goal is finding solutions of complex problems. And I dare say that software development is exactly that – solving complex issues – so we should be focusing on collective intelligence, and not individual traits.

Collective intelligence was much more predictive in terms of succeeding in complex tasks than average individual intelligence or maximal individual intelligence

Anita Woolley

This changes my perception of recruitment. I was always saying that given two candidates who are on par I’d hire a woman, not a man. Taking only individual perspective into account, that’s just about right. However, when we think about teams the equation is different.

In this equation women beat men easily.

The big question is what are you going to do with this?

Personally, I know what experiment I’m going to run next. And yes, it has a lot to do with hiring. I wouldn’t use the word “parity” but it wouldn’t be improper either. We need (even) more women on bard.

I do want my teams to kick butts. How about you?

Tagged as: great team, recruitment, team management

{ 0 comments }

It’s the People, Not the System

by Pawel Brodzinski on April 25, 2013

When I first learned about the D. Edwards Deming’s idea that 95% of performance should be addressed to the system and only 5% to the people it seemed totally counter-intuitive to me. Not even the idea itself, but its consequences. I mean a simple thought that you can basically stop working individually with the people on their performance as it just doesn’t make any sense. The impact of suboptimal system improvements should be tenfold or better than the best possible people-related changes.

Then, after researching the subject a bit, I swayed to the other side. The examples shared by Deming or Eli Goldratt are undeniable. I can also find a lot of examples from my own experience how the system was impacting performance heavily. Not that I had the numbers, but it resonated well with me.

Now, finally, you know what I think? Both approaches are crap.

Yeah, I’ve just tried to piss of both: guys who strongly believe in Deming’s work and those who totally disagree with him with a single attempt.

What Deming Really Said

I guess this story started when I was looking for precise Deming’s quote on one occasion. It seems that the meaning people attach to his words wasn’t there initially. The original 95/5 thingy was not about performance literally but about variability in performance.

Let me use a sport analogy to explain that. Let’s take a basketball player. If he scores anything between 5 and 30 points a game, and neither of extremes is an extraordinarily good or an extraordinarily bad game for him (meaning: it happens on occasions) variability of his performance is high. As a comparison we can have another guy, a second-tier player, who regularly scores anything between 0 and 5 points. Variability of his performance is significantly lower, even though his average performance is significantly worse.

Now, it’s not a surprise that the system governs variability. I mean, the more repeatable the situation the less variability you can expect. If the team plays are consequently set to create situations for one player his performances will be sort of repeatable. He won’t be suddenly disappearing from the game. At the same the system also governs variability of performances of a role-player who joins the game only under special circumstances, e.g. when the team needs more three-pointers or maybe when one of important players is injured. Variability of performances of such a player will be significantly bigger.

Of course, to some point, the system also governs performance itself. Think what happens when the star sits on the bench throughout the whole game or when a guy who is typically a sub plays the whole game. It doesn’t mean, however, that you tell a third-tier player to substitute a team leader and expect them to score 30 points a game. It’s not going to happen in a consistent manner. (For basketball fans: yes, I know Jeremy Lin’s story, but that’s an exception.)

What Deming was talking about was basically that the system governance is responsible for creating a stable and repetitive environment so people performances are controllable. Again, it’s not about how exactly people perform, but how their performance varies from day to day.

In fact, the above statement is mostly an interpretation too. Deming was talking about the system being, or not being, in statistical control which isn’t exactly performance variability, but for the sake of this argument let’s leave it as it is and not complicate things even further.

Anyway, Deming Is Still Wrong

So far I made an attempt to convince you that: first, Deming was basically talking about performance variability and second, the impact of the system on performance itself, while existent, isn’t anywhere close to 95%.

However, we shouldn’t forget Deming’s background, which is a factory floor. In other words it’s a place where workers are supposed to produce same things in a repeatable manner. I could exploit the basketball analogy further pointing that every game, heck, every play is different, but I guess in software development we simply don’t need that analogy anymore. It’s enough to ask: how many times have you built exactly the same feature?

And for all three of you who accidentally had this chance: how many times have you built the feature second time in exactly the same way you did the first?

I bring this argument to show that in knowledge work, or sports, we naturally have significantly higher variability to deal with. And, unlike on a shop floor, that is good. What’s more, there is a different value attached to every single thing we develop. In fact, it’s even worse than that. Very often we don’t know exactly what value is attached to a work item we’re going to build.

This means that in such a situation we should use a very different statistic mechanism than Deming based on. We need to take into account both expected cost and expected payoff. The latter, naturally, isn’t taken into consideration on a shop floor as in this situation payoff for each part is well known. In knowledge work, on the other hand, payoff function is extremely important and never flat.

Coming back to the basketball analogy: if you wanted to bet which player is going to score 30+ points during the next game would you rather choose this reliable guy who averages 15.0 and who always scores double-figure but rarely, if ever, exceeds 20.0 or rather that crazy shooter who (surprise, surprise) averages 15.0 as well but, depending on a day, can score either nothing or 40+ points? Bravo! You’ve just chosen higher variability, which is totally against what Deming taught us.

This is because you’ve taken the payoff into account. In the former case any payoff is almost impossible as, because of low variability, it’s highly unlikely that the guy is going to score 30+ points. The other case is a different story though.

Now, especially when we think about product development we are in a betting business. We bet that this or that feature will bring a ton of new users or a truckload of money. We can’t ignore the payoff function. We can’t assume the payoff function is flat. In either case we’d be throwing the baby out with the bathwater.

By the way, if you want to dig deeper around this one I strongly recommend watching this Don Reinertsen’s session. Twice. Seriously.

Besides, Who Does Create the System?

I’m not done yet. I don’t challenge the idea that the system affects performance. I simply challenge the so-called 95/5 rule or, to be more precise, I challenge the way some people interpret the so-called 95/5 rule.

The question we should be asking is who (co-)creates the system. If we start with Deming he points shaping the system as a management responsibility. This is probably very true on a factory floor. We are not at a factory floor though.

Let’s stay for a moment within software development perspective and think what exactly an equivalent of a production line is.

Obviously, one part would be organizational culture. What are general ways things are done in the organization? Does the org use a lean / agile or rather a heavy-weight, formalized approach? How do your clients act? These general rules will be difficult to change.

However, when we consider a lower level it’s a different game. Let’s try to translate low-level manufacturing process to software development. Production line would likely be a sort of a process: analysis, coding, testing, deployment, etc. What’s interesting though is what is happening on each of these stations. How exactly the work is done? Who makes decisions how the work is done?

Take coding for example. Who decides whether unit tests are there or not? How many of them? What kind of tests? Who decides on a specific coding style? A manager? Um, no, not really. Most, or even every, of those decisions are made by a coder – a worker.

Now, the important question: do such decisions define the system which a developer operates in? Obviously! Just think what is going to be the outcome of work of a cowboy coder and what happens when a worker is an eXtreme Programming fan. These are different systems indeed.

The conclusion of this story is that in our world workers can influence the system heavily, thus completely change the Deming’s equation.

One might point that leaving people freedom and empowering them is still the part of the system design which is still the management job. I’d disagree. One thing is that adopting a technique or a practice isn’t comparable to moving the machines on a factory floor. I can perfectly start writing unit tests and it doesn’t instantly require everyone else to change the way they work.

Another thing is that it’s way easier to be a Grace Hopper follower in our industry. We can easily change the part of the system that goes through our desks, no matter whether we are empowered to do so or not. Eventually, if anyone notices (which isn’t that obvious by the way) we should have enough information to have meaningful discussion about the impact of how we’ve done our work.

All in all, in knowledge work there’s no clear line that separates the system from the people, thus the whole notion of addressing specific part of influence to one or the other is flawed.

It’s the People, Stupid!

The last piece of this puzzle is a story. Not that long ago I’ve joined the organization that is exceptional when compared to its surroundings. I’m far from saying that it is a perfect system already, but it’s definitely the most mature company that I’ve ever been working with.

In fact, it’s not only maturity of software development process we have but also this touchy-feely stuff we call the atmosphere. Not a dream job (yet) but pretty damn close to it when compared to everything else I’ve had a chance to experience.

Let’s try to translate this to a system definition then. It would be pretty effective. It would be delivering high-quality stuff. It would be a great environment to work at. It would help everyone to grow. How could one possibly not like it?

The only problem is that I’ve lost one third of technical stuff over the course of few months. The system? No, the people! Their individual needs, frustrations and dreams. Their unique contributions to what the system is, or has been.

Because at the end of the day, in our world, the system is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system. Change a single person and the whole system is different. Suddenly the rules of the game have changed and everyone else operates in a very different system. And the only thing that has changed is a single person has left.

Summary

My message in all that is that we should first understand our work, how it gets done and what kind of system we operate in. Because when we think about that it becomes obvious that there’s no simple way of separating the people from the system in knowledge work domain, especially when we’re talking about a small scale, e.g. dozens of people, not thousands of them.

At the same time I’m challenging the common notion of Deming’s rule because it’s nothing close to what Deming really said and it is simply flawed in our domain anyway.

At the end of the day you should understand the system (obviously!) but focus on the people too if you want a significant change.

Tagged as: deming, people, software business, systems thinking, team management

{ 11 comments }

Better Standups

by Pawel Brodzinski on April 20, 2013

I never fancied the standard standup schema. I mean I see value in sharing what the team did yesterday what the team is going to do today and what are the problems the team has.

Except these questions aren’t answered on a typical standup.

The first problem is that we answer what specific individuals have done and will do. In any but smallest teams it’s the wrong focus to have. I mean if there are two or three of us it’s very likely that such updates are meaningful. With a couple more people we gradually lose track, and eventually interest, in what exactly is happening in the rest of the team.

At the same we should be focusing on what is important for the team which may be something no one mentions because for example the biggest pain point is on a plate of someone who is absent or overwhelmed with other stuff that just doesn’t allow them to focus on the real problem.

The second problem is that very rarely someone really answers to anything by first two questions, namely the issues part is often omitted. I like tweaking the third question, for example to something that Liz Keogh proposes: ”what I would rather be doing.” It helps only a little bit though as it’s almost as easy to avoid this question as the original one.

The third problem is that with a bigger team a standup becomes just long and boring, and whenever a couple of people exchange a few sentences about any specific bit of work it shuts down almost all the rest of the team instantly.

A very typical change I introduce is a standup around a board, be it a task board, a Kanban board or what have you.

Then the discussion is mostly around important stuff that is happening right now and is visualized on the board. A typical pattern is: blockers first, expedite items second, stalled items third and then all the rest. I covered more elaborate version of this approach some time ago.

Such an approach means that not everyone, every single day speaks up. But whenever anyone has a problem or is just trying to solve an issue too long there’s definitely an update from them on the way.

Then, there’s always a call for action regarding important stuff, even if it just so happens that a default person for that item is unavailable.

This means that standups around a board encourage collective ownership of work.

In fact, there are way more call for action situations as this form of standup basically focuses on solving issues. This often means helping each other, taking over bits of work from others, etc. Whenever someone has hard time coping with all the stuff that waits for them they usually get an instant help.

This kind of a standup is also shorter than a classic one. After all you don’t mention all the boring stuff that just goes as planned – everyone can see that on the board, so what’s the point anyway?

It also is an occasion to catch all the inconsistencies on the board so it serves another purpose too. You don’t get that from a classic standup.

I would also point that this approach does very good job in terms of keeping work in progress low. It simply changes the dynamics of the discussion toward everything that is in progress from a team perspective instead of work started by individuals. The latter doesn’t take into account all the waiting queues.

Finally, it scales up pretty well. You can run such a standup with a dozen or more people and it still fits nicely 15 minute slot. It’s not rare when you need only one third of that even with such a big team.

The impact of changing the standup pattern is almost instant. All in all, it makes standups more valuable for the team. Try this approach, especially when you struggle with the current one right now.

Tagged as: communication, kanban board, project management, standup

{ 0 comments }

Maturity of Kanban Implementation and Kanban Kata

by Pawel Brodzinski on April 17, 2013

One of interesting bit of work that is happening in Lean Kanban community is Hakan Forss’ idea of Kanban Kata. Kanban Kata is an attempt to translate ideas of Toyota Kata to Kanban land.

A simplified teaser of Kanban Kata is that we set a general goal, a kind of perfect situation we unlikely ever reach. Then we set short term, well-defined, achievable step that brings us closer toward the goal. Finally, we deliberately work to make the step, verify how it went and decide on another step. Learn more about Kanan Kata from Hakan’s blog.

Honestly, I was a bit skeptical about the approach. One thing that seemed very artificial for me was the advice how we should define short term steps that lead us toward the ultimate goal. “Improve lead time by 10% in a month.” What kind of goal is that? Why 10%? Why in a month? How should we feel if we manage to improve it only by 8%? Should we cease to continue improvements when reaching the goal after a week?

I know that these questions assume treating the goal literally and not very much common sense but you get what you measure. If you set such measurements, expect that people would behave in a specific way.

I think the missing bit for me was applying some sort of relativity to Kanban Kata. Something that would address my aversion to orthodoxy. Something that would make the application context broader. I found the missing link in David Anderson’s keynote at London Lean Kanban Day.

Interestingly enough, the missing link is my own work on maturity of Kanban implementations. Yes, it seems I need David to point me usefulness of stuff that I did.

The context of my work on depth of Kanban implementation is that instead of trying to use sort of a general benchmark I simply used “where we would like to be” as a reference point to judge where we are right now. In short: I’m not going to try to compare any of my teams to, e.g. David Anderson’s team at Corbis. Instead I want any team to understand where their own gaps are and work toward closing them.

Such an approach perfectly suits setting the goal of Kanban Kata, doesn’t it?

I mean, instead of having this artificial measure of improvements we have internally set end state which is resultant of opinions of all the team members. On one hand this approach let us avoid absolute assessments, which rarely, if ever, help as they ignore the context. On the other it helps to set meaningful goals for Kanban Kata-like improvements.

Relativity requires a team to understand the method they are trying to apply, but I would argue that if the team doesn’t understand their tools they’re doomed anyway.

Tagged as: kanban, kanban kata, measures, radar chart

{ 2 comments }

Pawel Brodzinski on Software Project Management

Hire the Best

What Makes Teams Better