Author: Pawel Brodzinski

  • No Meeting Culture

    Meetings are boring. Most meetings are irrelevant. There are too many meetings we have to attend.

    A confession: during past half of year I organized exactly two meetings with engineers in my team. Both were mostly about organizational issues regarding whole company, not just my team.

    How did I do that?

    Let’s start with why meetings are organized. Most of the time meetings happen to enable communication between people. Why don’t people just go to meet each other at their desks? Well, because they sit in different places, have different things to do and, often, have little free slots in their calendars. Sometimes they need to prepare themselves to say something reasonable and invitation to the meeting gives them time for that.

    Basically all these reasons become non-existent when whole team sits in one place.

    You don’t have to busily gather people from different places because, surprise, surprise, everyone is there.

    You don’t have to wander what people do at the moment since, well, you just see it in a glimpse. You can make your call whether it’s a good time to interrupt them at the moment or you should wait for a quarter.

    You don’t feel urge to finish in planned time slot even when the discussion is great and you’re solving problems like crazy. Neither do you feel this funny feeling when everything was said but no one hurries back to work and you just spend your time on chit chat because a meeting room is reserved for another half an hour.

    You can even allow starting talking with folks on subjects they aren’t prepared to. You can because whenever they need to prepare they’ll tell it and a discussion will be restarted later. This is like instantly starting a meeting instead of sending invitations. Odds are everyone is ready and you don’t waste time. If they are not it works similarly to invitation with agenda but better since you start meeting as soon as everyone’s ready.

    You should still think how improve transparency and communication flow but, believe me, once you start talking about almost everything in front of your team, even though you’re talking with a person next desk, people will know way more than they would otherwise. It would work that way even if you reported all your workweek on 4-hour long weekly summary with your team, which would be a candidate for the top dumb management practice of a year by the way.

    And the best thing. With this approach you magically clear everyone’s calendar. Finding slot when everyone is free becomes the easiest thing under the sun because everyone basically stopped attending meetings.

    A cherry on the cake: finding free conference room doesn’t bother you anymore.

    Downsides?

    It won’t work for 50 people. As far as teams aren’t bigger than 10 people it should do well. Vast majority of teams fall in to this category. Sometimes you need to focus and you don’t care about architecture discussion happening over your desk. You can take a break or try to isolate yourself with headphones. Either way it is a cost, but on average it’s significantly lower than it would be if you switched for old-school meeting approach.

    This applies only to team-related meetings. If your people have a lot of cross-team meetings and spend long hours on company-wide roundups filled with jabber this doesn’t have to be huge improvement. But then you’re doomed anyway. One of my engineers attended a few meetings on coding standards beyond these two I organized.

    The approach works best for engineers. Project managers and business people will meet other people more often that once per quarter but it should be still an order of magnitude meetings less than it used to be.

    I wouldn’t get this kind of crazy idea but it happened so my whole team is collocated and it’s the best organizational thing which could happen. If you think it’s drastic, you’re wrong. Meetingless environment comes naturally. Maybe it so because this way you possibly are all time at the meeting, but at the same time you “meet” people only when it’s really needed.

    Try it. And tell me what happens.

  • The Kanban Story: A Discovery of Kanban

    In the last chapter: A small team was built and they tried to set up a methodology for building their projects. After establishing a set of techniques and trying them against first couple of projects they faced a list of issues. They realized they needed something more. How would they deal with the problem? What would be their choice?

    When I read Henrik Kniberg’s article Kanban vs Scrum it was first time when I thought I get the whole idea. I even thought it might work for our team but if you know me a bit you know I’m very reluctant to drop anything we’re currently doing just to try out this new cool idea I’ve read about yesterday. This is by the way the most important reasons why a few engineers with great potential I know will never fulfill this potential. They just can’t hold their horses whenever they read about new jazzy technology. And it doesn’t really matter whether it does any sense to implement it.

    Anyway I finally decided to give Kanban a try since I believed it would solve both of our main problems. First Kanban limits work in progress (WIP) by design. Second having open backlog where I could put any incoming idea should help me with dealing with all different threads happening around our group and at the same time I should be able keep modifying priorities pretty easily.

    What more, Kanban shouldn’t put on us much of constraints which would be invited by most of other methodologies. As lightweight as possible, as little bureaucracy as possible. Kanban suited well.

    I checked team’s opinion about starting something new which would help us. When I described Kanban and prompted for feedback I got green light although I can’t say they were enthusiastic whatsoever.

    A decision was made.

    Read the whole Kanban Story.

  • Co-location Rules!

    A lot of interesting discussions today. During one of them we went through co-location and its influence of team productivity.

    I’m lucky enough to work with all my team in one room. I’m aware of all disadvantages of grouping people doing different things in one place but I’m still saying I’m lucky.

    I know development requires focus. I know that grouping a bunch of people in one place generates some chit-chat which distracts people trying to focus on their tasks. I know occasional phone calls do the same. I accept the fact. Hey, have I just said I accept lower productivity of our developers? Bad, bad manager.

    I know most people would consider a private office as a huge improvement from open-space. I wouldn’t offer that to my people even if I had a chance to make them this kind of offer. Ops, I’ve just admitted I wouldn’t make my people happier even if I could. How come?

    It just about trade-offs. While putting people together invites costly context switching because of distractions it also brings huge values in terms of team work.

    • Instant problem solving. It’s enough one person to ask another one about some issue to see insightful discussion emerging virtually instantly. You don’t need to think whether PM should join since he’s here and he joins as soon as subject appears interesting for him. Solving problems as you go is much more efficient.

    • Communication improvement. Communication issues are probably number one issue when it comes to visiting dead-ends, doing the same job twice or banging the wall hard with your head. When I think how much effort is wasted just because a couple of people didn’t talk with each other I believe every method which improves communication is worth considering and most of them are worth implementing. Co-locating people is one the most efficient choices here.

    • Reducing number of meetings. Many meetings aren’t even needed. However they’re scheduled because they’re considered as the easiest way of communication between more than two people from different rooms. Remove walls and you’ll automatically remove many meetings. People will have more time to do the real work.

    • Atmosphere building. Try to cheer up person who sit next to you. Tell a joke or something. Succeeded? Great. Now do the same with the person sitting on other floor. It takes walking and other tiring physical activities. It’s harder. You won’t do it so often.

    • Getting to know people. You’ll know better a person after sitting with her in one room for a month than after working in different locations for a year.

    And yes, I believe these compensate reduced productivity and happiness. Actually not only compensate but add more too. Net value is positive. That’s why co-location rules.

  • The Kanban Story: First Issues

    So we were doing great, everyone was happy and we were delivering on time on budget and on scope. Except it wasn’t exactly how things really looked like.

    First two projects were late. Not much but still. It was expected since these were our first estimates in the team and at that time we decided not to do anything about that yet. Slips were reasonably small, which was a good sign when we talk about our developers’ estimation skills. Nothing to be worried about.

    Another issue however appeared to be a real pain in the ass. One of applications got stuck somewhere in the middle of first iteration of tests. It looked like there was always something more important to do. Everyone was doing high-priority things and the application wasn’t touched even with a stick. There was no mechanism which would add an incentive to finish things and not leave even less-important tasks for later.

    We also had a problem with our Product Owner. The guy was trying to catch many parallel threads and organize team’s work but unfortunately he was pushing in a bit too many new things. At the same time he was losing some of nice ideas on the way. Before some of them could be implemented guy was coming back from another meeting with a client bringing new, better and higher-priority tasks and the old ones were fading into oblivion. For those of you who can’t wait to ask who this crappy Product Owner was the answer is: yes, it was me.

    A general conclusion was we need some more organization not at project level but at team level. Something which would help us finishing things and limit chaos generated by rapidly changing business environment. Specific of our team was we were doing a number of very small projects simultaneously so coordinating these projects was crucial to avoid falling into chaos.

    We were about to do first process improvements…

    Read the whole story.

  • The Kanban Story: Initial Methodology

    You already know how our team looked like and what concerns I had with implementing plain old Scrum. You also know we chose “take this from here and take that from there” kind of approach to running our projects. Our base method was Scrum but we were far, far away from accepting it the orthodox way.

    What we finally agreed on within the team can be described in several rules:

    1. Planning
    For each application at the beginning we were deciding what we want to see there in the next version. We were trying to limit a number of features but didn’t set any limits how long development should take. The longest cycle was something between three and four weeks.

    2. Requirements
    When we’d known what we wanted to do we were creating user stories and non-functional requirements. Each session took whole team, even when someone wasn’t going to develop that specific application. As it usually happens the scope was being changed as we discussed different aspects of planned work. We were adding (more often) or cutting off (less often) features. We were building a coarse-grained architecture as we discussed non-functional requirements. At the end of the day we had a whiteboard full of stories which were a starting point for development.

    3. Tasks
    Since user stories were rather big we were splitting them to smaller pieces – development tasks. This was changing view from feature-wise to code-wise. Development tasks were intended as small pieces of work (possibly not bigger than 16-hour long) which were a complete wholes from a developer’s point of view. Ideally a single user story should have several tasks connected to it and single development task should be connected with only one user story or non-functional requirement. It wasn’t a strict rule however and sometimes we had many-to-many relation since specific changes in architecture (single development task) were affecting many usage scenarios (many user stories). Development tasks should make as much sense as possible for developers so they were defined by developers themselves and by those who were going to do the job. Tasks were stored in a system which was used company-wide.

    4. Estimation
    At the very beginning we had no strict deadlines but we were estimating anyway. There were two goals: learn to estimate better when there aren’t huge consequences for being wrong and getting into a habit of estimating all of planned work. Our estimates were done against developer tasks, not user stories. The main reason why we went this way was that tasks were smaller so estimates naturally were better than they would be if we did them against user stories. A specific, pretty non-agile, thing we were doing with estimation was a rule of estimating each task by a developer who would be doing it. More on this in one of future posts.

    5. Measuring progress and work done
    Current progress could be verified by checking actual state of tasks connected with a specific app. Nothing fancy here. The thing which was important here was writing down how much time it took to complete the task. When completed each task had two values – estimated time needed to complete the task and time it really took to do it. At the end of the day we knew how much our estimates were flawed. The important thing here was official announcement that no one is going to be punished in any way for poor estimates.

    That was pretty much all. No stand-ups since we were all sitting in one room and we discussed issues and work progress whenever someone felt like it. No Scrum Master since, well, we weren’t doing sprints and within specific project things were rather self-organized. A kind of Product Owner emerged, impersonated by me, as we needed a connector between constantly changing business environment and the team working on different projects. You could say we needed one to bring some chaos to our work which would be equally true.

    We were going to build a few small projects that way. At the same time we were prepared to improve the way we create our software as soon as notice flaws and find a way to fix them.

    Keep an eye on the whole Kanban Story.

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

  • The Kanban Story

    My current team works with Kanban for some time already. For all of us this is a kind of experiment on live organism. Ongoing experiment. That’s what led me to an idea of The Kanban Story – a set of posts which are a logbook of our cruise with Kanban.

    The story has its beginning and several chapters since some things already happened since we started our friendship with Kanban. There’s no end however. I don’t know what we’re going to end up with but I’m going to share with you all ups and downs which we encounter along the road.

    Hopefully this will become a kind of manual which helps with other Kanban implementations and generally with your work on projects and teams.

    Technically it would work as pretty much every series on this blog – I will publish new chapter of The Kanban Story every week or so and you’d be able to find links all of them which are already published below since this post will be updated every time new post in series appears on Software Project Management.

    1. The Beginning
    2. Initial Methodology
    3. First Issues
    4. Discovery of Kanban
    5. Implementation of Kanban
    6. Kanban Board
    7. What We Do And What We Don’t Do
    8. Kanban Board Evolution
    9. Kanban Alone Is Not Enough
    10. I Don’t Know, Experiment
    11. Throwing Sticky Notes Out
    12. Pseudo Iterations
    13. Kanban Board Revisited
    14. Kanban Boosters
    15. Measuring Lead Time
    16. Coarse-Grained Estimation
    17. Swarming
    18. When and Why We Abuse Limits
    19. Small Tricks Do the Job
    20. Moving Cards Back
    21. Retrospectives
    22. Standard-Sized Features
    23. Skipping Part of Process
    24. Kanban Board Should Reflect the Reality
  • Technical Leadership and People Management

    The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

    They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

    Well, actually it is not.

    Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

    Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

    On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

    That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

    Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

    You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

  • Random Thoughts on Estimation

    A lot of discussion on estimation recently. A lot of great arguments but a lot of good old mistakes we’ve already went through. This brought me to a few random thoughts on estimating techniques.

    1. Estimation technique which involves discussion between different people is better than one which just simply uses their estimates as input.
    2. Using factual recorded historical data is better than basing just on experience.
    3. Smaller tasks can be estimated way better than big chunks of work.
    4. Every estimate starts with some kind of guess at the very beginning.

    I know these should be obvious yet I’m surprised how often people:
    – forget about them
    – deny these are true

    Then they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real estimation.

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