Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • 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.

  • The Project Portfolio Kanban Story: First Changes

    Those of you who remember my Kanban Story probably remember how important experimentation mindset was for me since the beginning of my journey with the method. On project portfolio level the only difference was that I was well aware that such attitude is crucial even before I started doing anything at all. In other words I planned to adopt such attitude.

    With this kind of approach you should expect changes in the process and, as a result, changes on Kanban board as well.

    OK, let’s start with what I had on the day one:

    What was wrong with it?

    Well, maybe not really wrong, but it soon appeared I needed more information from the board than I’d already had.

    First thing, which became clear and actually could have been predicted, was that throwing all future projects into a single “planned” bucket was an oversimplification. Actually a planned project was pretty much any project which wasn’t yet signed, meaning that there were still many bad things which could potentially happen before we were 100% sure we would be doing it.

    Soon enough I had two groups of planned projects: these which were still expected to be built in near future and those which were in doubt for whatever reasons. Once I realized it I just added another column to the board. Since it was very unlikely that a project “in doubt” would automatically go into development and most probably it would go back to “planned” stage before, I added the column on the very left and index cards could freely go between “planned” and “in doubt” back and forth as I was learning new facts on the projects.

    Second problem was related with general status of projects. As I needed to pay more attention to challenged projects than to these which were doing perfectly fine this information was crucial to have it at hand. I decided to go with a simple green-yellow-red statuses, meaning respectively that project was going as planned, wasn’t going as planned but changes could be absorbed by project team or agreed upon with clients or wasn’t going as planned and unless something was done we were likely to fail.

    Technically I just grabbed a bunch of color magnets and attached them to all projects in “ongoing” phase. I was changing magnets to different colors whenever a project changed its status according to above definitions. Once I clearly saw which projects are at risk, and I saw that a dozen or more times a day, I could easily ask for more information on a project, look for risk reduction actions, set a higher priority to a project or whatever I felt could help to bring it back to the right track.

    After changes the board slightly changed:

    Portfolio Kanban Board 2

    However that wasn’t all. Third issue I was facing was that I couldn’t tell looking at the board when we were expected to deliver a project. It was super-important information as without knowing the dates it was hard to say whether project was going according to the plan or not. After all without dates I could hardly say I even knew the plan. It was also very difficult to plan future projects as I couldn’t really tell when this or the other team would be free.

    And this is why my index cards started evolving as well. At the very beginning an index card for a project was very simple:

    As process described on the board wouldn’t tell me anything about dates I decided to add this information to index cards. I wrote any key dates we knew for a project. It could be stage deadlines if we had multiple stage deliveries or deadlines for delivery, user acceptance testing and project closure, etc.

    Then, as you may easily guess, these dates started changing, either in controlled or uncontrolled manner. Either way I ended up crossing out the old dates and adding new ones. Despite the fact that index cards started looking a bit cluttered I realized that the fact that dates had changed was important to me as well so decided to keep it this way.

    And then I had all the discussions on budgets. I mean one thing is to deliver on time, another one is to keep a project within budget. So yes, I was having these budget-related chats pretty regularly. Of course I could refer to budgeting application, but then I wanted to work on the data which is up to date. This disqualified the budgeting app as sometimes we had old data there. What more, there was a number of different reasons why we had it this way, be it anything from preserving initial budget estimates to bug in the system.

    Anyway, I ended up writing budgets on index cards. And again, whenever budget was changing I was crossing the old number out and adding a new one.

    A new index card looked like this:

    Besides the initial information, which was project name and team or teams working on a project, I had project status and a sort of notebook for important facts regarding the project (dates, budgets). Why do I say that it was a notebook? Well, after some time handful of index cards looked not-that-clean:

    Anyway, I had the information I needed.

    Of course all these improvements didn’t happen in a single day. It was more of a constant process of small adjustments and tweaks spread over a longer time span.

    There’s also one approach I used, which you may find useful. When I was adding dates or budgets to index notes, I didn’t checked them for each and every project which was on the board already. I just set the policy that each new index note which makes it to “ongoing” column had to have the data filled. In terms of projects which were already in development I was adding this information slowly over time, usually whenever I was discussing the very project and somehow dates or budget became important in the conversation.

    It meant that eventually I’d have had complete information either because I gradually updated all the index cards in “ongoing” column or because projects were finished and the cards were moved to “maintenance.”

    After all these evolutionary changes I was still kind of unhappy with the board. I still didn’t feel I had any explicit limits and, what even worse, I didn’t see any simple method to add them. I also noted that sometimes I found it hard to keep all the information updated, as the board was still fully owned and managed by myself. However I decided not to go with it to the outside world unless I was sure it was going to work.

    So no, that’s not the end of the story. However, I encourage you to read it from the beginning.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • In Defense of Difficult Decisions

    I made quite a bunch of difficult decisions in my professional life. I underestimated their negative impact a few times. I received a lot of flak for making them in the first place. And I would probably make vast majority of them again if I had a chance.

    I also restrained myself and didn’t make a few harsh decisions. Sometimes I wanted to do it but couldn’t, sometimes I could but didn’t have guts and sometimes I just didn’t want to deal with consequences. Given the chance I would likely act differently in these situations.

    It seems I’m a bit gung-ho when it comes to fighting status quo. Why?

    Well, first thing is that whenever you’re reading a story how a company was turned around the story always has this big change, which eventually results in a new, better situation. If you’re doing great that’s fine – do more of whatever you’re doing.

    However, pretty few of us are in a position where we can say that we’re doing totally fine. It means that we need to try, sometimes hard, to change things around us. It means that we need guts to make difficult decisions on occasions.

    What kind of decisions you ask? Well, so far the most difficult decisions I made were somehow connected with people. It was either about letting them go, which may be just a neat metaphor for firing, or not giving them what they wanted, or moving them out of their comfort zones.

    After all, if everyone around is happy with your decisions, they aren’t difficult.

    So we come back to the question which so far I’m trying to avoid answering to. Why am I willing to face unpleasant consequences instead of just accepting status quo?

    One answer would be that I’m physically unable to accept mediocrity. I mean, in the long run. It doesn’t mean that I’m not willing to work in an organization that sucks. I did, at least once, and even though the starting point was really appalling, the thing which kept me there was a chance to change things around. The thing which frustrates me way more, and mean much, much more, is when you aren’t allowed to improve the situation even if you want it badly. Then, it doesn’t really matter what the starting point is. It may be decent but if it isn’t going to change my frustration will grow. And I don’t like to be frustrated, thus guts to make difficult decisions.

    Another answer would be that the real change more often than not requires difficult decisions. I like a metaphor I learned years ago from one of my friends: “powdering shit.” It doesn’t make it smell better or be more pleasant. It’s just fooling yourself – “it is powder, you see, not shit.” Well, no, not really. It smells like shit, looks like shit, it is shit. Sorry. Powdering it doesn’t improve it. At all. You want to change the aroma? Clean the mess. Get your hands dirty. There’s no easy way. The only way is difficult (and unpleasant). Thus difficult decisions again.

    It doesn’t mean that bold decisions are a way to go in each and every situation. No. The problem is, it’s way easier to find people who prefer accepting mediocre status quo than painful changes for the better. 4 out of 5 people (OK, I’ve just made up this statistic) will prefer to wait to the least possible (possible, not reasonable) moment before they make a difficult decision. Sometimes this waiting takes years. Years of mediocrity or, even worse, years of witnessing how the situation slowly deteriorates to the point where company goes out of business.

    And this is another reason for difficult decisions. There are few people having guts to make them. People, in general, would likely accept them, even though some of them would complain, but they don’t make them. Ever. Unless forced. Even if they say otherwise. After all, who likes to do unpleasant tasks? So yes, my gung-ho approach sort of compensates ultra-conservative approach of majority, thus difficult decisions once more.

    Now, don’t understand me wrong – difficulty that goes along with a decision doesn’t automatically make it a good one. You can be wrong with a difficult choice as well as with an easy one, except in former case it will hurt you badly. No risk, no fun, they say.

    However, when I think about wrong decisions I made, somehow majority of them are those which seemed ease at the time of making them. It was sort of accepting status quo. “It was always like this, why would you want to change it?”

    To make it better. To make our teams better. To make our work better. To make our products better. To catch up with ever-changing business environment. Or, in other words, to keep the organization alive in the long run. Not a bad motivation, eh?

  • Why You Should Ask: “Why?”

    David Joyce shared a short story on Twitter how a team was told by a coach to switch from Kanban to Scrum and they eventually got back to what they’d had initially. It seemed to that the team had been operating pretty well in the first place so I was curious why they were told to change.

    It seems that coach’s argument was that they weren’t agile.

    Ouch.

    I think I should start with a few disclaimers. Yes, you can officially consider me a Kanban proponent. No, I don’t think that Kanban, in general, is superior to Scrum (or any other specific approach). Yes, I like Scrum and witnessed it working very well for some teams. No, I don’t think that Scrum, in general, is superior to Kanban (or any other specific approach).

    I do however have problem with people selling agile, or any other approach, as it was the one and the only revealed truth. I do have problem with people selling agile as the way of life. I do have a general problem with any orthodox folks out there selling their snake oil.

    The problem is there are more and more such people. Agile is already a business. Scrum is a business as well. Soon Kanban will be business too. This means there is plenty of people who are selling ready-to-apply solutions without even thinking how they might be used in a given environment. Or whether they are applicable at all.

    You should avoid these people. The problem isn’t that they aren’t helping. It’s even worse. They are actively harming your team.

    One theme which often comes to me whenever I’m working with different teams or preaching agile or lean is that not only should you learn the method of your choice, but also understand why it works. “Whys” are crucial here.

    If you understand why a specific practice or rule is there you can fine-tune it in a way that doesn’t harm the team, or substitute it with other technique which covers with the same gap. Otherwise it’s just following the book.

    Now, it’s perfectly fair to follow the book if you and your team aren’t experienced with different methods and don’t have answers for all the whys at hand. However, if we take coaches, people who earn money teaching us, it is their freaking duty to understand how, why and where tools they sell happen to work.

    Otherwise they are like the coach from David’s story. Selling his snake oil with bullshit arguments like “it isn’t agile.” Well, I’m not agile, so what? Would my customers pay me even a buck for being so? I thought they were paying me for software I build and using this or that method is reasonable if and only if it can help me to be more effective.

    When I see snake oil salesmen I’m sad. I’m even sadder when I see people buying their snake oil. If we can do anything about this, we can try to reach as wide audience as possible with our message. Avoid orthodoxy. Avoid people who have the same answer for every problem. Avoid those who can’t answer your whys. And don’t be afraid to call bullshit.

  • Effective Standups around Kanban Board

    You can hear here and there that Kanban scales up pretty well. Actually one of Scrum issues, and I believe one that isn’t addressed neatly, is what to do in projects that take more people than a single Scrum team can accommodate. Definitely one thing which is surfaced pretty soon as Scrum team grows is standup meetings.

    As you go with three standard questions through growing team it naturally takes more and more time. Soon it can be a problem to fit into short time-box you have for such meetings.

    When team are adopting Kanban they usually leave standup unchanged. However it means that, at some point, they face the same issue as Scrum teams do – 15 minutes is not enough anymore.

    Recently Jorn Hunskaar shared such story on his blog. It prompted me to combine a bunch of ideas into a single answer that can be a guide how to improve standups organized around Kanban board. I left a lengthy comment on Jorn’s blog although I believe it is worth to share the idea here as well.

    Instead of running typical round-the-table with answers about what happened yesterday, what is going to happen today and what issues are there you may try to redesign the pattern you follow on standup.

    • First, go through all the blockers (if there are any). These are definitely your pain points at any given moment. It means that you definitely want to invest precious standup time on blockers. This is no-brainer.
    • Second, discuss expedite or emergency items (again, if there are any). This is top priority work from the perspective of the whole team. This is something you really need to get done even at cost of delaying other work. Again, something which is worth investing scarce resource into.
    • Third, go through items that hasn’t moved since last standup. These are items which may be risky. Maybe they weren’t supposed to move but in this case it would be a quickie – not much discussion needed. Otherwise it is worth to have a brief analysis what happened that prevented moving cards forward. By the way, it means that you should have some kind of mechanism to mark index cards which aren’t moving, which is usually tricky.
    • Fourth, go through everything else. One more guidance you can have is discussing items of one class of service after another in order of priorities. In other words you start with highest priority class of service (bugs, critical features or what have you) and discuss all items of this class of service. Then you move to another one. Well, at least this can work considering that you can tell which class of service is more important than other.

    One more rule would definitely be reasonable: within each of these groups you start from the right side of the board and go to the left. This shows that the closer an item is to being done the more you want to discuss it as you are closer to complete it, thus bring value to your users, clients and stakeholders.

    Now, up to this point there is little difference – you still go through every single work item which is on the board. There is different focus on issues and you may skip discussing obvious pieces of completed work but still, a lot of stuff to go through.

    However, given that you’ve just sorted topics to discuss by priority you can just use a simple trick and just finish discussion when the time of the meeting has elapsed, no matter if you were able to finish all the things. It likely means that you’ve covered all the items from first three groups, and definitely all of them from first two, and whatever leftovers you have are items which require least discussion or no discussion at all.

    It also means that on a good day you can cover all things, or more things than on worse day, but that’s perfectly OK. What you basically need is to ensure that most important stuff doesn’t go unmentioned.
    Going a step further means that you can skip a discussion over a specific groups or sub-groups of items, e.g. a specific class of service, when you see it doesn’t really add any value. If you aren’t sure try to cover it during standups and see what outcome you get. Then you can start experimenting with the plan of the meeting.

    Ideally, after some time, you will end up discussing only important stuff, say, blockers, expedited and stalled items and maybe others which are brought by any team member for an important reason and just skip regular work which needs no more attention than a silent confirmation that everything is perfectly fine.

  • Product Owner versus Product Ownership

    Product Owner (capital letters) is a role known from Scrum. The role which is defined pretty well. Sort of. Actually, sometimes I think that there are almost as many approaches to Product Owner role as there are Scrum teams.

    In theory it is an ideal situation when PO is client representative working closely with a project team. That’s the theory. In practice I could hardly point any team that has comfort of such setup. More common scenario is PO on vendor’s side, a member of the team, who is acting as client’s advocate the best they can.

    However, for many teams it is still too good to be true. The only thing they want is to have a single person that can answer any product-related question in reasonable time. I once called it an acceptable scenario. Bob Marshall answered that it is as acceptable as broken leg is, which is also true.

    I treat such solution as acceptable as I know many teams that don’t even get this. In other words broken leg is still better than no leg at all.

    Anyway, my point is that understanding of Product Owner role is um… broad, to be delicate. However, more interesting dispute would be about reasons which PO role was introduced in Scrum for. Now, excuse me this generalization, but basically PO role is there because we, as a team, want to know what the heck the right thing to build next is.

    Product Owner role is set as an important part of Scrum team model, gets tools to mark out and correct team’s course (planning meetings, demos) and is a go-to person whenever any scope-related doubts pop up. Saying that PO tells the team what to do would be an oversimplification but generally it’s PO who has almost full control over what the team builds.

    What about product ownership (small letters) then? Well, I’m not really fond of definitions or labels, so don’t treat the following as an oracle’s epiphany, but when I use the term product ownership I mean roots of Product Owner role: knowing what is the the most important thing to build at any given moment.

    Note: I point roots of PO role and not the PO’s duties. The difference is important as Product Owner, being a part of Scrum, is pretty well-defined, formalized and prescriptive approach to the problem of product ownership. And definitely not the only one.

    If we discuss a project you work on, I don’t want to know who is your Product Owner, product manager or whatever-you-call-them. I don’t even want to know how you call them or what flavor they are of. What is really important for me is how you know that you’re building the most important thing at any given moment.

    If you don’t have a damn good answer for this question you’re likely wasting money of your employer.

    Knowing what is important is a clue of product ownership. Good Product Owner is only one of paths of pursuing this goal.

  • The Project Portfolio Kanban Story: A Basic Approach

    You already know why I decided to try out Kanban as a tool to organize our project portfolio. To be honest I didn’t spend much time on considering the initial Kanban board design. Remembering about experimentation mindset you should have when using Kanban I decided to start with anything which seemed sort of reasonable and adjust the whole thing on the way.

    One of observations I made recently is how we stick to standard Kanban board designs. It seems that this is a path of least resistance – to use what we already know and are familiar with. I pretty much did the same. I started with a design that I used when I was applying Kanban on a team level. I just tried to map a process in a very generic way to a list of stages, and then track projects as they go from the left side of the board to the right.

    This is what I started with:

    As you can see I started on a pretty high level. We had projects we expected to start soon, and most of them eventually were started. Then we had whole ongoing phase separated only to three, very generic stages.

    As our clients are typically rather big companies most of the time we have pretty formalized analysis phase at the beginning of a project. This stage was worth separating as it there are significant differences, both in terms of effort we invest and people involved, between analysis and building stages.

    Then there was generic building phase. I didn’t try to track details for example in projects where we had iterations. I didn’t try to show specific stages in projects where we could define them. One reason was that the development process isn’t homogenous – depending on a client, a size and a type of a project, a development team and a few other criteria this process can look differently. Another reason was I didn’t want to go into deep details, especially not with the first version of the board. After all it was expected to be changed.

    The last building stage sub-column was representing projects which went into user acceptance tests. Similarly to analysis, pretty typical stage, even for clients that get iterative deliveries. And again, a part of a process we wanted to distinguish as it usually is a pretty specific in terms of team’s involvement.

    Finally, there was maintenance column which is sort of done column on steroids. On a typical Kanban board done column is a way to say that we don’t plan to do anything with an item which made it way there. Eventually, we remove an index card or a sticky note from the column to make a room for incoming ones. On a project portfolio level moving cards into the last column is sort of double blessing. Not only do we know that we are done with building a project but we also switch into maintenance mode, which is usually the most profitable stage of a project lifecycle.

    A pretty natural move to make was attaching team names to project index cards. Even though we were changing teams responsible for projects very, very rarely I decided to go with small stickies attached to index cards as sometimes it happens that a couple of teams are working on a single project.

    Now, a couple of things which weren’t that intuitive with this project portfolio Kanban board. First, there were no limits whatsoever. I played with the idea of adding some but eventually, I came to a point that it’s not only a number of projects that matters but the size of them is equally important. In other words one team can cope with a single big project or a few smaller ones concurrently and both are perfectly acceptable scenarios. I just decided to see how it goes and make up my mind about limits later on.

    Second, the board wasn’t really co-owned by everyone in the team. OK, in a team of almost 150 people it would be sort of difficult to have a board co-owned by everyone. However, considering there are just about a dozen project teams we could have one representative of each team and we all could perfectly work on a single board. Well, we theoretically could, if not the fact that we were spread over the whole building. Also, I didn’t want to enforce on each and every team a new duty which might well change pretty soon.

    I decided to start with this project portfolio Kanban board treating it like a personal Kanban board. It was owned, updated and changed only by myself; although anytime I was learning a new fact on any of projects I was updating the board. Soon enough I started having visits not because I was in the room, but because the board was there.

    A nice side-effect of such approach was that I could have my project portfolio Kanban board on one of whiteboards in my room which meant it was always at hand.

    Either way, I knew it was sort of temporary state. The goal was either to move toward co-ownership of the board or dropping the tool all along. As later appeared I pursued this goal soon, but that’s a subject for another chapter of The Project Portfolio Kanban Story.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • The Purpose of Retrospectives

    Those of you who read Software Project Management regularly know for sure that I have sort of experimentation attitude. I like to try different things, see how they work and, if they sort of do, share my experience here with you. I’m particularly happy with a bunch of such concepts, one of them being ad-hoc retrospectives.

    This story is more than a year old, but recently Bernd and Ilja from it-agile reminded me about it with their comments under the post.

    A short version of the idea is that, instead of doing regular retrospectives bi-weekly, monthly, or whatever your cadence for retrospective is, you do a very short and focused ad-hoc discussion on a single problem raised by any team member. The outcome should be similar to what you get from a regular retro – an action point, or a bunch of them, aimed at solving the issue. In my case the whole mechanism proved to work very effectively. If this teaser sounds interesting I strongly encourage you to read the full story.

    Both Bernt and Ilja pointed that I shouldn’t call it a retro. As Ilja puts it:

    Retrospectives are more than just meetings where you solve problems you are already aware of, anyway.

    Well, I guess we are in full agreement on this one. The only difference is I actually believe that even with ad-hoc retrospectives we are (usually) solving problems that we aren’t yet aware of. At least we aren’t when we launch the retro. Pretty often we start with just a symptom. Someone spots something that they think is worth discussing. So here we are – at ad-hoc retro.

    First, we don’t have to agree that this is a real problem and often, initially, we don’t. Thus a discussion. Even though we actually are focused on this single starting point, we dig deeper trying to find some common denominator for our views.

    Second, as I’ve already told you, we usually start with just a symptom. Quite often we are yet to discover, and address, a root problem.

    Finally, we try to come up with some action points to fix a root cause we agree on.

    Now, I happen to facilitate a bunch of regular retros recently and all of them seem to follow similar pattern, no matter the team or the organization. We start with a handful of things we like or don’t like, try to cluster them somehow, look for root causes and address them. However, it all starts with observations people make.

    It’s not some kind of magic that tells us what we are doing wrong. It’s not an outsider who comes and blesses us with an epiphany. It’s not a scientific process which makes us come up with the right solution. It’s the team that finds it out by themselves.

    In both cases: regular and ad-hoc retros the outcome is similar, the process is similar and even the same people do the job. The main difference is granularity. While during a regular retro we try to cover things which happened during a specific time-box, on ad-hoc retrospective we start with just a single idea. An idea we would write down on the on a sticky note at the very beginning of the next regular retro anyway. In other words we would bring it up as well, no matter the process.

    I just wanted to add that another difference is, that during typical retros, not every problem is acted on. We usually try to focus just on a bunch of most important things at the moment. However, on a second thought it works the same with ad-hoc retrospectives. Sometimes after a brief discussion we just decide to leave a thing alone for the time being. We either don’t share views of a person who proposed the issue or don’t see any action points that we could agree on or whatever else. So similarly to regular retrospectives the outcome can be “do nothing” too.

    If nothing so far convinced you that both concepts are surprisingly similar I have a question about a purpose of retrospectives. It is improvement, isn’t it? We want to do better in future that we’ve just done. If so, we can perfectly do this job using both approaches. Of course, depending on a team’s maturity I would go with one or another, but that’s a totally different story.

    Of course we can bring it down to some orthodox discussion over definitions, but don’t count in. I’m more into solving problems than arguing over definitions. It just feels more useful.

  • Get Rid of Estimation

    Software estimation. Ah, a never-ending story. Chances are good that, whenever you’re talking about building software, this subject will pop up soon. You can be pretty sure that basically everyone around has problems with estimation or simply struggles with it. And that’s virtually obvious that there would be a new sexy method of estimation every year or so. The method which is claimed to solve an unsolvable puzzle.

    Recently there was yet another question on estimation on Project Management StackExchange. This sole fact isn’t probably worth writing a whole blog post about that, but there was one side thread which is worth focusing at.

    One of advices I shared was that whenever you can you should avoid estimation at all. This sprung sort of objection. OK, so the subject definitely is worth wider discussion.

    First things first. Why do we estimate at all in the first place? Well, we usually want to know how much time it’s going to take to build this damn thing, don’t we? Um, have I just said “usually?” Meaning, “not always?” Actually yes. It’s not that rare when we either don’t need any estimate at all or we just want to have a general insight whether the project will be built in hours, days, weeks, months or years. In either of these cases just a coarse-grained wild-ass guess should be fine. If it’s needed at all.

    OK, but what about majority of cases when we need some kind of real estimate? For example all those fixed price projects where estimates are basically a part of risk management, as the better the estimate is the smaller are chances that the project goes under water. I can’t deny that we need to have something better than wild-ass guess then.

    Yet, we still can avoid estimating quite often.

    Let me start with one of obvious things about estimation: if you base on historical data, and you apply them in a reasonable way of course, you can significantly improve your estimates. In other words, no matter the method, if you are just guessing how much something is going to take, you will likely to end up with way worse results when compared to a method, which uses your track record. And yes, I just dared to name planning poker “guessing.” It is collective, involves discussion, etc but usually it is just this: guessing.

    Cool, let’s use historical data then. What’s next? My next question would be: how precise must your estimates be? Seriously, what kind of precision you aim for? My point is that we need very precise estimates very rarely. This is by the way the reason why I don’t use Evidence Based Scheduling anymore.

    Anyway, ask yourself a question: how much you would pay for bringing your estimates to the next level of precision. Think of it like being correct in terms of estimating in years, months, weeks, days, hours, etc. Let’s take just an average several-month-long, fixed-priced type of project.

    If I’m wrong with years I’m totally screwed, thus I’d pay significant part of project budget to be correct on such level. If I’m wrong with months it might be a hit on our reputation and also it may consume our whole profit we get of the project, so I’d be ready to invest something around the profit to be correct with months. Now weeks. Well, a week here, a week there, does it make such a difference in this kind of project? Can’t I just assume there is some variability here? Unless of course our deadlines are written in stone, e.g. you adjust your software to law changes. In most cases I’d invest just a handful of bucks here at best. Days? Hours? Are you kidding? Does it even make a difference that I spend a day more on such project?

    Now you know what kind of precision you expect from your estimates. Would it be possible for you to come up with estimates of such precision basing purely on historical data? I mean, can’t you just come up with a simple algorithm which automatically produces results reasonable enough that you can forget about all the effort spent on estimation?

    Whenever we come to discussing estimation I like to share the story from one of my teams: basing on a fact that we were collecting data on our cycle times and we reduced variability in task sizes coming up with the idea of standard-sized features we were able to do a very good job with estimates not estimating at all. We were simply breaking work down so we could learn how many features there are to build and then we were using very simple metrics basing on our track record to come up with the numbers our sales department requested. By the way: a funny thing is, almost all of that appeared as an emergent behavior – something we started doing as a part of continuous improvement initiative.

    Either way, even though we were capable of providing reasonably precise and reliable estimates we didn’t really estimate. I was surprised how easy it was to get rid of estimation, but then I can come back to the point from the beginning of the article: what is the point of estimation? You don’t do it just for the sake of performing the task; you do it for a reason. As long as you achieve your goal, does the method really matter? It means that you can get rid of estimating even if you do need some kind of estimates.