Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • The Kanban Story: Kanban Boosters

    During my talk at AgileCE I mentioned three things as biggest Kanban boosters in our case:

    One of comments I heard about this part was: “Pawel, these things aren’t Kanban-related – they would work in any environment.”

    Well, I’ve never said they’re exclusive for Kanban. My point is: Kanban is pretty simple approach – it really tells you to do just a few simple things leaving most of other aspects open. This means you may (and should) use some help from other techniques/practices which set additional constraints or organize other areas of your process. And boosters I mentioned work exactly this way.

    Co-location allows you to keep your Kanban process as simple as possible. You don’t need to use any software to visualize current state of the project – old-school, hardware whiteboard is enough. It also helps to exchange information between team members which is always important but with minimal formal information exchange in place it plays even more crucial role.

    No-meeting culture brings us “do it now” attitude and saves a lot of time usually wasted on meetings. And we discuss different things more often than we would otherwise because launching a discussion is totally easy: you just start talking.

    Best engineering practices help us to keep the code quality under control. That’s a thing which is basically omitted by Kanban itself so you need other tools to deal with it.

    Now, you can perfectly take your Scrum (or whatever kind of) team and use the same techniques and it would most likely work. Oh, it would as long as your team isn’t too big (co-location and no-meeting culture don’t scale up very well) and you don’t have a list of engineering practices enforced by your approach anyway (like in XP).

    So no, these concepts aren’t exclusive to Kanban. They just work in specific environments. Yours either fit or not. It doesn’t really matter if your process name starts with S or K or X or P or whichever letter sponsors your day.

    After all when I think about Kanban I don’t isolate the method from the rest of our environment – that would be stupid. If Kanban works for us it is because the whole setup is good enough, not just its Kanban part. And these boosters are a part of the story.

    Read the whole Kanban Story.

  • Why We Don’t Write User Stories Anymore

    There was a time when we were writing user stories to describe requirements. I’d say they worked fairly well for us. But we don’t do this anymore.

    We were using user stories as a technique which allowed us to describe bigger chunks of functionality. There was one bigger sub-project or module and it had more than 10 user stories attached (usually closer to 20) and a handful of non-functional requirements. During development we were often going through several stories at once as technical design didn’t map directly to the stories. The stories were more of input to design session and a base for test cases than stand-alone bites of functionality.

    Then we switched to Kanban. One of consequences was we reduced the size of average feature which was going to development. It no longer had 15 stories attached, but it wasn’t a single-story task either. If we were still writing user stories to each Minimal Marketable Feature we would probably have few of them. My guess is 2 or 3 most of the time.

    At this level stories become pretty artificial. I mean if you think about 2 stories connected with one feature, i.e. administrator can configure this magic widget and user can use this magic widget to do, well, the magic, you can pretty much tell these stories intuitively in your head. Writing them down becomes overkill.

    Besides that I think the often cited role of user stories which make usage scenarios completely clear is overrated. If you can talk with developers in language closer to the code, and functionality description is much closer to the code than telling user story, you’ll be better understood. The standard problem here was that functionality description wasn’t precise and it often became disconnected with usage scenarios.

    The answer for this problem is: make features as small as possible (but only as small as they still does any difference). Small features are easy to define, easy to understand (even for a developer) and easy to chew. It is pretty hard to screw them.

    There’s one more reason why I don’t consider user stories as a must-have. If you happened to create software which will be used by other developers or administrators at best, like some magic box with a lot of APIs and command line interface as the only UI, you should know what I’m talking about. If you write stories for this kind of software you end up with a bunch of “as a developer I want to call the magic function which does the magic” stories. Doesn’t API specification make more sense?

    I don’t say user stories are bad. They aren’t. But they don’t add value all the time and in every situation. This is just another practice which should be used only as long as it does make sense in your specific situation.

  • People Don’t Want to Learn

    I attended a few meetings recently. They all were one thing in common: someone made some effort to create opportunity for others to learn. It doesn’t really matter if that’s downloading Mike Cohn’s video or preparing and delivering a presentation in person. It is the effort addressed to others. It’s like saying: “Hey, I found this presentation valuable and believe we have a lot to learn from it. I will find a room where we can see it and discuss it.”

    And then just 5 out of few dozens of invited people come.

    That’s because, in general, people don’t care if you want to (and can) teach them something. They don’t want to learn. Chances are you don’t agree you are alike. That’s fine. But in this situation face it: you’re a minority.

    If you belonged to majority you wouldn’t give a damn about your colleague inviting you to a local developers’ meet-up. You wouldn’t feel like watching video from the major conference from your area of interests. And when I say majority I think like 90-95% of people.

    That’s right. I believe barely one tenth people care to learn even when they can do it effortlessly. This is by the way rejecting to become a better professional.

    But at least one third, if not a half, will complain how limited their learning options are. How they can’t meet with authorities in workplace or how they weren’t allowed to attend an overpriced course.

    But there’s a good news too. It’s pretty easy to stand out the crowd – we just need to use opportunities to learn we have.

  • Manual Testing Is a Must

    The other day we were discussing different techniques aimed at improving code quality. Continuous integration, static code analysis, unit testing with or without applying test-driven development, code review – we’ve went through them all. At some point I sensed someone could feel that once they employ all this fine practices their code will be ready to ship as soon as it is all green after build on a build server. I just had to counter strike:

    “I’m not going to ship any code, no matter how many quality-improving techniques we use, unless some human tester puts their hands on it and blesses it as good. Not even a chance.”

    I’ve seen the situation quite a number of times: a team of developers who are all into the best engineering practices, but unfortunately at the same time sharing a belief this is enough to build top-notch applications. I have a bad news for you: if the answer for a question about quality assurance team is “we don’t need one” I scream and run away. And don’t buy any of your apps.

    It just isn’t possible to build quality code with no manual testing at all. You may build something and throw it against your client hoping they will do the testing for you. Sometimes you can even get away with this approach. Be warned though – you’re going to fail hard way soon. The next customer may not like the idea of doing beta-tests for you, actually most of them won’t, and then you’re screwed.

    Manual and automatic testing is fundamentally different. With automated testing, no matter if we’re talking about unit, stress, regression, integration or end-to-end tests, you go through predefined tracks. You had to create the test in the first place so it does exactly what you told it to do.

    On the other hand humans pretty often had their own minds which they happen to use in unpredictable ways. They may for example make up some test scenarios on the fly or they may sense a subtle scent of a big scary bug hiding around and follow their instinct to hunt it down. Every now and then they will abandon beaten tracks to do something unexpected, i.e. find a bug which would be missed otherwise.

    Note: I don’t say what kind of procedure you should follow in manual testing. Personally I strongly believe in value of exploratory testing, but any good tester will do the job, no matter what your manual testing procedure look like.

    Actually this post was triggered by recent discussion between a few bloggers including Lisa Crispin, James Shore, Ron Jeffries, George Dinwiddie and Gojko Adzic. The discussion, while interesting and definitely worth to read, is a bit too academic for me. My approach is that there is no universal set of techniques which yields indisputably best results. While I like James arguments why they dropped acceptance testing and support his affection for exploratory testing I share Lisa point that even in stable environment our “best” approach will evolve and so would techniques we employ.

    You may exchange acceptance testing with exploratory testing and that’s perfectly fine. As long as some fellow human put their hand on the code you want your users to touch with mine that I’m good with that. I don’t care much which approach you choose or how you call it. It is way more important who does the job. Experienced quality engineer with no plan at all will do way better job than poor or inexperienced tester with the best plan.

    Just remember if you happen to skip the manual testing at all I’m afraid your app may be good only for machines as only machines tested it.

  • Managers Are Clueless

    So you’re a manager. You even think you’re pretty damn good manager. Fine for me. Do you remember Pointy-Haired Boss? Yes, that clueless manager from Dilbert cartoon. You have this guy sitting in your head. So do I, by the way.

    Is that supposed to be insult? Well, not exactly. I really think every manager has this clueless version of himself in the back of his head which is used more often than we’d like to admit. You still don’t believe me. Do a simple exercise. Think about your team. Arrange members from the best to the worst. Easy?

    It wasn’t supposed to be easy. The trick is how you decided that one ‘average’ person is after all better than another ‘average’ person. Some guessing I guess. Why exactly you have chosen the best one? And what a couple of worst people have done to earn their place? Is it possible that you justify their position with some past event (success or failure) which was spectacular enough they earn the place in your mind? Is it possible you didn’t take into consideration recent history because you already are strongly biased?

    And now the best part, think how many things you haven’t taken into consideration. You haven’t thought about tons of important things and you were still able to say who is better and who is worse from others. And no, I don’t believe none of them are important. Isn’t that clueless?

    A Confession

    I worked with bunches of underpaid and overpaid folks. I saw work which was underrated or overrated just because of person who authored it or the person who judged or both. Many of decisions standing behind these situations were mine. I’m not proud of it.

    What I can say is I didn’t do it on purpose. I just lacked knowledge. Sometimes I wasn’t even conscious my knowledge was insufficient to make a right call. Sometimes I should try harder or think more. I was, and I am, a clueless manager. I try to fight it but that’s an uphill battle. I have my prejudices and preferences and I don’t claim I’m able to fully ignore them.

    The Bad News

    I’m not the only one. I’m tempted to say that every manager is so because the only ones who would be different must be heartless robots which aren’t great candidates for managers anyway.

    This means you as a manager, and your manager too and her manager and so on, are clueless to some point. Usually more than you’d like to admit. This mean there’s a chance your judgments aren’t fair or your work may be misjudged. And finally this means your subordinates can trick you along with your cluelessness to make you think better about them.

    Managers were, are and will be clueless. We may fight with it but we’re likely to fail. Most of us don’t even try anyway.

  • Testers Shouldn’t Stick to Specs

    Jennifer Bedell wrote recently at PMStudent about testers goldplating projects. Definitely an interesting read. And pretty hot discussion under the post too.

    I’d say the post is written in defense of scope. Jennifer points that testers should test against the specification only because when they step out of the specs it becomes goldplating. In other words quality assurance should verify only whether a product is consistent with requirements.

    That’s utterly wrong.

    It might work if we worked with complete and definite specifications. Unfortunately we don’t. And I mean we don’t ever work one of these. They just don’t exist. What we work with is incomplete vague and ambiguous.

    And yes, you can deliver software which sticks perfectly to specs and at the same time is unusable piece of crap.

    You should actually encourage testers to get out of the box (specifications) and wander free through the application using every weirdest scenario they can think of. Why? Because your beloved users won’t follow specs. They won’t read it. They won’t even care whether there is something called with the name. This is artificial artifact created to make discussion between product manager and developers easier. Users couldn’t care less about specs.

    This means they don’t use application in a way which was specified in requirements, user stories or whatever you happen to create. They use the app using all kinds of approaches, even the weirdest ones. You don’t want to face it unprepared. So forget about damn specs when testing and try everything you can think of (and some of that you can’t).

    I’ll go even further: forget about test cases too if you happen to have them. OK, forget about them during the first iteration of tests, because you have more than one, don’t you? The reason is exactly the same as above.

    And yes, I can imagine some extreme bugs which will be submitted because of this approach. Bugs which would take years to fix and they are so unlikely to appear in real life it would be plain stupid to fix them. This only means you should monitor incoming stream of bugs, hand-pick these few you aren’t going to fix and throw them out.

    This isn’t a reason to consciously decrease quality by sticking to specs during testing.

  • The Kanban Story: Kanban Board Revisited

    Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.

    We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.

    When we left the board last time it looked like that.


    What was the problem?

    On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.

    Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.

    The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.

    After playing with some ideas we came with version 3.0 of our Kanban Board.


    What has changed?

    The left part hasn’t changed at all. We were happy with it.

    The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.

    Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.

    Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.

    Limits

    Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.

    Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.

    The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.

    The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.

    “Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.

    Looks like we get more and more columns over time. I just wonder whether that’s a good thing.

    If you liked the post you may want to read the whole Kanban Story.

  • Fighting with Status Quo

    Last time I wrote about status quo and how it becomes protected value within companies. I could tell you countless stories of people being (mentally) hurt by status quo. I could tell barely a few of these when status quo was defeated.

    How to fight with status quo then?

    A short answer is: change rules of the game. Until new status quo emerges everything will be different.

    To elaborate a bit more, status quo is painful in terms of lost opportunities. Every time some talented and eager engineer hits the glass ceiling or a poor candidate is promoted over a good one or suboptimal organization is sustained the company loses. It loses in terms of productivity, performance and employee satisfaction. At the end it loses money since at the same cost there could be done more or there could be done equally much but at lower cost.

    A good supporting question is: who sees all these problems?

    Everyone who tried to improve something but failed because reluctance of people happy with whatever it is today. That would be one group. Another one will be made of few people who are high enough in organizational structure to see how things work, but at the same time have no real power, or interest, to change it.

    Another supporting question: can these people introduce change?

    No, they don’t. They don’t have enough power. They are either too junior or too new or work too far from the core of the organization. Sometimes they would even try to fight the reality just to learn they have virtually no chance to win. Status quo defenders are numerous and powerful and they prevailed many try-outs like this.

    If you came to this point you can basically do two things:

    • Change behavior of people who defend status quo. To succeed with this you need to open their eyes first. It may be possible but it doesn’t have to. How to do this? Well, bottom-up approach doesn’t work. If it did their attitude would already be different. What you need is someone with respect. Someone who would coach status quo keepers showing them ways of improvement. Make them aware there are different styles of management. Make them aware how they can improve their leadership. Make them aware how much they can personally gain if they enable changes in their teams. If this approach succeeds game rules will start changing slowly but constantly. Unfortunately this would work only when you have managers who were unaware of the problems. If they were consciously maintaining status quo chances are good your efforts would be ignored.
    • Get someone experienced and give her power to change things. It could be one of these peripheral managers but as an insider she would be naturally perceived as an enemy by her colleagues. It’s better to get an outsider, someone who successfully cleaned up a company or two. Hire her and give her enough power to allow her to enforce changes over the current organization. Let the outsider change the rules. If you choose your candidate wisely, you’ll go through a number of clashes, some people will leave, other will be fired but in the end organization will work better. Why? Because every significant change in the company, every leaving, creates opportunities for those who want to improve organization and destroys at least a few glass ceilings. Of course you can rebuild every flawed element you’ve just destroyed but after all one of reasons you have your superhero outsider is to prevent that happening.

    As I write this I’m perfectly aware how rare are cases when companies decide to undertake such actions. But every time I hear about another management failure which is triggered by defending status quo (and believe me I hear that a lot) I have the same thought: “Why won’t you, my dear execs, do anything to heal your organization?”

    I surely am biased but it happens now and then that I believe I have a few recipes which would instantly improve overall performance, let alone some consistent work on fundamentals. After all management isn’t that hard if you have someone to learn from.

  • Big Companies Are The Best… In Maintaining Status Quo

    What happens when company grows from 10 to 100 people?

    Initially there’s a group of highly motivated and hard working people led by one or a couple of visionaries. Everyone knows each other well. Everyone knows what anyone else is doing at the moment. Then some success happens and organization grows. At the beginning it scales up trouble-free. Somewhere along the way teams emerge. Suddenly company needs a few managers. Who is promoted? What a question. Of course those who were in the pack when employee counter was one-digit.

    First hierarchy self-emerges. No one really thinks about this much. After all it’s all about a couple of teams, not full-blown organization. Then the company grows further and by the time it reaches 100 people there are probably at least two levels of management. First managers add new folks to their teams to the point they need middle management to deal with their 30-something people.

    Note: at that point there still isn’t much planning when it comes to organizing company structure. It is created in the meantime while people aren’t focusing on their work.

    What happens when company grows from 100 to 1000 people?

    By the time organization has 100 employees self-emergent structure becomes suboptimal. It is no longer a bunch of people working toward common success. If you don’t hire great candidates only, and let’s face it: you don’t, there are some people on board who just work there and don’t really care for anything beyond their paycheck. There are also few managers who shouldn’t become managers at all but should stick to engineering. To add some spice the company still grows at constant rate.

    The bigger it grows the more power management gets. Execs no longer work with line employees most of the time. They work with excel sheets and if they meet someone they are other execs or senior managers at best. Real power is moved one level down – to managers who make hiring decisions, promote employees and deal with all people-related issues. Who are they? Remember this few veterans who were around from the very beginning and become very first managers in the company? Well, now each of them leads one of multi-team departments with close to 100 pairs of hands each.

    Sure, there are reorganizations but most likely they happen out of the center of the company. Core remains unchanged. Why? Well, that is damn good question.

    A short answer is: because big organizations are great in maintaining status quo. I don’t want to argue whether a few hundred people make a company big (it does not) but somewhere between 100 and 1000 people this attitude appears and it is there for good.

    And here’s a long answer.

    • Think about management skills of early-managers. Most likely it is their first management job. Most likely they were engineers initially. I’ll be brutally honest: chances are good they doesn’t really suit management job. The problem is they don’t even know that. They can’t. They may even do their best and still suck as managers. If they have grown with the company they may lack just good role-models in management. I could bet my money against their management skills in this situation and, on average, I would win.
    • Now, put yourself in shoes of these veterans. They are with the company from the beginning. They career seems to be well-earned. They aren’t aware they may suck at what they do. When they were engineers they had simple verification of their work: test passed, client didn’t complain thus everything was good. With management it isn’t so easy. Their team won’t come to them to say they suck. Hey, you just don’t go to tell such things to your boss. We can even consider managers are aware they suck a bit. And what would they do? Resign to leave a position for someone better? You must be kidding me.
    • So what do execs do with this? Pretty much nothing. They’re chewing through their Excel sheets and as far as numbers are fine everything else is too. And if numbers start to stink who would they talk to anyway? Well, managers I guess. They’re disconnected with most of the rest of people for a long time already.

    Maintaining status quo is a safe choice for everyone who has enough power to make any important decision in the company. Those who see problems and would like to change something are either somewhere on periphery of organization or very low in hierarchy structure. The former aren’t taken seriously the latter hit the glass ceiling.

    What more, existing status quo propels the same behavior all over again. If the company promoted three out of four engineers from early setup to senior management the fourth one pretty much expects the same. And most likely he will get the promotion, no matter whether he was the best candidate or not.

    Of course you can find counterexamples. I don’t say every company works that way. I guess when Google hit 500th employee mark they were still nothing like that. I know startup where all 3 co-founders had experience in management so they aren’t likely to hit this reef either. I know companies which will never make it past 50 people so they definitely shouldn’t care about these issues.

    Anyway more often than not defending status quo is a problem. I’ve seen it at all stages from few dozens to few thousands of people. And it always looks like decision-makers weren’t aware of the fact or, if they were, like they didn’t care. When company grows to specific size it is just easier that way.

    In the next posting I’ll give an idea what can be done to change the situation. Stay tuned.

  • What Makes You a Great Professional

    I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.

    Now a second step – try to name one attribute which is common for each of them. Something which isn’t, by definition, related to specific role or specific job. Depending on variety of people you’ve chosen this can be pretty hard, but try for a while – there must be something. Got it? Great.

    What you’re trying to achieve here is finding a kind of success factor. Something which would differentiate good from great, but at the same time probably not something which would guarantee a mediocre person to become a star. That just isn’t so easy.

    What have you chosen?

    My choice is: urge to learn.

    This is something which constantly pushes us ahead, out of our comfort zone. Even if we err along the way the overall result is positive. As the time passes we get better and better since, well, learning is all about getting better. We grow to the point when someone thinks about us when asked the question from the beginning of this post. We’re not likely to get there though, so chances are good there’s still plenty of room for self-improvement.

    Learning can be a part of your job – in this case you should be pretty happy with it. You can also do a job which doesn’t develop you much at the moment, but it is a lame excuse to stop learning. There are tons of great places to get better at whatever you do or learn something completely new. If you stick with whatever you already know you’re heading to side-track.

    I have great news for you: if you reading this, odds are you have this urge. If you take time to look for content discussing personal development in context of your domain (I don’t expect many dustmen here really) you’re well ahead of the rest of the pack. You’re here to learn something new. Otherwise why would you spend your time reading this?

    If you’ve chosen something else than urge to learn tell me what is your choice and why.