Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Author: Pawel Brodzinski

  • You Can Deliver Late

    It is a problem that never really goes away. You build your app and at the beginning everything seems to be as planned. Suddenly you realize you are late. For the sake of this post it doesn’t really matter whether late means 6 more months in 18-month long project or a day in a week-long sprint. Either way you realize you won’t make it.

    Then, people go crazy.

    Depending on team’s maturity you will notice a range of different behaviors. Anything from cutting corners on quality (“we have this buffer here we can use – it is called functional testing”), through abandoning best practices (“maybe we hit the window if we skip writing unit tests”), cheating client (“let’s deploy and we’ll be building the rest while they’re testing”), throwing features out (“oh, they are just saying it is crucial, they’ll manage without this feature and otherwise we won’t make it by the deadline”), to working team’s butts off beyond any limits (“hey guys, I know it’s the fifth weekend in a row, but we need to finish it and we aren’t anywhere close”).

    I have a question for you: how often do you consider being late as a viable option?

    My wild-ass guess answer: way too rarely.

    I mean, how many times in your life have you worked on a system that really had a deadline written in the stone? How many times there would be deadly serious consequences for your users and/or clients if you were late. Not tragically, hopelessly, beyond-any-recovery late, but simply late. Like a day every couple of weeks or a month every year.

    Personally I worked on such project only once. We were adjusting ERP system to new law after Poland joined EU. Deadline: May 1, 2004.

    Guess what. We were late. A week. And then, like hours after we released we found a bug which basically got medieval on the database. Almost another week to publish a hotfix that made the software usable again. And you know what? Nothing happened. The sun rose again, the moon was there at night, we didn’t lose our jobs, and our clients didn’t lose theirs. It was OK.

    It was OK, even though we missed the deadline that actually was written in the stone.

    Well, if we missed it by a couple of months we would probably be out of business but still, a couple of weeks were sort of acceptable.

    You can miss your deadlines too. They aren’t going to kill you for that I guess. And yes, I am well aware that being a supervisor of a dozen project teams it is unlikely that I am expected to state such opinions so openly.

    Yet still I believe that the price we pay for being on time when it can’t happen on reasonable terms more often than not is bigger than any value we might get by hitting the window. And talking about price I think about dollars, euros or whatever currency is on your paycheck. Actually most of the time we pay for decisions mentioned at the beginning of this post long way after the deadline passed. We pay in maintenance cost, we pay in discouraged users that can’t really use the app, and we pay in burned-out teams.

    So next time you’re going to make your call, consider this: you can be late. Even more, most of the time, being late is fairly OK.

    Advertisement: Infragistics® NetAdvantage® for jQuery expands the reach of your web applications by using the NetAdvantage jQuery controls that are cross browsers, cross platforms and cross devices supported. This fully client-side JavaScript & HTML5 based toolset is equipped with Line of Business UI applications needs with rich interactive dash boarding charts in HTML5.

     

  • The Project Portfolio Kanban Story: Why Standard Board Design Is Not a Good Choice

    When I was starting my journey with Kanban on project portfolio level I based on a classic board design I knew from my work with Kanban within project teams. I basically tried to map value stream to the board but on a different level.

    The effect was sort of predictable.

    Portfolio Kanban Board 2

    It was also naive.

    The basic strength of such design is it’s very intuitive. Well, at least for these parts of the world that read from left to right. The same way we read the board: whatever is closer to the right edge of the board is closer to completion. The value stream we map may be a bit simplified (as me make it linear) but then it isn’t that much of a problem – after all index cards are flowing through the board pretty smoothly.

    Unless you put on single index cards “tasks” that last a year or more, which is exactly what I have done.

    When you’re looking at very long lasting projects you look for different information than in case of several hour long tasks. It isn’t that important how an index card is flowing through the board. After all you expect it to sit in one place for months. If you find out that the status of the index card has changed a few days late it likely isn’t a problem at all.

    It is way more important, and interesting at the same time, to see teams’ capabilities in terms of undertaking new projects, i.e. how much more we can commit to our clients. Note: we aren’t talking about a single team of 7 (plus or minus 2). What we have here is 100+ people working on a couple dozen different projects concurrently. At this level capabilities are pretty damn difficult to estimate, especially given ever-changing business surroundings.

    This is a huge weakness of the common board design: it doesn’t really help you with estimating free capabilities. It would help if we were able to set reasonable WIP limits on such board. Unfortunately, it is (close to) impossible.

    A number of projects isn’t a good candidate to measure WIP, as projects differ in size hugely. If you use time-boxing you could try using a number of time-boxes as a measure. However in this case you don’t want to have a random team working on thirteenth iteration of a project that was build so far by the other team. With WIP limits measured by the number of iterations you would likely end up this way. Another idea was using money-related measures. This brings a question whether you sell all your work for the same prices. I guess that is true in very few cases and definitely mine is not one of them.

    The longer I thought about it the more often I was coming back to people. I mean a team could start another project if they had some free people who could deal with it in planned/expected time frame. I even thought for a moment of setting base WIP limit around 130 (roughly a number of people working on projects represented on the board) and having each index card to weigh as much as there were people involved in a project at the time. The problem was the hassle needed to manage such board would be horrifying.

    On the other hand measuring WIP in number of teams was way too coarse-grained as we had anything from multiple projects covered by a single team to multiple teams working on a single project.

    All in all I ended up with a belief that, in terms of project portfolio Kanban, standard board design isn’t a good choice. I was ready to redesign the board completely.

    If I piqued your interest read the whole project portfolio Kanban story.

  • How Much Work In Progress Do You Have?

    One of common patterns of adopting Kanban is that teams start just with visualization and, for whatever reasons, resist applying Work In Progress limits at the very beginning. While, and let me stress it, resignation from introducing WIP limits means drawing most of improvement power out of the system I understand that many teams feel safe to start this way.

    If you are in such point, or even a step earlier, when you’re just considering Kanban but haven’t yet started, and you are basically afraid of limits I have a challenge for you. Well, even if you use WIP I have the very same challenge.

    First, think of limits you might want to have.

    Second, measure how the tasks flow through your process. It’s enough to write down the date when you start working on a task and the date when you’re done with it – the difference would give you a cycle time.

    Third, after some time, check how many tasks in progress you really had every day. In other words: check what your WIP was.

    Odds are you will be surprised.

    One of my teams followed the “let’s just start with visualization and we’ll see how it goes” path. We even discussed WIP limits but eventually they weren’t applied. It is a functional team of 4 that juggles tasks which are pretty often blocked by their “clients,” i.e. beyond team’s control. The process, besides backlog and done bucket, is very simple: there’s only one column – ongoing.

    The discussion ended up with the idea of limit of 8, considering there are some rather longish tasks mixed with quite a few short but urgent tasks, e.g. “needs to be done today” sort, and of course there are frequent blockers. In other words rough limits two tasks per person should account for all the potential issues.

    As I’ve mentioned, WIP limits weren’t initially set. Even the WIP limit of 8 looked too scary at that point. After a few months we came back to the discussion. Fortunately, this time we had hard data from a hundred days.

    Guess what the worst WIP was.

    Seven. Over the course of a hundred days there wasn’t a single case that the scary limit of 8 was reached, let alone violated. What more, there were only 5 days where limit was higher than 6. In other words setting the limit of 6 and keeping it would be no sweat. A challenge starts at 5, which sounds very reasonable for such team.

    All of that considering that each and every blocked item was counted within the limit as at the moment the team doesn’t gather the data to show how long a task remains blocked.

    The lesson I got was that we can and should challenge our WIP limits basing on historical data. How often we hit WIP limits. How often we violate them. If it appears that we have enough padding that we barely scratch the ceiling on rare occasions it is a time to discuss reducing WIP limits. After all, it might mean that we are pursuing 100% utilization, which is bad.

    If WIP limits are barely and rarely painful, they aren’t working.

  • Instant Feedback Culture

    There is said a lot about feedback. We continuously learn how important it is and how to deliver it in constructive way. Yet still, for many of us, me included, delivering feedback is difficult.

    I already hear you nodding your heads and saying “yes, especially critical feedback is a hard part.”

    Well, no. Not at all.

    I mean when it comes to critical feedback we happen to fail to do it constructively, but at least we do it. Positive (supportive or however you want to call it) is a different animal though. It’s easier to do it constructively. The problem is every now and then we forget to do it at all.

    But I have a solution. Yay!

    It is totally simple. That’s a good part. Unfortunately there’s also bad news for you. Prerequisites are difficult to achieve.

    OK, the method. I call it instant feedback culture. Why culture? Well, it is the part of organizational culture. The rest is pretty self-explanatory – you deliver feedback instantly. Has someone just said or done something you want to comment on in either a positive or a negative way? Use the Nike way: just do it. Do it instantly or almost instantly. Why “almost?” Um, not all the feedback you want to deliver publicly and the situation or behavior you have feedback on might have happened in a big group.

    You don’t keep it for later, for dreadful performance appraisal or something. You don’t wait until you forget it, which is by far the most common thing to happen. In some way you just get it out of the chest.

    Simple enough, isn’t it?

    Now the hard part. Prerequisites.

    First, trust. Unless you all trust each other it won’t happen. OK, it may happen partially, between people who trust each other, even if you can’t say that virtually everyone trusts anyone else. However, bear in mind that it’s like with number communication paths: between two people, there is one, between three there are there, with four people you have 6, etc. It doesn’t scale up linearly but exponentially. And the more people you get on trust side the more value they get out of instant feedback culture.

    Second, openness. It works both ways: one has to be ready to honestly share what they think and on the other side they need to accept an incoming message. I don’t have to to agree uncritically with it, let alone doing something about it, but I should accept and appreciate someone cared enough to share it.

    Doesn’t look difficult? Believe me, it is. Actually if you asked me what is a single biggest challenge in leading teams I will point building trust as it is totally intangible, yet crucial to get this entity called “a team” working.

    Anyway, considering you’re doing great and these prerequisites aren’t an issue for you, introducing instant feedback culture should be a piece of cake. Just remember to share every little bit of feedback instantly. Don’t wait until it fades away to oblivion. Don’t wait till there is an occasion because by this time it can be totally irrelevant or meaningless. Start sharing your feedback instantly and do it consistently.

    Others will follow. After all we like to receive feedback, especially a pleasant part of it. This way we get relevant feedback and get it quickly so it actually is easy to do something about the thing which is under discussion. Either do more of it (if a feedback is supportive) or change it (it it’s not).

    Soon you will see feedback flying all around in different directions and people, armed with new knowledge, will be improving much faster.

    So go, try introducing instant feedback culture. Considering that your team is ready for it, that is.

  • What Is Slack Time For?

    Jurgen Appelo recently touched the subject of slack time discussing what kind of tasks are supposed to be done in such time slots.

    First thing that I find disputable is reducing slack time to mere padding: “I expect the task to be done in 1,5 hours but to be perfectly safe I’ll start it 3 hours earlier so I can deal with unexpected difficulties.” I guess I’m way closer to Marcin Floryan’s comment under the post. Anyway, that’s not what raised my biggest concerns.

    I don’t agree with Jurgen on what slack is, or should be, for. Jurgen points that when we think about important things, like improvement, refactoring, learning and brushing teeth, we should actually plan for that and not hope that there will be enough slack time to have all of them done somehow. After all, we know that hope is not a strategy. Well, at least not a good one.

    First, I see it a result of a simplified view of slack time. Actually, with Work In Progress limits set properly I can expect to have pretty stable amount of slack time over time. The thing I can’t predict is when exactly it will happen and who exactly will hit the limit and will be granted free slot. However, lucky me, statistics is on my side – the slack time distribution should be pretty fair over time.

    I say “pretty fair” as when I have a very stable process, which software development is not by the way, I will likely face the situation that people who work on bottleneck part of the process won’t get slack time at all. Fortunately software development is really far from being “very stable” and even if it was we would still be able to deal with the situation using different means, e.g. the way Jurgen proposes.

    Second, I actually think that slack is a perfect tool to be used against important but not urgent tasks. Improvement and learning definitely fall into this category. Refactoring may or may not, depending on a software development approach you use. And brushing teeth? Well, unless you accept the fact you’re killing colleagues with your poisonous breath I would treat it as important and urgent.

    Yes, it means that I accept the fact that we may not spend any minute improving or learning (consciously) for some time. Considering my WIP limits are reasonable such situation would happen if and only if a team is perfectly balanced, our productivity keeps super-stable and there are no non-standard cases. Um, have I just said it is impossible not to have slack time? Oh, well.

    Of course there is another situation: too loose or no WIP limits at all. And yes, in such case planning tasks, which would normally be done during slack time slots, is one of ways to go. But definitely not the only one! And not the most effective one either!

    Actually planning improvement, learning, etc. tasks is just adding additional work items to your project. It doesn’t make you more flexible. Pretty much the opposite.

    Simply adding “empty” slack time slots, which can be filled by a specific task which, at the moment, seems most reasonable can be a more effective approach.

    You can do even better though. If your system natively introduces slack time these empty slots will appear not when someone arbitrary says so, but exactly when it is optimal for the system, i.e. when adding another regular task would overcrowd the flow, thus harm the productivity.

    With such approach I believe slack time is actually the right place for important stuff.

    Actually if a task is simply optional I would likely advise not to do it at all. After all, why add the complexity which isn’t needed. Isn’t everything around complex enough? Thus I don’t consider slack time a tool to be used to do optional stuff.

  • Better Conferences or Better Learning?

    Bob Marshall recently published his ideas how to improve conferences. Pretty radical ideas I’d say. Basically what Bob proposes is to move from traditional one-way communication to bi- or multi-directional conversations with expertise available on demand (read the whole post – it’s worth it). By the way similar points were shared by Jurgen Appelo in his writing as well.

    I’m no conference animal, even though I helped a bit to organize a few of such events and attended a few more. I went through different formats, from whole day long workshops, through few hour long tutorials, through anything between 90 and 30 minute long sessions, open spaces, TED-like no-more-than-18 minute-long performances, lightning talks, pecha kuchas and whatnot.

    While I understand Bob’s desire to change knowledge consumption from push model to pull model I find it hard to buy his ideas uncritically.

    There is one reason. The conference isn’t better because this or that format is generally better, but because the very set of people attending the very event learned much. In other words, thinking about an event we should think how this specific set of attendees is going to learn, which is a function of how they expect to learn and how they are prepared to learn.

    One of the best events I ever attended was Kanban Leadership Retreat. It was an unconference. It exploited many of ideas Bob shares. From a perspective of attendee, who was willing to learn even though they brought significant knowledge on the subject, it was great. The learning process was very multi-directional and pretty much everyone was both: a teacher and a student.

    At the same time on occasions I speak at events where such format would fall flat on its face. It would, as people who attend generally expect knowledge to be pushed to their heads. You may laugh but actually even such approach is sometimes expected in a whole spectrum of behaviors. On one end there’s mindless zombie who was sent to the event by the company (yet still they can learn something). On another there’s TED, where you know close to nothing on vast majority of subjects being discussed and actually expect expertise from people on the stage. Note: we’re still in “Dear speaker, I know nothing of whatever you’re talking about” land. I know there is another dimension where you move from one-way learning to everyone’s a teacher attitude.

    So basically my thought on the subject is: first, understand what the effective method of learning is for this very group you’re sharing your knowledge with. And yes, I’m talking here about majority, or average, if you excuse me such vast oversimplifications. I’m saying so because we don’t measure success of event by happiness of most demanding person in the room. Even more, probably the most demanding person in the room shouldn’t be happy with the event, because arguably it would usually come at a price of having many others not catching up with the content.

    Having said that I believe that generally speaking conferences should head the way Bob describes as our focus is still on pushing knowledge, not pulling it. I wouldn’t be so quick to revolutionary change all the events though – I would rather look for opportunity to broaden variety of methods attendees can use to learn.

    This is what a better learning is all about. And better learning is something better conferences should be all about.

  • Learn. Adapt. Experiment. Repeat.

    One of recurring themes in my discussions on different methods and practices we use in our professional lives is: understand why and how the thing works so you can safely adjust it or substitute it with something else and get the same effect.

    A common example is stand-ups. Why are stand-ups limited to short time (15 minutes)? Why were they intended to be done with people standing and not sitting? Why do we answer three standard questions? And finally, how does it help us?

    Can you answer these questions from the top of your head?

    I know, it isn’t rocket science whatsoever. Yet I know many leaders, and even more teams, that would struggle to answer them reasonably.

    Such understanding of tools we use isn’t crucial only because it means you can go beyond by-the-book approach with methods and practices you adopt. It also is a signal that you know and use learn-adapt-experiment-repeat pattern. And this is a game-changer in terms of improving the way you and your team works.

    Let me share a story. I had a management retreat today, which was basically dedicated to discussion over handful of topics that are important for us. During the retreat’s summary a bit of feedback I received a couple of times was about the method of finishing discussions we used.

    Basically we had a Kanban board to organize subjects to discuss and at any given moment we had 1 (if any) subject that was “ongoing.” Now, if anyone out of 14 people in a room felt that discussion wasn’t adding value anymore or was meandering toward something totally different, they put a small sticky on subject’s index card. Once we had 3 stickies the discussion was over and could go further later, meaning during a break or after the retreat, in a group of people interested.

    My goal was simply not to see a dozen people bored to death only because there still are 2 folks who are willing to continue discussing something deadly important to them. At the same time I didn’t want to cut the discussion in half only because a timeslot dedicated for it was over, thus no timeslots whatsoever.

    Although no one taught me the method directly I’d lie if I said that I came up with the idea. Actually a few days ago I read Benjamin Mitchell’s post about two hands rule – a method one can use to cut irrelevant discussions during stand-ups.

    What I learned from Benjamin’s post wasn’t a stand-up-related technique. I learned the mechanism and understood how it worked. I didn’t dismiss the idea only because I don’t regularly attend any stand-up these days.

    Eventually, just after a few days, it came up handy. It required some changes in details as forcing people to keep their hands up for 20 minutes could be considered mobbing, but in its heart it is exactly the same tool.

    What happened here is I learned something new, adapted it as needed and experimented (I didn’t know how it would go). Finally, I learned something new. It seems I’m already at the beginning of the next iteration of the pattern. And I have a new tool in my toolbox. One which comes handy with things I regularly do.

    I’m two steps ahead. How about you? Are you there too or you still are following the book?

  • A Myth of 100% Utilization

    Do you remember your very first job? A junior software developer or a quality engineer. An intern maybe. You were expected to do something. All the time. I mean someone paid you and wanted to keep you busy. You didn’t see a big picture. You just had a queue of tasks you should do. One after another. Like building a brick wall. Brick by brick. Done with one? Here’s another.

    More interesting question is: has it changed over years? I mean you probably changed the role a few times, possibly went through a handful of companies. Odds are you see a big picture now. Or at least a big part of a big picture. Maybe you’ve grown to be a leader or a decision maker. Maybe even things are under your control.

    Nevertheless I’m still interested: whether you or your bosses still expect people to be busy doing the project tasks all the time?

    I guess this is true for vast majority of organizations. We still build brick walls. Brick by brick. Done with one, here’s another. Why bother, you ask.

    Well, this approach means basically aiming to have all the people doing something, for the sake of this post let’s call it “project tasks,” all the time. It means aiming for 100% utilization of people. And you know what? If you aim for 100% utilization you’re likely to get pretty damn close to it.

    The problem is we don’t get paid for being fully utilized. We get paid for delivering projects (again, please let me go with such a generic word).

    Thus, we should be aiming for effective and optimal deliveries and not for having everyone around busy.

    And there the fun begins.

    Intuitively we follow the way of thinking which tells us that we do most work when everyone actually is doing work all the time. Finished with one feature? Go, start another. The project will end faster.

    Except it isn’t true.

    We don’t do simple manual work. We don’t build a brick wall where each and every task of adding another brick is similar, simple and almost completely independent of other tasks. And most of all it can be done without much, if any, cooperation with others.

    There are a few areas where 100% utilization hits us hard.

    Context switching

    This is an obvious statement but switching context comes at a cost. I guess we always perform better when allowed to complete one thing uninterrupted before starting another and the nature of task doesn’t matter here. However, when we think of knowledge work there’s another cost we pay – time we need to get at full speed back again. Time to get into the context of the task. It’s not just another brick which we don’t even think of as our hands do the entire job.

    100% utilization means basically more tasks being done concurrently, because we want to have so much work started that everyone has something to do. It means that tasks are waiting for people. It means that quality engineers have enough developed features to test that they’re never idle and so on.

    OK, but what happens when someone finds a bug? Well, a developer switches back to this feature and fixes it. Then they’ll go back to this new feature they’ve been working on. In the meantime the quality engineer started working on something else and now they need to come back to this issue to retest it. Another context switch. Now, multiply it by a big number and that’s what is happening in many software development teams. Constant context switching, sometimes to work items which were waiting so long that people barely remember what they were all about.

    It costs. Each time probably just a bunch of dollars, but multiplied by a number of such situations it stacks up to huge piles of money.

    Task juggling

    Another problem which comes with having tasks waiting for free people on every stage of the process is that we have lots and lots unfinished work. It means significantly bigger coordination effort you need to invest to keep you machinery working. It means way more prioritization work as every now and then people need to decide what to next. After all they are choosing among a number of different options.

    It might surprise you but prioritization can take a huge toll in terms of time consumption. Let’s go with a simple experiment: prioritize whether you prefer to drink or pee at the very moment. It was quick, wasn’t it? Now, prioritize importance of each and every thing which lies on your desk. How much longer the second task took you?

    Many ongoing features usually also means that you add cost attached to all the product politics. If there are many decision on priorities during the whole process it means there’s a temptation to change these priorities so team members start attending meetings or having discussions where they are told to add this little gizmo to the next release as it will allow conquering the whole world. No! Not the world, the whole galaxy! Now, imagine you could just avoid all that and focus on value-adding work. How happy you would be.

    Time to market

    This one is tricky. If you asked any decision maker whether they want to have shorter time to market they would eagerly agree. However, pretty often shorter time to market bears not that much value. Think of fixed priced custom project for a big client. Even if you can release per feature or you can deploy a new version weekly, chances are good they won’t touch it, even with a stick. And if you deliver the whole solution a month earlier than planned they won’t have capabilities to run user acceptance tests, thus you’ll wait anyway.

    However, there are project where shorter time to market has huge value. Ask almost any web based app targeted directly to end users. In such cases longer lead times are actually counted in dollars.

    Early issue discovery

    Although personally I think this one is overhyped it can’t be omitted. If there’s a problem in your process there’s big value in discovering it as early as possible. Think of broken deployment. If you wait until you deploy the huge product at the very end of the project you are screwed up. However, if you care to deploy first bunch of features as soon as it is possible and reasonable, you discover the issue early, sort it out and eventually live through the final deployment with little or no problems.

    On a side note: why do I think this one is overhyped? Well, if I hear examples of sending mass snail mails, you know, printing some papers, putting them into envelopes, sticking stamps and so on I wonder what can go wrong with such process. Yeah, envelopes can have wrong color. Wouldn’t I notice it instantly? Hopefully our teams know at least part of their craft at this level as we do mailing.

    OK, either way there are quite a few places where we actually pay for 100% utilization. The result is that with the very same team we deliver later when they’re fully utilized than we would if they weren’t.

    I know, this is counterintuitive.

    It also means that avoiding 100% utilization means that we can build our projects cheaper.

    I know, this is counterintuitive.

    Actually, it means that letting our people do nothing on occasions means that we can perform better. And I mean nothing like, well, virtually nothing.

    I know, this is counterintuitive.

    The funny thing is we aren’t that surprised when we think about a highway. When we pack as many cars into highway as it is possible (100% utilization) we expect to see a traffic jam. And that’s what happens. We’ve been there. We’ve seen that. We expect nothing different. Then it is intuitive. Maybe because we’ve experienced that.

    Maybe we should give ourselves a chance to experience it in our projects as well?

    And yes, we can do better than let people doing nothing when they don’t do project work. But that’s a subject for another post.

  • Naming Issue

    There is something I see over and over again whenever people are discussing different methods. I go here with very generic “method” label on purpose as I don’t want to limit this to agile and lean world only. People pay much attention to the choice of words when they describe their ideas.

    Let me give you an example. Recent Al Shalloway’s post discussing MMFs starts with a distinction between MVP (Minimal Viable Product), MVF (Minimal Viable Feature), MMR (Minimal Marketable Release) and MMF (Minimal Marketable Feature). I don’t want to go into this discussion, but the simple fact people use all these different definitions proves that they really care about wording.

    I’ve made similar observation listening to David Anderson describing why he chose specific terms to describe his concepts and what changes he’s going to make in his next publications.

    I see this pattern even when people appreciate a specific choice of words someone used to share their message.

    And I don’t get it.

    OK, that’s not that simple. I understand why people pay so much attention to naming. They try to communicate their thoughts as precisely as possible. They try to describe their message in a detailed and clear way so everyone gets it. Cool. That’s perfect.

    Yet still, I don’t get it.

    Here’s why. I’m not a native speaker. I can communicate in English (or so I hope) and have even advanced discussions on subjects I’m interested in. At the same I don’t understand all the nuances of the language, something which likely comes totally effortlessly for natives. It basically means that, despite the effort of our thought leaders, I sometime just miss the point they addressed with putting so much attention to naming. It’s just lost in translation.

    When we are on translation, well, the problem is even worse. Whenever I speak publicly or train in Polish (my native language) not only do I struggle with my (lack of) understanding of nuances of English language used in sources but also with translating the message precisely enough. Unfortunately vast majority of these nuances is hardly translatable which makes the situation pretty bad.

    Of course I can’t say for every other language in the world but I wouldn’t say Polish language is that special, so my wild-ass guess would be that many others non-native English speakers face similar issue.

    In such cases my solution is to use any name which seems sort of suitable but add a longer explanation. The name itself isn’t that important. What is important is the meaning people attach to it, which by the way, we have only that much control over.

    And that is why I don’t really get this striving for perfection in naming.

    I see the right explanation of whichever words we choose to use as way more important challenge. I can say capability, or throughput, or thingamajig. As long as people know what hides under the name it’s going to be fine.

    This is by the way something I realized a couple of years ago on a session dedicated to translating Agile Manifesto to Polish. Even though probably we all understood the same values we found it really hard to put it into words of our native language in a way that was satisfactory to all involved.

    My realization was: “Whatever. As long as people understand the values wording doesn’t matter that much.”

    My appeal to thought leaders: whenever you are fine tuning the naming, remember that there are many people who just won’t get the difference. Good explanation is way better than good naming.

    And we still suck at explaining even basic concepts.

    You guys may think this whole translation thing is a non-issue and maybe for you that is correct. Remember though there are big parts of the world where English is neither the only nor the first language people use. It’s worth to remind about that from time to time. So I do.

  • On Agile Once Again

    There was said a lot in the old rusty discussion on being agile versus doing agile, The Only Right Mindset, etc. Same with lean but on a smaller scale I guess. In all these discussions I always try to be on common sense side.

    I mean I somehow missed the moment when agile became a major religion and lean a minor one (for the time being), but evidently it must have happened as I see lots of worshippers around. People who know the one and the only way of doing things. People who believe in this or that method. Me? I don’t buy it.

    I will support most agile and lean initiatives I see out there, but it is not because they suit to my perfect picture of the world. It is so because applying Scrum or Kanban, even by the book, is still an improvement for majority of teams. By the way, pardon my “Kanban by the book” as there is no such thing, but definitely there already are beaten paths leading to Kanban adoption so it wasn’t vast oversimplification.

    Anyway, whenever I’m talking with a team about methods I don’t object adopting old-school formal waterfall-like approaches, pardon my French. On occasions I may even advise sticking to them.

    And if you ask me, this is exactly being agile.

    It’s easy to criticize a team which is following a heavy process. The Manifesto says “people over process,” so you’re doing it wrong! But wait, aren’t that people who enforced (or asked for) this process? Are we really that fixed if we can consume changing requirements and still deliver, despite our heavy process? And most of all, isn’t Scrum (to take the example from the top of my head) a pretty formal process as well?

    We are far beyond the point where you could get away with simple labels like “Scrum means agile.” We know more, we understand more and most of all we have hell lot of examples of good, bad and ugly things done under the agile banner.

    If I see a team that has a very formal process enforced by their client and they are doing very well, yet they still look for occasions to reduce the burden of formalities while sustaining the quality I see agile. I see it even if the only practice from Scrum handbook they follow is daily standup. I see agile even if, at the first look, most of people would rate them “hard-core waterfall.”

    On the other hand, when I see a team applying Scrum, Kanban or whatever they believe is the next big thing, and they are doing it blindly, without understanding how the damn thing works, why it works and how it even applies to team’s specific situation I don’t see even a bit of the message which started it all.

    You can say that I oversimplify things. Maybe I do. Yet this approach works for me. This is a lesson I got from jumping on Kanban bandwagon. Kanban is vague enough that the simple message that a team is using the method tells you almost nothing. At the same these few simple rules, which come in variety of flavors, usually bring pretty good results. If you understand what you’re doing, that is.

    You don’t need strict and specific rules to make it work. You just need understanding of the tool you use.

    This is pretty interesting observation as I happen to be part of program board on different agile/lean events and I still see many proposals trying to go through with the message about the ultimate way of doing things. Wake up! We’re past this point for some time already. We don’t need oracles. We need practitioners sharing their ups and downs, successes and failures, and most importantly deep understanding what they are doing, why, and how comes that it happens to work.

    And by the way if you happen to suit this picture somehow I encourage you to submit your proposal to the ACE Conference – the event I can honestly recommend. We still look for a handful of speakers to share their knowledge and experience. Besides, Krakow in late spring/early summer is a really nice place to visit.