Pawel Brodzinski on Leadership in Technology

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

Tag: agile

  • Agile Self-Organization: Band-Aid for a Broken Leg

    One of the concepts that has been widely popularized by Agile movement is self-organization of teams. It lands very nicely in any Agile context, no matter the discussed method or even a general approach one might have to Agile implementations.

    It is, after all, an idea that appeals to line employees and managers alike. Let’s give atomic teams power to decide how they would work within safe constraints. Safe here means safe for managers, of course. In one swift move we address, at least to some point, two issues. One, we increase empowerment across team members as they get more say over how they work. Two, we remove managerial burden of work organization at a the most detailed level, at which managers’ competence can frequently be challenged.

    All but the most micromanagerial types should be satisfied.

    Since how the work gets done is decided closer to where it actually gets done, we increase odds of good processes and policies. At the same time, through more autonomy we improve motivation and engagement.

    It’s not without a reason that self-organization at a team level got its way into common practice.

    History of Agile (Oversimplified)

    The starting point for self-organization as a technique or a practice is not unlike other agile practices. Early Agile methods were focused on a team. The perspective might have differed, but the atomic entity in consideration was always a team. Be it Scrum, XP, Kanban or anything else, in their early forms there was little mention on interoperability across teams either horizontally or vertically.

    Obviously, once Agile got traction there was a need for scaling the approach up. Initially, some makeshift approaches were being made to do that (anyone remembers Scrum of Scrums?). Eventually, whole methods were built to enable large scale Agile implementations—SAFes and LeSSes of this world.

    These approaches were built around a core method, typically Scrum, and took good parts of other methods whenever authors saw fit. Fundamentally, the value added of these methods was in a description how to roll everything out in a big organization. The desired outcome would be to see the core method implemented in multiple teams while ensuring some level of alignment across an organization.

    It was about scaling up the method and not scaling up the principles behind. It was about getting more Scrum / Kanban / whatever teams in an organization and not figuring out how the basic values and principles would have to work if they were applied on different levels of an organization.

    That’s exactly when we petrified self-organization as a technique relevant to a team and a team only.

    The Broken Leg

    Let’s look at the problem we are solving with self-organization. We give people autonomy and they organize work better as they are most knowledgeable how the work can be done optimally. At the same time, since we distribute autonomy, we increase motivation and engagement.

    So far, so good. I can’t help but ask: are these problems exclusive to the lowest levels of organizations, i.e. atomic teams, or are they more endemic?

    There’s no reason to think that the disease isn’t wide-spread. After all, for a century we are perpetuating Taylor’s and Ford’s ideas of separating the workforce from workflow design. It doesn’t happen on the factory floor only but throughout the whole hierarchy. A higher rank designs how lower rank works and what is expected of them. It is, in fact, the hierarchy itself that discourages us to distribute autonomy more than absolutely necessary.

    What we are looking at is not just a marginal problem of line employees going shallow into the higher ranks. The injury is not a scratch but a broken leg.

    The Band-Aid

    Despite how widespread the disease is the solution we have is far from enough: self-organization… but just at a team level. It is exactly the proverbial band-aid for a broken leg. It does the work, i.e. stop the bleeding, but only as long as the injury is skin-deep.

    We know it’s not the case.

    And yet we keep curing our broken organizational leg with just more band-aids of atomic teams embracing more autonomy. At the same time, we don’t address the structural problem of lack of autonomy throughout the hierarchy.

    There lies the root cause of the problem. Working only on the lowest possible level, i.e. teams, we already have hard constraints of how far we can go with autonomy (and it’s not far really). Unless we start working on self-organization systematically, we won’t get much long-term effect in an organization. It would be just one more band-aid.

    The Cure

    We got principles missing when we were figuring out how to scale Agile up. Interestingly enough, it had long been figured out in the military. Even more curious, the problem had been solved with tangible practices and not with some vague aspirations. The difference is that the military practices were designed as scalable from the very beginning.

    Take briefing and debriefing as an example. It is a pair of activities of sharing the goals and the context (the orders) by an officer to a unit and having the unit brief back to the officer what they understood. The goal of briefing and debriefing is for any rank to make sure that: a) a lower rank unit understands the goal (the purpose) of a higher rank officer and one rank above, and b) a lower rank unit understood correctly what was briefed.

    Such a practice is rank-agnostic. It can be applied at any level of a hierarchy without any specific adjustments. It is entirely not so with Agile self-organization practices that were immersed in 7 plus or minus 2 people as a definition of a team.

    If we aspire to see organizational transformations that would be an equivalent of turnaround of some of our teams, we need to reinvent self-organization. Autonomy distribution must become either a rank-agnostic practice or it has to have dedicated solutions for each organizational level.

    The former, while much harder to design and implement, is potentially much more applicable. It is the domain where tools such as decision making process, open salaries, or inclusive hiring process reside. The meta pattern here is that by default any decision is made after collective advisory process and at a lower level that it would have been made otherwise.

    I acknowledge that these examples may sound radical. They are, indeed. And yet adjusting them to a softer form is straightforward. It doesn’t have to be that anyone can decide about anyone else’s salary. It can be that anyone can decide about anyone else’s salary within their team and in accordance with budget constraints. What matters is that the decision is made at a lower level (a team mate and not a manager) and the whole team is invited to take part in the process.

    Such a change won’t happen overnight. Even in a small organization it likely requires years and not months to implement. However, unless there is a motion toward that direction, we are just paying lip service to self-organization and apply more band aid to broken legs.

  • Scaling Up Is Not the Only Option

    There is one thing that seems to be present in pretty much every company strategy these days. Given the opportunity, they want to grow. Obviously not every organization is successful at that but scaling up is treated as a default option and a universally desired goal.

    In fact, it is sometimes assumed so obvious that it doesn’t even gets discussed. One example was a recent discussion on preserving culture (see comments too). The post that initiated the whole thing seems to assume that the growth is a fixed part of the equation.

    An interesting thing happens when I mention scaling up strategy that we have at Lunar Logic, which is: don’t. All those blank stares and questions like “why would you pass an opportunity to grow?” Interestingly enough ceasing to grow means that we have to pass on some potential projects. This makes the whole discussion even more interesting.

    An issue we forget is that scaling up doesn’t come for free and the biggest cost of growth is how it affects organizational culture. Given that the current culture is something one values, preserving the important parts of it during growth is extremely difficult. If we are talking about rapid growth it’s basically impossible.

    If you happen to be in a place where the culture is a cornerstone of your success, which is exactly our case at Lunar, you may want to rethink whether scaling up is an obvious, or even desired, choice.

    Nevertheless a story I keep hearing over and over again about different organizations is “we’ve been doing so great so far that we decided that we want to grow by 100% in a year.” The trick is that when they succeed they will likely be a very different organization. Different values will be shared across the group. Different behaviors will be treated as a norm. Different way of work will be considered a standard. It will be a different culture altogether.

    It is likely that the very things that made them successful in the first place will be gone by then lost in rush to get bigger.

    Obviously there’s only that many things one can do with couple dozen people but then decision about growth is typically made without considering all side effects.

    And by the way, while I keep focusing on culture, as it is most vulnerable, there’s much more than that. One of the catchy themes these days is scaling Agile. Obviously part of the story is rolling out Agile in the context of big organizations. Another part though is maintaining all the value that we get thanks to using agile approach once we grow. While this is doable it adds to complexity of all the processes and the whole system.

    It’s not without a reason that smallest organizations tend to be the most efficient and as they grow they tend to spend more and more effort trying to comply with their internal and artificial processes.

    So why not dodge the bullet and keep an organization small? While I don’t say it has to be a default option it’s definitely an option to consider.

    It changes the whole equation as suddenly you are incentivized to say no. No, we won’t take this project as we are fully booked. No, we won’t jump on that candidate even though she seems to be pretty good. Suddenly, we have higher standards for work we do and people we hire.

    The focus is not on “more and more” but on “better and better.” Wouldn’t that be a nice option to consider?

  • Hyperproductivity Myth

    If you are in broadly understood context of Agile you eventually has had to hear about being hyperproductive. Sources reporting a few hundred, or even as much as more than a thousand, percent productivity improvement aren’t unusual. In fact, 200% improvement seems to be “guaranteed” by some.

    That’s great! Good for them! They’re going to get hyperproductivity badge or something. Yay!

    What Hyperproductivity Is

    Let’s start with the basics though. What is this whole thing? When a team becomes hyperproductive? How much do they have to improve? Oh, and by the way, if a super-crappy team improves three times and guys that were already great only by 20% would that mean that hyperproductivity was reached by the former, the latter, or both?

    The most common metric I hear about in the context of hyperproductivity is velocity. Actually, I consider using velocity to measure productivity evil or dumb. How much should my team improve? By the factor of three? Nothing easier. Oh, and by the way, we don’t use our estimation poker card worth 1 that often anymore.

    Note: I don’t deny teams improve. I merely point that stating so purely on a basis of velocity improvement is naive at best. There are so many potential dysfunctions of such approach that I don’t even know where to start. How the scope of work is split into individual tasks? What is a distribution of point estimates? How has it changed over time? What do we understand as a task in the first place? How do we account for rework?

    In other words without understanding a specific context mentioning hyperproductivity is meaningless. Just a marketing fad, which it might have been in the first place.

    Efficiency As a Goal

    Even if we agreed on a reasonable proxy for measuring productivity there’s a bigger problem ahead. We are not in a business of writing most code, delivering most features or achieving best velocity. If you think you are, go talk to your clients, but this time try to actually listen to them.

    If you spend about 5 minutes looking for sources pointing how notorious software industry is in not building the right stuff you may change your mind. Is a half of the stuff we build utterly useless? How about two third? Oh, and by the way the rise of the methods that are literally aimed to avoid building things unless we know we’re going to need them tells a story as well.

    So yeah, focus purely on productivity and you’re going to achieve your goal:

    Processing waste more effectively is cheaper, neater, faster waste.

    Stephen Parry

    The most painful problem of software industry is not efficiency. If it was, we’d already be in haven, given how much easier it is to build a software app these days than it was a couple decades ago. The problem is we are building wrong stuff.

    We may as well be efficient, but unless we are effective in the first place, i.e. doing the right thing, there’s no glory waiting for us.

    How We Create Value

    This brings me to the utter failure of pursuing hyperproductivity. Let’s (safely) assume that our goal is to deliver value to our clients. We do that by building stuff. Except the value almost never is clearly defined. In almost every case software development is a knowledge discovery process.

    This has some serious consequences. If we go by this assumption we may take all the functional specifications with a tongue in a cheek. It’s just a sketch of a map and most of the time not even an accurate sketch. This also means that amount of artifacts, like code, features, etc., we produce is not nearly as important as figuring out where exactly the value is, which bits and pieces we should build and which should be ignored.

    This happens when we discuss the features, look for solutions, research options, prototype, A/B test, change stuff back and forth to see what works. This happens when we don’t score on velocity or any other productivity metric.

    But wait, to become hyperproductive we should rather avoid that…

    That’s exactly why I don’t give a damn about hyperproductivity.

    I use to say software development is a happiness industry. We thrive only as long as our clients are continuously happy. We don’t make them happy by delivering more stuff. We make them happy by delivering stuff that has value for them and their customers.

  • Unscaling Agile

    A theme of scaling Agile, or Lean for that matter, is all hot these days. You will hear it all sorts of contexts: as broad as Agile and as specific as one of the methods we use. No wonder. It sells.

    You can tell that looking at tracks at Agile or Lean conferences. You can tell that looking at a rise of approaches that specifically aim at the big scale as their main target (SAFe, anyone?)

    The interesting part of the whole dispute is how rarely we question scaling up strategy. I mean it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.

    How does it work for us so far? Not so well. We don’t have lots of success stories and those few that are available seem to be share at pretty much every Agile or Lean event there is. This tells a story about our success rates with scaling agile too.

    Unscaling strategies are almost never mentioned in the dispute. It is so despite the fact that we actually know at least a couple of different approaches we can use there.

    One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.

    Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.

    Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.

    Interestingly enough, such approaches are rare. One exception may be outsourcing. However, outsourcing done in a common way has nothing to do with scaling down and very frequently criteria used to choose an outsourcing partner only make the whole situation worse. Believe me, I’m actually in this business on a receiving end so I’ve heard all the motivations for sending the work near-shore or off-shore.

    If you wonder why unscaling is so unpopular you aren’t going to be surprised with the answers. Either of these scenarios means losing control and that is something that management is generally allergic to. Also to make it work you need trust as high autonomy is one of key parts of the setup. Finally, there’s a risk of doing something not exactly in a standardized way which may produce unpredictable outcomes.

    Have I just said between the lines that one of the main drivers of scaling up Agile and Lean is complacency? Oh well…

    Anyway, unscaling strategy not only makes it much easier to adopt Lean or Agile but at the same time it enables fresh ideas as many constraints are typically relieved. Not to mention that it goes along the lines of autonomy, mastery and purpose which drives individual motivation.

    So the next time you hear about scaling Agile why not consider unscaling it?

  • Why Your Change Program Will Fail

    Most change initiatives fail. How many of them? Well, let’s see.

    In 1995, John Kotter published research that revealed only 30 percent of change programs are successful. Fast forward to 2008. A recent McKinsey & Company survey of business executives indicates that the percent of change programs that are a success today is… still 30%

    This is from a McKinsey report. How about different sources?

    According to international management consultants Bain & Co, 70 to 90 per cent of organizational change initiatives fail.

    Now, obviously these statistics receive some criticism. After all, what is a change initiative? What is a success? My point is that what we see is that in different context we suck big time at improving how we work.

    What’s more we are not improving really. Over the course of past 15 years we’ve seen a huge rise of the methods and approaches that are specifically aimed toward driving the change management.

    Agile proposed a neat value container quickly filled with specific methods that should change and improve the way we work. Lean offered a thinking pattern focused on continuous improvements. Both are more and more frequently considered table stakes than game changers. Why nothing is changing then?

    First, let me make a bold observation: neither Agile nor Lean seem to be making a difference. In fact, that’s not only my observation. Daniel Mezick points that:

    If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility.

    We have to be doing something wrong. Dave Nicolette offers some ideas what that might be. Anyway with such a wild popularity of Agile and Lean we should expect to do better than that. The problem is that most of the time we don’t even try to understand what made them work in the first place.

    That’s a sad observation, but most of the time when I hear an Agile or Lean experience report it simply covers methods, practices and tools. The problem is that neither of these is pivotal in any change initiative. Basically, adopting practices and tools is simply a cargo cult. That’s not going to work unless there’s something more, the same way as it didn’t work for the Pacific tribes after the World War II.

    In agile context we often mention values as the missing bit. I sort of agree with that. Sort of because the way Agile Manifesto is formulated it creates false dichotomies, yet it points us the right direction.

    There’s a problem with values though. You don’t introduce values simply stating that you have them. You don’t incept them through mission statements and stuff. By the way, do any of you know value statement of your org by heart? Values are derivative of everyone’s behaviors and attitudes, thus they are a result of organizational culture.

    There’s one more layer to that. Values can’t be inconsistent with the culture. Otherwise authenticity is gone and your claims about values have little to do with reality.

    In other words a company can’t adopt Agile Manifesto simply by stating so. Not a surprise that change initiatives around Agile so frequently boil down to methods and tools. Not a surprise they fail at a high rate.

    We see the same story with Lean as well. The bits that get traction are tools and techniques. It is so often when I see teams acting like limiting work in process, doing Gemba walks and having Kaizen boards was everything there was to improve continuously.

    It’s not going to fly, sorry. We are back to organizational culture and everyone’s everyday behaviors. What do people do when they see an issue? Do they feel empowered to do whatever the hell they believe is the right thing to do to fix that issue? Do they even know what is the ultimate value they produce so they get good guidance on what is an issue in the first place?

    These behaviors tell a lot about the culture. Unfortunately most of the time answers for the questions above suggest that there’s no freaking chance to make the tools work the way we intend them to. Typically we see over-constrained, siloed organizations where one neither knows what is the right thing to do nor has courage to go beyond the constraints.

    I keep getting flak for bringing this up over and over again but I will do it once more.

    It’s easier to ask forgiveness than it is to get permission.

    Grace Hopper

    Grace Hopper’s famous words are, in my opinion, the essence of the bit we are missing when introducing Lean or Agile to our organizations. That very bit is responsible for the appalling rate of success of change initiatives.

    You can have all the hot tools and practices in place but when your people are driven by fear of consequences of their actions nothing will change. “Fear” may sound harsh but that’s what it is. It doesn’t mean that changing status quo by a tiny bit scares the crap out of me. It’s enough that I start thinking about potential consequences, what my bosses would think about that and whether they would even be happy. This is fear too.

    When I think about the situation from a perspective of my experience as a manager I’m not surprised. I mean, really, promoting this whole “don’t ask permission” attitude is going to backfire on you on occasions. What’s more it means giving up control. Even worse, it assumes trust. It assumes trust to everyone, not only to few trusted people. Now, this is a huge leap of faith management has to take.

    If you are thinking about continuous improvement or making your change initiatives work start with this leap of faith. If you can’t make it work don’t bother with all the tools, methods, practices and stuff. It’ll be just a waste of time. And the best part is that to make this work leaders have to start with themselves.

    Only then you can dream of influencing culture so that it supports the everyday acts of leadership on all levels. If you got it right you may actually start thinking about all the helpful stuff you can introduce to keep the changes running. In fact, it’s pretty likely that you won’t need so much guidance as lots of them will emerge.

    Oh, and if you wonder whether that change among leaders and managers is easy, well, it involves lots of pain and suffering. It is against of what we’ve been (wrongfully) taught for years. Sorry.

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

  • On Feedback

    I’m not a native English speaker, which basically means my English is far from perfect. Not a surprise, eh? Anyway, it happens sometimes when one of natives I’m talking with corrects me or specifically points one of mistakes I keep making.

    And I’m really thankful for that.

    I’m thankful most of the time such feedback happens instantly so I can refer to the mistake and at least try to correct it somehow.

    This is what happened recently when one of my friends pointed one of pronunciation mistakes I keep making. It worked. It did because feedback loop was short. It worked even better because it was critical feedback. I didn’t get support for all the words I pronounce correctly. It was just a short message: “you’re doing this wrong.”

    Of course it is my thing to decide whether I want to do something about this. Nevertheless I can hardly think of positive feedback I could receive that would be that helpful.

    When you think about this, it is contradictory to what we often hear about delivering feedback. It isn’t uncommon that we are thought how we should focus on positives because this is how we “build” people and not “destroy” them. Even more, delivering positive feedback is way more pleasant and for most people easier as well. It is tempting to avoid the critical part.

    When we are on feedback loops I have one obvious association. Agile in its core is about feedback loops, and short ones. We have iterations so we deliver working software fast and receive feedback from clients. Or even better, we have steady flow so we don’t wait till the end of sprint to get this knowledge about the very next feature we complete. We build (and possibly deploy too) continuously so we know whether what we’ve build is even working. And of course we have unit tests that tell us how our code works against predefined criteria.

    It is all about feedback loops, right?

    Of course we expect to learn that whatever we’ve built is the thing clients wanted, our code hasn’t broken the build and all the tests are green. However, on occasion, something will be less than perfect. A feature will work not exactly the way a client expected, a build will explode, a bunch of tests will go red or pronunciation of a word will be creepy.

    Are we offended by this feedback?

    Didn’t think so. What more, it helps us improve. It is timely, specific and… critical. So why, oh why are we that reluctant to share critical feedback?

    It would be way more harmful strategy to wait long before closing a feedback loop, no matter what the feedback is. Would it really tell you something if I pointed you this two-line change in code you did 4 months ago, that broke a couple of unit tests? Meaningless, isn’t it? By the way: this is why I don’t fancy performance reviews, even though I see the point of doing them in specific environments.

    Whenever you think of sharing feedback with people think about feedback you get from your build process or tests – it doesn’t matter that much whether it is positive or critical; what makes the difference is the fact it is quick and factual.

    You can hardly go wrong with timely and factual feedback, no matter whether it is supportive or not.

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

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

  • Scrum versus Kanban

    These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

    Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

    Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

    The point

    From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

    Team model and software development process

    Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

    Scrum proposes pretty damn good team model and process for building software.

    If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

    On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

    Kanban doesn’t propose any specific team model or software development approach.

    It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

    The difference

    When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

    Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

    The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

    Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

    Help you get

    You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

    Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

    Which one is better

    Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

    If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

    After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

    Final thought

    If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

    After all, this post is big and hairy so I guess I succeeded with the task anyway.

    Advertisement: Protect your business from a surprise software audit with License Dashboard.