Pawel Brodzinski on Leadership in Technology

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

Tag: agile

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

  • Kanban Basics

    I often say that you can implement Kanban in your team in a single afternoon. That’s how we did that after all. So when Andy Brandt asked me to do Kanban Basics webinar I expected that preparing it would be pretty simple. How long can you talk about few-hour-long task?

    Well, it wasn’t as simple as I expected.

    Kanban itself is very simple. But telling people they should visualize workflow, limit work in progress and measure the flow isn’t really all the basic stuff they need to know. After a while it always ends up with questions how we do this and how we do that.

    What limits should be set on board?
    What happens when a bug is found during testing?
    Should sticky notes be moved back on the board at all?
    How cycle time is measured?
    What happens when the limit is reached?
    What to do when emergency task pops up?
    How to cope with multiple projects?
    Is feature-by-feature deployment mandatory?
    How estimation is done?

    That’s an interesting observation – I often deal with most of these questions at the end of my Kanban presentations, no matter if I cover basic or advanced material. After giving it some thought I decided this would be a good starting point to prepare Kanban Basics presentation.

    What I ended up is presentation below. It covers a bunch of scenarios visualized with (surprise, surprise) Kanban board. Additionally I used Scrum as the reference to make a basic Kanban description easier to understand.

    Kanban Basics

    If you have some basic questions which seem to be omitted in the presentation, please leave a comment. I’d be happy to both answer the questions and update future versions of the presentation.

    If you speak Polish feel free to watch the recording of the webinar.

    Also, check The Kanban Story series as it reveals all the details of Kanban implementation in my current team.

  • How to maintain backlog?

    In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

    However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

    Keep epics, split late

    Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

    Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

    It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

    Groom from time to time

    If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

    Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

    Group features

    There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

    Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

    Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.

  • Agile Isn’t Immune for People Who Don’t Give a Damn

    I like presenting. I just love the fact that every time I deliver the presentation I find something new in there. It’s like having tiny epiphanies while you’re talking to a crowd. And I’m sure I wouldn’t have them if I didn’t overcome my fears and didn’t start speaking publicly.

    A thing which hit me last time I was delivering my Kanban Story presentation was how fragile agile is in terms of people who don’t give a damn. In the summary of presentation I make a point that Kanban may not be for your team if you work with undisciplined engineers.

    But what I realized while I was talking it is not only about lack of discipline. It’s about care. In Kanban people have to care about Kanban board. They have to move cards as they progress with features. They can’t abuse limits unless it is agreed among the team and team rules allow to. They should think how they could improve the board. They should keep the board up to date.

    Why it is so important? Because the board is single most important information radiator in Kanban teams. If contents of Kanban board are random you spread random information about project among the team and outside the team. You pretty much misinform everyone around. And now the important thing:

    In Kanban teams anyone can easily abuse Kanban board.

    It’s enough someone doesn’t care. He doesn’t care to move cards through the board or put his marker on task he’s working on at the moment or ignore transition criteria or whatever. Suddenly you have random Kanban board and no systemic tools to deal with the issue. People versus Kanban 1:0 at halftime. If you want to know how the match ends, well, you’ll have to read the blog in future since it is a subject for another post.

    It’s already half of A4 page and I haven’t really mentioned agile in general. Only Kanban. Kanban this and Kanban that. Don’t I have something else to say? Well, I do, thanks for bearing with me so far.

    One of reasons why Kanban is so easily abused by people who don’t give a damn is the fact that Kanban prescribes close to nothing. But enough of K-word. Scrum is more formal. Actually Scrum is pretty formal approach if you ask me. How it deals with the problem?

    A bit better. Stand-ups, time-boxing and planning meetings are all practices which help to deal with undisciplined team members. (I wanted to write “engineers” instead of “team members” but I’ve just recalled there are no roles in Scrum besides Scrum Master, Product Owner and Team Member and I prefer not to be killed by some Scrum extremist.) With these practices it is easier to make someone stick to convert folks who don’t care. If you work with Scrum you can’t work without time-boxing while the rest of the team has 2-week long sprints. You are asked the same questions as everyone else during stand-ups. There is more of a stick in Scrum than in Kanban. (Have I just said K-word?)

    XP goes even further. Rules are surrounding you everywhere, my poor engineer. It almost tells you how to pee. Not in pairs. fortunately If you work with XP and you don’t give a damn you’re probably already fired.

    But let’s face it – how many teams out there use eXtreme Programming religiously? Few. More of them follow just a couple of engineering techniques choosing Scrum as their process base. And even then we have whole variety of Scrumbuts, Scrumbans and Scrumwhatevers.

    Average agile approach in real world, if there happen to be something like that, would cover a very limited number of rules. I’d say that there would be less of them than Scrum proposes. And even then rules are often softened or teams choose those which are less painful to adapt.

    So we come back to the first point. The fewer constraints (aka enforced practices) we have in place the more easily our process can be abused by people who don’t give a damn. If your method base on a lot of common understanding instead of tons of process documentations and a number of strict rules buying all people in becomes crucial. Having few rules means that you give people power to create and adjust your software development/project management approach.

    It also means you give them power to destroy and harm it.

    If you like this post you should thank Michal who took the discussion up on Twitter.

  • Which Engineering Practices You Should Use

    XP is a “software development through the eyes of an engineer” kind of methodology. It focuses heavily on engineering practices.

    On contrary, neither Scrum nor Kanban seems to care much about best software development practices. But wait, if you read about Kanban a bit you’ll quickly find an advice to focus on your engineering practices too as Kanban (or Scrum) alone is not enough.

    Actually I can’t recall any project management approach which says “when it comes to code, do whatever – this whole programming thing doesn’t really matter.”

    So we’re back here again – a set of best software development practices is important. Yet, there is plenty of them, how to choose the right ones?

    You may choose a set of tools you believe are most valuable. However if you don’t have comfort of choosing toolbox first and then looking for people who are familiar with tools (or at least willing to learn how to wield them) you’re likely to fail.

    Every change is difficult and developers tend to be pretty stubborn. Yes, they will do this whole code review if they really have to, what a big deal anyway, but don’t expect to get decent results unless developers believe it is a valuable technique. They will hate it probably as much as filling data in time tracking app, which isn’t even close to what you wanted to achieve, right?

    And this brings me to another approach: let engineers choose which engineering practices they want to employ. Let them argue. Let them look for consensus. Help them in facilitating discussion if it’s necessary but don’t enforce any specific technique. Throw in a few ideas but if they don’t catch up don’t try to use your magic power: “I can force you to do so.” If you’re a team leader or (even worse) a manager it’s not you who will be doing this darn thing every single day for next couple of years so just shut up, OK?

    The best set of engineering practices is the one which will be adopted by engineers. And yes, this means it will be changing over time. The more mature the team is the more practices people are able to adopt.

    The same rule works in other areas too. Product management? Well, don’t you have a product owner or something? Let her decide. Testing procedures? Shouldn’t you agree to whatever your QA guys want?

    When it comes to discussion on standards a manager should take a step back and let a decision to be made by people who will be affected.

    There’s one trick here however. If you happen to work with inexperienced or just average people the consensus may be “let’s just hack some code instead of wasting time on this stuff, we’re Cowboy Coding Wizards and nothing can beat our code.” But then you have a bigger problem than deciding which of best practices your team would use. You better start to evangelize your team a bit or look for another job, whichever looks easier.

    There’s another trick too. What to do if you have hundreds or thousands of developers? Well, different toolboxes should emerge in different teams and it would be pretty stupid to try to standardize all of them. “What if nothing emerges despite a multiple teams working on software development?” you may ask. Well, running away while screaming would be a pretty good option there I guess.

    You didn’t really expect to see here The Big List of the Best Engineering Practices Every Team Should Adopt, do you?

  • The Kanban Story: Kanban Alone Is Not Enough

    Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.

    I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.

    What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.

    We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.

    All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.

    So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.

    Read the whole Kanban Story.

    If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.

  • The Kanban Story: The Beginning

    So I found myself in this small team, part of a bigger company but working pretty independent of the rest of people here. Kind of start-upish environment. I knew every single person I worked with. Well, actually I’d chosen most of them and hired them here. The team was great (if you guys are reading this: no, it is not a reason to come for a raise) and personally I didn’t feel an urge to strictly control everything. On the other hand some order is always a nice thing.

    Initially I gave a lot of thought to project management practices and didn’t come with a solution I was happy with.

    I rejected PMP-based heavy-weight process which works for many projects in the organization. We didn’t need all the hassle they bring. At least not at that stage. A natural idea was Scrum which I didn’t like either. Scrum is pretty formalized methodology too and I wanted to avoid formalisms as much as possible. Actually with a lot of R&D work, pretty much prototyping and priorities changing all the time I needed something more flexible.

    I didn’t want to be time-boxed since we were planning to work simultaneously on a few independent small projects which would be hard to synchronize if we wanted to put them all in one team-wide sprint. Creating independent sprints for each of projects was a complete overkill since you don’t really need Scrum sprint for a one-and-a-half-person project.

    Actually I’d say we were at the point where we were too flexible for agile methods. Now, go burn me in flames for being iconoclast.

    After some discussions we collectively agreed we wouldn’t adopt Scrum as a whole but would use some of techniques used there and some other ideas we thought were good. In the next post in the series you’ll find more details how we initially organized our development.

    Keep an eye on the whole story.

  • There Is No Single Flavor of Agile

    Agile is such a capacious term. Under the flag of agile we do different things. Scrum is agile. And XP is agile. Scrum-in-the-name-only is also agile. We go with no plan whatsoever and that’s so damn agile is agile too.

    Yes, you say the first two are true agile and others are fakes just tainting The Holy Agile Name. That reminds me… wasn’t it exactly the same with waterfall and others bad, bad techniques? Wasn’t they tainted by poor implementations which got everything wrong so we had to come with new better methods? Well, just a food for thought.

    Coming back to agile. With all these good and bad implementations I can safely say that there’s no single flavor of agile. There never was. I believe it was never intended to be the only one. I recently read notes on the writing of the agile manifesto by Alistair Cockburn and one thing stuck with me:

    “I came in through the doorway marked “Efficiency” not the doorway marked “Change” – because my background was in fixed-price fixed-scope projects. (…) Other people came to agile through the doorway marked “Change”, and that’s fine for them.

    So although agile gets billed most of time through Kent Beck’s “Embrace Change” moniker, I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking.”

    Different experiences, different projects, different backgrounds. Different accents when talking about the Manifesto. I can’t say I haven’t expected that at all but still. There was never one universal interpretation of agile principles yet we see every now and then people selling the only right and proper method of being agile. How come?

    On a side note: I wrote this piece a few days ago. In the meantime The Big Ugly Change came and kicked my ass big time. “The world will supply enough change requests.” Couldn’t agree more these days.