Pawel Brodzinski on Leadership in Technology

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

Tag: software business

  • Against Rightshifting

    Rightshifting is a nice idea. In its origin it says about improving effectiveness of organizations. When an organization rightshifts it becomes aware of different approaches, methods and techniques that can be used to work better. Eventually, the company adopts some of them and starts treating them as non-optional. Oftentimes, it means that the organization refuses to work “the old ways” as it is clearly considered suboptimal.

    I do like to think about rightshifting in terms of personal development. Every one of us can (arguably should) learn new approaches, methods and techniques. With such an attitude we eventually learn how to work better. Oftentimes, we’d love to reject to work differently, on occasions we even do, although this time the case is more complex.

    Being a part of a bigger entity, we rarely have comfort do fully decide how work is being done. If you ever heard “do we really need to write unit tests (a client won’t pay for this)” discussion you know exactly what I mean.

    What happens then? Well, usually we develop our frustrations regarding lack of workmanship. Some leave in pursuit to find another job that suits better their expectations and skills. Some stay and try to change the organization from the inside. Sometimes they even succeed, although more often a success is local (a team level) than global (an organization level). Anyway, besides these rare successful cases usually much frustration is involved.

    Bad news is that a scenario involving frustration is a frequent one when we personally rightshift. More often than not, the pace of our personal improvements is better than the one of organizational improvements. On one hand it means that personal rightshifting introduces at least some dissatisfaction. On the other it should open new opportunities.

    Yes, of course. The problem is that there are fewer and fewer of them, the further to the “right” you are. There aren’t enough great companies, or I should say mature enough companies. I mean, maybe there are, globally. But few of us operate on a fully global job market and jobs in general, and jobs at great companies specifically, aren’t distributed evenly across the world.

    So sorry, in most places on earth “there’s no shortage of talent, only a shortage of companies that talent wants to work for” isn’t true. Even less so, when one has high expectations for craftsmanship and organizational standards.

    In other words, in theory, you can rightshift yourself to the point where you’re practically unemployable because you aren’t willing to accept anything but your impossible-to-meet standards of work. I’m pretty sure it’s not only theory and quite a few folks out there could tell by their own experience.

    I know by mine that definitely the more to the “right” you are the fewer companies you want to work for.

    So my advice would be: don’t rightshift… too fast.

    Be aware that rightshifting closes a few options here and there. Rapid rightshifting may close the option you’re exploiting at the moment too (also known as a current job). I wouldn’t call rightshifting a career-limiting move, although in some ways it might be considered this way.

    Is it different when we look from a perspective of an organization? A bit. When the company rightshifts faster than individuals working there, there is frustration too. However, people tend to adjust to the way their company works. After all, it is one of conclusion that may be drawn from famous Deming’s work (95% of variability is caused by the system). In other words, improving the system (the organization) we naturally pull people to the “right” too. Most of them at least.

    Unfortunately, raising standards means that there are fewer people that you’re willing to hire. It limits company’s pace of growth. It makes hiring people’s work way more difficult. Of course you can always fall back to good old growing people from basics but you can afford to have only that many of them.

    So again, don’t rightshift… too fast.

  • On Transparency

    One of things I’ve learned throughout my career is to assume very little and expect to learn very much whenever changing a job. In terms of learning, there always is a great lesson waiting there for you, no matter what kind of an organization you’re joining. If you happen to join a crappy org this is the least you can salvage; If you join a great one, it’s like a cherry on a cake. Either way, you should always aim to learn this lesson.

    But why am I telling you this? Well, I have joined Lunar Logic very recently. From what I could say before, the company was a kick-ass Ruby on Rails development shop with a very open and straightforward culture. I didn’t even try to assume much more.

    One thing hasn’t been a surprise; We really are a kick-ass Rails development shop. The other has been a surprise though. I mean, I expected transparency within Lunar Logic, but its level is just stunning. In a positive way of course.

    An open discussion about monthly financials, which obviously are public? Fair enough. Questioning the value of running a specific project? Perfectly OK. Sharing critical opinions on a leader’s decisions? Encouraged. Regular lean coffees where every employee can come up with any subject, even one that would be considered embarrassing in almost any organization I can think of? You’re welcome. I can hardly come up with an example of a taboo topic. In all this, and let me stress this, everyone gets honest and straightforward answers.

    Does it mean that the company is easier to lead? Um, no. One needs to think about each and every decision because it will be shared with everyone. Each piece of information should be handled as it was public. After all, it is public. So basically your goal, as a leader of such an organization, is to be fair, whatever you do. There’s no place for deception, trickery or lies.

    One could think that, assuming goodwill, it is a default mode of running a company. It’s not. It’s very unusual to hear about, let alone work at, such an org. There are a number of implications of this approach.

    • It is challenging for leaders. You can’t hide behind “that’s not for you to know” answer or meaningless blah blah. People won’t buy it. This is, by the way probably, the number one reason why this approach is so uncommon.
    • It helps to build trust between people. Dramatically. I don’t say you get trust for free, because it never happens, but it is way easier.
    • It eliminates us versus them mentality. Sure, not everyone is equal and not everyone has the same role in the company, but transparency makes everyone understand better everyone else’s contributions, thus eliminates many sources of potential conflicts.
    • It heavily influences relationships with customers. It’s much easier to be open and honest with clients if this is exactly what you do every day internally. I know companies that wouldn’t treat this one as a plus, but being a client, well, ask yourself what kind of a vendor you’d like to work with.

    All in all, transparency is like a health-meter of an organizational culture. I don’t say that it automatically means that the org is successful, too. You can have a great culture and still go out of business. I just say that if you’re looking for a great place to work, transparency should be very, very high on a list of qualities you value. Possibly on the very top of the list, like it is in my case.

    By the way, if you are a manager or a company leader, ask yourself: how many things wouldn’t you reveal to your team?

    This post wouldn’t be complete without giving credits to Paul Klipp, who is the creator of this unusual organizational culture. I can say that during first few weeks I’ve already learned more about building great teams and exceptional organizations from Paul than from any leader I worked with throughout my career. It goes way beyond just a transparency bit but that’s a completely different story. Or rather a few of them. Do expect me to share them soon.

  • Why Organizational Transformations Fail

    You can’t reorganize the way a business thinks by reorganizing the business.

    ~Stephen Parry

    I can safely state that every company I worked for was attempting to make an organizational transition during my time there. Motivations varied from simply surviving, through adjusting to a new environment, to improving the whole business. Approaches to run a transition also differed, but one common part was a reorganization.

    Oh, reorganizations. Who doesn’t love reorgs? Shaking everyone around. Bringing in good old insecurity and fear of unknown. Quite an interesting strategy to introduce a positive change, although the one which is most prevalent and often inevitable. Unfortunately, a strategy that has a pretty low success rate too.

    After all, coffee doesn’t become sweeter simply because you stir it.

    The interesting part, however, is that I can come up with an example or two in which reorganizations helped to make a transition a success, or even make it possible in the first place.

    How come? The answer is hidden in Stephen Parry’s words at the beginning of the post. It’s not about the reorganization itself; it’s about changing the way business thinks. The problem with most reorgs is that they’re driven from the top, which usually means that the top of hierarchy remains the same. It also means that the way business thinks, which spreads top-down, remains unchanged.

    If the organization’s leaders’ mindset remains the same, any change that is introduced down there isn’t sustainable. Eventually, it will be reverted. Depending on how many layers of isolation there are it may take some time but it’s inevitable. Prevailing mindset just goes top-down and unless you can address its source it’s a battle you’re not going to win.

    I can think of, and have been a part of, reorganizations that shook the very top of a company, introducing new leaders and thus enabling the new way of thinking. Yes, the business was reorganized but this was neither the only nor the most important part of the change.

    Because coffee doesn’t become sweeter simply because you stir it. Unless you’ve remembered to add sugar before, that is.

    The game-changer here is mindset; that has to change in order to enable the successful transition. And I have bad news for you: it has to change at the very top of the organization. You don’t necessarily have to start there, but eventually it either happens or things, in general, remain the same.

    So if you consider a reorg as a way to change how your business works, ask yourself a question: does this change affect the mindset of the organization’s leaders? If not, I wouldn’t expect much chance of success.

    Besides, there are many ways to skin a cat. A reorg isn’t the only tool you have to change mindset across the organization. Heck, it isn’t even a very good one. Remember that when you start the next revolution just to see that virtually nothing changes as a result.

    By the way, there is a neat application of this idea in a bit different situation too. If you want to preserve mindset across the organization when changing leaders, pay very close attention how new leaders think. Your company can be a well-oiled machine, but when steering wheel is grabbed by a guy who neither understands nor cares about the existing mindset, the situation is going to deteriorate pretty quickly. You just don’t want to hire Steve Balmer to substitute for Bill Gates.

  • Is a ScrumMaster of Any Value?

    Tobias Mayer, who I respect very much, recently put his thoughts about ScrumMasters into a blog post. The post that can be summarized best by its title: Delete [ScrumMasters]. The strongest point of the post goes as follows:

    “I believe the concept of ScrumMaster has done more damage to our industry than it has aided in change. It has been a way for individuals and organizations to jump on the Agile band wagon, in a mostly painless way (discounting severe certification costs) and continue to do much as they were doing before.”

    It isn’t a surprise for me that the post gained a lot of traction. Many experienced leaders in our community have quickly supported Tobias’ crusade.

    I haven’t.

    I agree with vast majority of what Tobias has written. I like the diagnosis he makes. I even believe we should be told such things by our thought-leaders. Yet I don’t jump on the bandwagon of spreading the epiphany: we don’t need ScrumMasters anymore.

    One of stories that instantly pops into my head whenever I hear about the role of ScrumMaster is the one John Cieslik-Bridgen, who used to be a ScrumMaster at Lunar Logic, shared with me once:

    “We were doing a “design your ideal team” exercise. In this exercise, I liked the fact that I wasn’t referred to as a ScrumMaster, rather ‘a John’, as in, “we’ll need ‘a John’”. I think the use of the word “coach” much better reflects what I try to do.”

    On a side note: I’d love to have “a John” as a title on my business card someday. After all, many teams need a John.

    By this point you may wonder, which part of Tobias’ post I haven’t understood, as the story is totally aligned with the article. Well, I have understood the post. John’s story, however, is just one side of the coin.

    The other is that few organizations are mature enough to hire, or promote, a John. Conversely, many companies lose their Johns, these great coaches and counselors, because they don’t have a named place for them. What’s more, organizations often need some kind of framework to even allow a role of a John. This framework very often happens to be Scrum and the role is called ScrumMaster.

    I don’t say it is a magic pill that solves every problem in an organization. I just say this step is often very helpful in moving to the next level for both the org and for a John.

    And yes, I can think of other, arguably better, means to an end of organizational and personal improvement, but I find this one working surprisingly often. To quote Tobias once more: “Sorry guys, it’s what I see.”

    I actually see much value if a John blossoms and eventually leaves the organization because it just scratches the surface and doesn’t really introduce agile values. At the end of the day we still have one more great guy on the job market.

    While I agree with the argument that the ScrumMaster role is often abused and I don’t really like how it is defined, I still consider it one of the valuable options for organizations. The option that may end in preservation of status quo, but also in creating a space for people who will take the org to the next level.

    Does it mean we should throw away the role as a whole? Well, in mature organizations, where there is a good understanding of the reasons that ScrumMasters were introduced and what they are supposed to do, I see no reason to cultivate the role or the title.

    On the other hand I still see the ScrumMaster role as a tool that can create space for change agents (I hate this name too) and catalyze improvements. After all, would there be a John without a ScrumMaster first?

    Have I just written a post in defense of the ScrumMaster role? Oh well…

  • Scott Berkun on Consultants and Practitioners

    Continuing the discussion on differing perspectives of consultants and practitioners, I have asked Scott Berkun a few questions on the subject. I chose Scott because for the past few months he has been coping with both options: while publishing his next book – Mindfire: Big Ideas for curious Minds – he spent a year and a half having something like a regular job at WordPress.com.

    Not only was I curious about Scott’s views on the subject but also I think we can learn a lot from him, especially those of us who are considering coupling both roles. So here are a few gems of knowledge gleened from Scott.

    Scott, you’ve recently left Automattic where you worked for some time and it has triggered me to ask you a few questions about your spell there. The difference between insider versus outsider or practitioner versus consultant perspective is something that draws my interest for some time already. You’ve decided to try living both lives concurrently and it gives you a unique perspective on a subject.

    Reading your blog and your tweets over time, my impression is that your enthusiasm for having a regular job while pursuing your career as a writer and a consultant was diminishing. Was that only an impression or there is something more to it?

    The plan was always to stay at WordPress.com for about a year. It’s a great place to work and it was hard to leave. Any complaining I did was probably just to help convince myself I needed to leave, which was hard to do as I enjoyed it so much. I stayed there for 18 months, 6 months longer than I’d planned.

    What was the biggest challenge of having two so different careers at the same time?

    Having two careers sucks. I don’t recommend it. My success in writing depends on full commitment. I can write books because I have no excuses not to. I succeed by focus. It’s the primary thing I’m supposed to do. Having two jobs divided my energy and I don’t have the discipline needed to make up for the gap. It also changed my free time. I noticed immediately the amount of reading I did dropped dramatically. I used to read about a book every week or so. That dropped to a book every few months. Having two jobs meant my brain demanded idle time which came at the expense of reading. I felt like I was working all the time, which isn’t healthy for anyone.

    And what was your biggest lesson from this time?

    The next book is about my experience working at WordPress.com and what I learned will be well documented there. Professionally I learned creating culture is the most powerful thing a leader does, and WordPress.com has done that exceedingly well.

    Do you think that coupling consultancy and a regular job is doable in the long run?

    I don’t know why anyone would want to work that much in the same field, honestly. For anyone who thinks I’m good at managing teams, or writing books, a huge reason why is the other interests and experiences I’ve had in my life that have nothing to do with leadership or software or writing.

    Do you plan to get another job at some time in future again? Why?

    As long as I’m paid to speak to people who are leaders and managers, it’s wise for me to periodically go back to working in an organization where I’m leading and managing people. It forced me to test how much of my own advice I actually practice, and refreshed my memory on what the real challenges are. Any guru or expert who hasn’t done the thing they’re lecturing others about in years should have their credibility questioned. I figure once a decade or so it’s a necessary exercise for any guru with integrity.

    Why we should consider moving to (or staying in) a consultancy role?

    When I first quit to be on my own I did a lot of consulting. As soon as the books started doing well and I had more requests to speak, I did less and less of it. I do it rarely now. Consultancy can be liberating as you are called in to play a specific role on a short time frame. If you like playing that specific role and like change (since who you work with changes with each new project), consultancy can make you happy. It pays well if you are well known enough to find clients.

    Why we should consider moving to (or staying in) regular jobs?

    Consultants rarely have much impact. Advice is easy to ignore. Consulting can be frustrating and empty for the consultant, even if you are paid well. Anyone serious about ideas and making great things knows they have to have their own skin in the game to achieve a dream. You can’t do that from the consulting sidelines. In a regular job at least there is the pretense of ownership. Everyone should be an entrepreneur at least once in their life: you can only discover what you are capable of, or not, when you free yourself from the constraints of other people.

  • Practitioner versus Consultant

    Whenever I’m acting as a coach, a facilitator or a consultant for a team there’s one thing that struck me every time – how much being a practitioner helps me in performing in the role. And when I say a practitioner I think about doing similar work as the teams do on a daily basis, and not only coaching, consulting or facilitating. It’s like doing my regular stuff except it is a bit different. But then, I’m solving similar problems every day, am I not?

    Personally, I could imagine myself being full-time consultant, although I believe I’d lose something this way. On one hand full-time consultants are exposed to more different environments as, well, this is what they do – they visit different organizations and work with them. On the other, consultants come, consultants go – most of the time they don’t hang around to see the final results of their work. After all it isn’t their responsibility to make the change stick.

    However, when I think about consultant versus practitioner perspective the biggest thing that still keeps me on practitioner’s side of the fence is fear of disconnection. At this moment whenever I’m “selling” you something it is likely verified in the organization I work (or have worked) for. Been there, seen that, done that. You can trust me.

    It’s not that I read this trendy book or my company is selling training of that method. It’s not that I spent much time on conferences listening to all those published authors, thought-leaders and whatnot who are extremely knowledgeable but are also long gone from real jobs, you know, the ones that produce something tangible.

    I really touch the crap. And live with it. So whenever I’m wrong there’s no one else but me to clean up the mess.

    So what I’m thinking about here are two things. One question is for consultants that are reading the blog (I know there are quite a few of you): how are you coping with the issue of disconnection? Or maybe it is just non-issue?

    Another question would be for those of you who are considering hiring some help to sort things out in your organization: would you prefer a consultant or a practitioner and why?

    I’d be glad to hear as many voices as possible, so if you are considering commenting the post but not really sure, please do – you’ll earn my infinite gratitude. And you definitely want it because it is exchangeable for a beer when you meet me.

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

  • Kanban Leadership Retreat

    I spent last few days at Kanban Leadership Retreat. An original David Anderson’s idea was to gather in one place thought-leaders working on Kanban and provide them a platform to exchange experience, ideas and thoughts. I must say it kinda scratched my ego in its back to be invited.

    Anyway I’m still impressed how great the event went. I mean, I know that gathering some great minds in one place and giving them free beer (one evening only, but still) is a sure-shot recipe for a stunning success. To be honest, I did have high expectations. Basically all of them were exceeded.

    As the retreat worked as unconference vast majority of sessions ended up as discussions. There was little-to-none pre-prepared content which was both good and bad. It was good because it really enabled a lot of good discussions and thought exchange but there were moments when I’d appreciate a bit of structure, which is naturally brought by standard presentations.

    Personally I’d also prefer to see sessions a bit more focused on real-life stories than on meta-level but I guess expectations on this one differed.

    Anyway, volume of mind-blowing ideas I’m still trying to think through was astonishingly high. After all, what could you have expected after inviting all those though-leaders, and I take the word “leader” very seriously here, to the same place? By the way: you can definitely expect some of those ideas shared here in near future.

    Actually I went to the retreat with a goal to discuss a few of them: portfolio-level Kanban, Kanban failures and methods of selling Kanban to teams and organizations. Lucky me, each of them have made it to the event program. And basically each of the sessions looked totally different than I’d projected. This basically means I got a new, and unexpected, perspective on ideas I’d already had which, by the way, might make attending my future sessions on Kanban way more valuable, if you excuse this shameful plug.

    But all in all it wasn’t the content which was the most valuable for me. People were. I always say that networking is the most important part of any event but this time it was totally on steroids. The format of unconference, the choice of people and never-ending Icelandic days made it the ultimate networking event. If, by any chance, I looked as a child in chocolate factory please forgive me – I had damn good reasons to look so.

    I should probably mention all great folks I was talking to, which would be kind of boring for people who weren’t there, so I’ll refrain (BTW: if somebody is curious please check people I recently followed on Twitter). But if you are the one of them I’d like to genuinely thank you for all the stuff I learned from you.

    Huge thanks for organizing the whole thing goes to David Anderson and his staff along with Hillel Glazer, who facilitated the event.

    Personally I will be there next year. That’s no-brainer for me. If any of you, by any chance, is invited you shouldn’t hesitate whether it is a good idea to go even for a second.

  • Good Waterfall Is Better Than Bad Agile

    Lech brought an interesting subject recently: isn’t running an R&D project with heavy-weight, structured approach extremely difficult?

    We use to think that we need very flexible approaches for projects which aren’t defined very well, thus agile being frequently a tool of choice for R&D projects, which bear a lot of unknowns by definition. After all can you really produce reliable plan for a research project? It is research; you don’t really know what you’re going to end up with.

    But we fall in the trap of simplifying things. When we think about heavy-weight approach to project management we instantly see BDUF waterfall project with no checkpoints on the way carried through without taking changing conditions into consideration. Yes, there are still a lot of projects done this way but this isn’t the only way of running projects non-agile way.

    The trick with R&D projects is that you wander through unknown areas. It doesn’t mean you can’t plan you journey though. It doesn’t mean you can’t assess your progress and change your course along the way. It doesn’t mean you can’t measure where exactly you are or compare that against expectations which were set up front.

    What more, to some point agile, when done well, enforces us to do exactly that. But then every reasonable approach, no matter whether it’s heavy- or light-weight, does the same. We can have inspect-and-adapt attitude with pretty much any project management approach used these days.

    The real problem is we often misuse tools we have. Project management methodologies aren’t an exception here. When we fail to apply our project management approach reasonable it doesn’t really matter which one we choose – the result will always be poor.

    So my answer for the problem from the beginning of the post is: as long as your project management approach is well-organized and reasonable your R&D project will go well. It doesn’t matter much whether the method is heavy- or light-weight. However if you fail to apply the approach right way don’t expect much of success in your project even if the label on you’re a tool of your choice says “agile.”

    In other words good waterfall is better than bad agile.

    Since I expect “but good agile is better than good waterfall, especially for R&D projects” kind of argument I’ll answer it up front: it depends. It depends on many factors, starting with your domain, going through organizational culture and ending with people you work with. And yes, we can discuss each case separately.