Software estimation. Ah, a never-ending story. Chances are good that, whenever you’re talking about building software, this subject will pop up soon. You can be pretty sure that basically everyone around has problems with estimation or simply struggles with it. And that’s virtually obvious that there would be a new sexy method of estimation every year or so. The method which is claimed to solve an unsolvable puzzle.

Recently there was yet another question on estimation on Project Management StackExchange. This sole fact isn’t probably worth writing a whole blog post about that, but there was one side thread which is worth focusing at.

One of advices I shared was that whenever you can you should avoid estimation at all. This sprung sort of objection. OK, so the subject definitely is worth wider discussion.

First things first. Why do we estimate at all in the first place? Well, we usually want to know how much time it’s going to take to build this damn thing, don’t we? Um, have I just said “usually?” Meaning, “not always?” Actually yes. It’s not that rare when we either don’t need any estimate at all or we just want to have a general insight whether the project will be built in hours, days, weeks, months or years. In either of these cases just a coarse-grained wild-ass guess should be fine. If it’s needed at all.

OK, but what about majority of cases when we need some kind of real estimate? For example all those fixed price projects where estimates are basically a part of risk management, as the better the estimate is the smaller are chances that the project goes under water. I can’t deny that we need to have something better than wild-ass guess then.

Yet, we still can avoid estimating quite often.

Let me start with one of obvious things about estimation: if you base on historical data, and you apply them in a reasonable way of course, you can significantly improve your estimates. In other words, no matter the method, if you are just guessing how much something is going to take, you will likely to end up with way worse results when compared to a method, which uses your track record. And yes, I just dared to name planning poker “guessing.” It is collective, involves discussion, etc but usually it is just this: guessing.

Cool, let’s use historical data then. What’s next? My next question would be: how precise must your estimates be? Seriously, what kind of precision you aim for? My point is that we need very precise estimates very rarely. This is by the way the reason why I don’t use Evidence Based Scheduling anymore.

Anyway, ask yourself a question: how much you would pay for bringing your estimates to the next level of precision. Think of it like being correct in terms of estimating in years, months, weeks, days, hours, etc. Let’s take just an average several-month-long, fixed-priced type of project.

If I’m wrong with years I’m totally screwed, thus I’d pay significant part of project budget to be correct on such level. If I’m wrong with months it might be a hit on our reputation and also it may consume our whole profit we get of the project, so I’d be ready to invest something around the profit to be correct with months. Now weeks. Well, a week here, a week there, does it make such a difference in this kind of project? Can’t I just assume there is some variability here? Unless of course our deadlines are written in stone, e.g. you adjust your software to law changes. In most cases I’d invest just a handful of bucks here at best. Days? Hours? Are you kidding? Does it even make a difference that I spend a day more on such project?

Now you know what kind of precision you expect from your estimates. Would it be possible for you to come up with estimates of such precision basing purely on historical data? I mean, can’t you just come up with a simple algorithm which automatically produces results reasonable enough that you can forget about all the effort spent on estimation?

Whenever we come to discussing estimation I like to share the story from one of my teams: basing on a fact that we were collecting data on our cycle times and we reduced variability in task sizes coming up with the idea of standard-sized features we were able to do a very good job with estimates not estimating at all. We were simply breaking work down so we could learn how many features there are to build and then we were using very simple metrics basing on our track record to come up with the numbers our sales department requested. By the way: a funny thing is, almost all of that appeared as an emergent behavior – something we started doing as a part of continuous improvement initiative.

Either way, even though we were capable of providing reasonably precise and reliable estimates we didn’t really estimate. I was surprised how easy it was to get rid of estimation, but then I can come back to the point from the beginning of the article: what is the point of estimation? You don’t do it just for the sake of performing the task; you do it for a reason. As long as you achieve your goal, does the method really matter? It means that you can get rid of estimating even if you do need some kind of estimates.

In my story from Lean Kanban Central Europe 2011 I promised I will elaborate more on my session there, titled Kanban Weak Spots. The starting point to the session was analysis of a number of situations where Kanban didn’t really work, finding out a root cause and then trying to build a bunch recurring patterns from that.

By the way I have an interesting observation. Whenever I called for Kanban failure stories I heard almost perfect silence as an answer. It seems everyone is so damn good with adopting Kanban that it virtually never fails.

Except I’ve personally seen a bunch of failed Kanban implementations. Either I’m the most unlucky person in the world and saw all of Kanban failures out there or for some reason we, the Kanban crowd, are still sharing just success stories and not putting enough attention to our failures.

Actually, when I was discussing the session with fellow presenters we quickly came to the point that basically every time we think about Kanban failures it can be boiled down to people. However, and it is one of recurring lessons from lkce11, we should address vast majority of ineffectiveness to the system, not to the people. In other words, yes, Kanban fails because of people, but we change the system and only this way we influence people behavior.

This is exactly the short version of the presentation, inspired by Katherine Kirk and Bob Marshall.

There is the long version too. Symptoms, which show you that something isn’t working, and if you do nothing about them you’re basically asking for failure. I have good news though. Most of the time you will look for these symptoms in just one place – on your Kanban board.

Probably the most common issue I see among Kanban teams is not keeping the board up to date. In short, it means that the board doesn’t reflect the reality and your team is making their everyday project decisions basing on a lie. A very simple example: given that there is a bottleneck in testing but it isn’t shown on a Kanban board, a developer would come to the board to see what’s next and they would decide to start building a new feature instead of helping to sort bottleneck out. Instead of making things better they would make them even worse, thanks to the board which isn’t up to date.

I face the same problem but on a different level, whenever a team tries to make a board showing the way they’d like to work, and not the way they really work. Actually this one is even worse – not only do you make your everyday decisions basing on a lie again but it’s also more difficult to get things back on the right track again. This time it’s not enough to update the sticky notes – you need to fix the design of the board too.

Another board-related issue would be forgetting about a good old rule: KISS. When people learn all these nice tricks they can use on their boards they’re inclined to use a lot of them. Often way too many. They end up over-engineering the board, which means that they bury important information under the pile of meaningless data. Soon, people aren’t able to tell what means what and which visual represent which situation. Eventually, they stop to care to update the board because they’re basically lost, so they’re back to the square one.

Violating limits has its own place in hell. Of course it is a matter of your policies whether you allow abusing limits at all. However it is pretty common situation that it is generally acceptable that limits are violated very often, or even all the time. Now, let me stress this: limits in Kanban are the fuel of improvements; if you don’t treat your limits seriously you don’t treat improvement seriously either. Limiting work in progress is a mechanism, which makes people act differently than they normally would. When a developer, instead of starting to build another feature, goes to help with a blocker in testing it is usually because limits told them so. Eventually they learn to predict such situations and act even earlier, before they fill up the work queue. Anyway it all starts with simple actions, which are triggered by limiting WIP.

The interesting thing is that all these problems can be seen on a Kanban board. The reason is pretty simple: the board should reflect the reality, no matter how sad the reality is. You deal with lousy process the same way as you deal with alcoholism: the first step is admitting you have a problem. Even if your process looks like a piece of crap show it on your Kanban board. Otherwise you’re just cheating yourself and you aren’t even starting your journey with continuous evolution toward perfection.

There is however one driver of Kanban failure, which won’t be seen on a Kanban board. It’s also my recent pet peeve. Treating Kanban as a project management or a software development approach is basically begging for failure. It is asking Kanban to deal with something which it wasn’t designed for. It’s using a banana to hammer a nail. Seems funny indeed, but if you care about a success, well, then good luck – you’re going to need a lot of it.

Kanban can be called change management approach or process-driving tool or even improvement vehicle but it doesn’t say a word on how you should manage your projects or build your software. If you don’t build Kanban on a top of something, be it a set of best engineering practices or project management method of your choice, you’re likely to fail miserably. And then you will be telling everyone that you need to have experienced team to start using Kanban and that it wouldn’t work otherwise.

So here it is – a handful of risks you should take into consideration whenever adopting Kanban in your team. A bunch of situations observed by the most unlucky guy in the world, who actually sees Kanban failures on occasions. However, what I want to achieve with this post is not to discourage you to try Kanban out. Pretty much the opposite. I want you to think of this list and actively work to avoid the traps. I just want you to succeed.

And this is why you will hear me writing and speaking about Kanban weak spots again.

Now, even though I teased much of the content from my lkce11 session above, here are my slides.

By the way, if you happened to be on my session in Munich please rate it.

If you’d like to see some more content on the subject, fear not. As I’m very passionate about that I will definitely write more on this soon.

The next agile conference has just ended. Was it worthwhile? Well, a general answer is positive, although I can’t say everything was perfectly fine.

Evolution of Conferences

When we are on a general level let me start with an impression I have and which is supported over and over again this year. Thinking about conferences I see a tendency to make them more local, which is both good and bad. I mean it is definitely more convenient for people to attend an event which is close and is priced similarly to other events in the region. It also seems that the event will be more affordable as many attendees won’t need to travel and pay for hotel.

On the other hand it means we have more and more events and the calendar becomes pretty crowded. Having more events also means that it is harder to find one where a speaker lineup is exceptional. After all pretty few, if any, agile or project management thought leaders could live of public speaking, so they end up choosing carefully where they will present. Thus, statistically speaking, we end up having speaker roster sort of watered down. Anyway, it seems this trend is here to stay, so we should appreciate even more such mind-blowing events as lkce11.

Dates

Coming back to abe2011, it is yet another example showing the trend. First of all, the dates. I mean adding yet another event, and a brand new one, in September or October… You just can’t think of worse time. You already can go to the tour over the Europe during these months and probably there wouldn’t be a single week of without an agile conference. Actually you wouldn’t even have to travel over the whole continent. And I don’t buy the argument that closer to the end of the year weather in Poland is crappy. I mean do we attend conferences to catch some sunlight or something?

Speakers

When I was announcing the event I was very positive about the choice of speakers, but now I think there were a few of not-so-stunning performances, just to be delicate. On the other hand there are more and more of speakers I know who are predictable in a sense that you can safely guess what kind of performance they’re going to deliver. I guess after being on the board of a couple of events choosing right speakers becomes kind of easier. Usually second year lineup is better than the one from the virgin edition too.

All in all, in terms of presentation quality AgileByExample was OK. I really liked Jutta Eckstein’s session on distributed teams, whole Product Owners slot (Marcin Maciejewski, Inbar Oren and especially Monika Konieczny, as her session was real fun) and how Pawel Lipinski tackled the subject of estimation even though I’m sort of confused when it comes to what point Pawel was trying to make exactly. From a perspective of a presenter I enjoyed my presentation as well, although, from what I’ve heard, my enthusiasm to Kanban was misinterpreted by some, so that they thought I propose Kanban as a silver bullet (which I obviously don’t). Anyway, if you were at the session I kindly ask you to rate it and leave feedback.

On a side note: as my session triggered kind of hot dispute I will write more on the subject soon.

Networking

When I was inviting you to AgileByExample I wrote: “If for nothing else consider attending #abe2011 for networking.” And if I’d made only a single good prediction it would have been the one. Networking on the event virtually ruled. The venue worked great in terms of enabling conversations and a decision to make the evening party in the venue instead of somewhere in the city was terrific. I went to bed at 3 am with a head full of stories people shared with me, which is highly appreciated since it is exactly what fuels my future presentations. Thank you guys! Hope to see you again soon.

Organization

Talking about the venue, it was… um… uncommon. If you expect all the comfort hotel gives, you wouldn’t like it but it definitely had its climate and for me personally it was a refreshing change. There was enough coffee, food was fine, wifi just worked, there were (almost) enough plugs and a back row for laptop users. No reasons to complain. I regret a bit that hosts didn’t plan any prize for the most active twitter user because it would definitely go to me.

Format

AgileByExample is another event which follows the format which I first saw on ACE Conference, which means there is a single track and all sessions are limited to 30 minutes. I’ve already told you that but it’s worth repeating: this format works astonishingly well and I say it from both perspectives: as a speaker and as an attendee.

As a speaker I have a room full of people, which is always appreciated, and I have a chance to seed my ideas even in heads of people who weren’t super-interested in the subject in the first place. If I do a good job, that is. Since in Poland Kanban is still sort of new concept it is important for me.

As an attendee I don’t have dilemmas where to go but I’m also exposed to subjects which I wouldn’t choose otherwise. Of course if you end up on crappy session you don’t have other options to execute but go for a coffee or catch up with work backlog but I need such moments as well.

Oh, one thing which is important with such format is keeping speakers at bay. I mean not everyone limits themselves to 30 minutes sharp which means they’re stealing time either from a following speaker or Q&A session. BTW: the idea to have Q&A after the slot of 2 or 3 sessions was marvelous. When it worked, and it worked most of the time, we had sort of mini-panel on a subject covered in a slot.

Summary

It seems this relation has already become longish so… to the summary. If the event had been moved a couple of months later and the choice of speakers had been a bit different there would have been no reason to complain whatsoever. However even now I feel that these two days were a very good investment and if I’d been making the decision whether to go to abe2011 again it would have been the same. I’m looking forward to attending the next edition.

One of great things about conferences is discussions which are food for thought pretty frequently. For some reasons, probably because its not-very-big size, ACE Conference is specifically good at this.

Sometimes it’s as if you’re talking with someone about the project you know perfectly. You could spend hours talking why it was successful, failed or whatever outcome it brought, except no one is willing to listen about the project that much.

Anyway, you could bet that nothing is going to surprise you about the project. Like with real money. And then you have a chat with a nice guy, such as Marcin Floryan, and you talking about the project for whatever reasons and suddenly, completely out of the blue, you have epiphany.

Suddenly you ask yourself, or are asked, another why and you answer the question intuitively and you’re totally surprised with what you’ve just said. It’s like wow, that’s oh so obvious, how come I haven’t thought about it earlier? What a dumbass I must have been.

So thanks to Marcin I had this kind of epiphany. We were discussing one of my projects which, from technical perspective, was very successful. Now that you ask – yes, it was the project behind the Kanban Story, but that’s not a reason this time. The thing we were digging around was whether technical excellence is a good investment.

It’s a problem of many teams: there is much pressure over them so they retreat to the good old hacking instead of keeping good engineering practices or even introducing them in the first place. They incur technical debt which they usually pay back during stabilization phase or maintenance.

So what happens when we remove time pressure? I assume here we talk about at least a decent team and people who know their craft. In the very project we discussed it meant longer development but most of the time regression testing, deployment and maintenance went quickly and flawlessly. Given that we were deploying like once a week it would be a real nightmare if it was otherwise. But then I know projects where every deployment takes a couple of weeks and it’s just a long painful stream of epic fails.

If you’re working on the project and you care about code quality in a longer time span you actually start reducing costs, as no matter how application grows cost of regression testing, deployment and maintenance remains basically flat. On the other hand, in projects with big technical debt tend this cost is growing exponentially.

And this is exactly the point when you start winning.

Let’s take a few steps back then. Why are we winning? Because we have low costs related to the final parts of SDLC. Why is it so? Because we don’t really have any serious issues with deployment and maintenance. Why? Because the code is good-quality. Why the code is that good? Because we keep it that way with our best engineering practices. And the final why: why do we have all these practices in place? Because there was no time pressure so we were free to adopt them.

The last why was my epiphany. For some reasons I haven’t really asked myself about non-merit reasons of introducing, or not, best engineering practices. Well, we kind of know it’s good to adopt best practices, after all they have the word “best” in their name so they can’t be bad, can they? But then it is so common that teams deal with time pressure and they sacrifice engineering practices on the altar of fast coding, also known as the altar of crappy code.

So well, if I had to point the root cause of the success in this example I’d say it was reduced time pressure. And the funny thing is, in the long run we were more productive than we would be if we had to drop our engineering practices.

I don’t say lack of time pressure is universally good. Actually I know quite many people who just need time pressure to be productive, but if you assume a decent team of good craftsmen it shouldn’t really be an issue.

Recently I took part in panel discussion on DVCS where my introduction ended up with “my last check-in happened in 2003.” So yes, now I’m “programming” in Outlook and Word. In Excel if I’m lucky. It doesn’t make me some sort of expert in terms of discussing pair programming, does it?

When we are at pair programming I confess I was never a fan of this practice. It somehow feels unintuitive. I actually do believe wise folks like Ron Jeffries, Corey Haines and Yoda who tell us it does work, but it’s kind of thinking “Well, for Yoda even a lightsaber works pretty damn well and I could only hurt myself with the thing.”

Anyway, I remained skeptical for a longer time, especially that none of my teams have ever seriously introduced pair programming. Recently Corey Haines made me thinking about it from a bit different angle when he told on ACE Conference that pair programming is like an instant code review. I must admit it kind of speaks to me.

The next thing which added some doubts was my recent experience which isn’t really programming-related. After all, you already know my last check-in was when people I now hire were still in kindergarten. Recently I’m often working on different documents pairing with different people. It doesn’t really matter what these documents are all about but if you tell “appraisal system” in my neighborhood I’ll make you suffer.

We’re usually trying to write something creative and, while working in pair, it works surprisingly well. Technically it’s like pair programming – one keyboard, one monitor and a couple of people switching roles occasionally: one is writing and another one is reading, commenting and asking “What the hell have you meant by that?”

One interesting thing which happens is the flow. As long as both people are focused on a document writing goes pretty smoothly – either I have an idea what’s next or you’re just telling me what’s on your mind. Also there are quite a lot of discussions about what exactly we want to describe at a specific point so we kind of cut feedback loop down to the least possible size. But here’s the best part: whenever, for any reason, someone goes out of the room, productivity falls flat on its face like instantly. Whenever I was the one who stayed it was as if someone has just turned struggle mode on. And then, when we were back in the pair, after a while we were reaching the flow again pretty quickly.

Another thing is even more interesting. After a couple of such sessions when I thanked the person who I paired with telling how much they helped me I heard as a response: “Well, it was you who did the work, I was just sitting there and commenting from time to time.” I was all like “Are you insane? What on Earth are you talking about? If not you I wouldn’t get even one fifth of this stuff in that time and it would be sort of crappy anyway.” In short, both of us thought it was the other one who did most of the work, which was quite funny.

Now a question: does it differ that much from writing code?

If asked, I wouldn’t say that pair document writing would yield such good results. Unless we tried it, that is. Now, I can hardly imagine we could have done it differently.

Of course it isn’t the best solution in every single case but the longer I think about it the more situations fit pair writing approach. I’m definitely going to do pair document writing more often.

And maybe it’s time to try pair programming in some teams as chances are it would show similarly unintuitive and similarly good results.

This is the story about trust and excellence.

Once upon a time, in some not-so-big software shop, development of a new project was launched. It was kind of side project in terms of day-to-day business. Actually one might say it was very, very side project. Anyway, a small team was formed to cope with a task.

Five brave people formed a fellowship. They all had their talents and they were dispatched to deal with different roles: development, testing, deployment etc. The team had a leader, guy with some battle scars who had seen quite a lot different projects.

Since it was the side project which they were working on the leader told the team they’re free to choose any methods they want – there was no pressure of time, at least at the beginning, and everyone wanted to make it pretty damn good in terms of quality.

So yes, they were allegedly wasting time on things like unit tests, refactoring, collective code ownership, code reviews, continuous integration and such. Yes, they could have been delivering features faster at the beginning, but they chose not to. They chose they’re going to keep all those practices as long as possible.

The leader never put the team’s choice to a question. He used to ask whether they believed they were doing the right thing. He used to see their head nodding as an answer. He trusted the team.

Fast forward: year and a half.

The fellowship kind of achieved the goal they were chasing. The product was kind of complete. The team was disbanded and everyone chose their own direction. But something stayed there. The product. The product which had to be maintained.

New mercenaries took over the code. It was kind of checkpoint for all the choices the original team had made over the project life span.

A couple of opinions which popped up:

• Did they really build it in such a small team in a year and a half? Impressive.

• This is one of best pieces of code I’ve seen here.

Now, doesn’t it sound a bit contradictory?

The punch line: the fellowship did a great job both in terms of quality of the product and pace of building it. They all wanted to excel and they were allowed to. The leader could not possibly verify whether their choices were good, so he decided to trust them.

And the outcome was something which falls into “pretty damn good” category if you ask me. Actually up until project takeover it was kind of speculation, but then the project became a living proof that it’s worth to invest in best engineering practices.

It pays off.

It pays off even when there are some counterintuitive things to deal with at the beginning. Actually it was easy to choose gung-ho approach and jump on building as many features as possible from the very beginning. But somehow from a perspective of time the chosen method resulted in both: good quality and relatively fast delivery.

Of course, all characters in the story were totally fictional and any similarities to real people completely accidental.

We were talking with a couple of colleagues who I’m working with at the moment about value of unit testing. It was pretty unique group. I worked with the same people on a different product a couple of years ago. In terms of complexity and size both products are similar. What differentiates them is the way they were built.

Product A was just hacked. While building product B we used some of best engineering practices, unit testing being probably the most important in the context of our discussion.

The main visible difference was upgrades. With product A, every time we planned upgrade it was inseparably connected with fear. Fear that something would go wrong. Fear that strange errors would pop up in strange places. Fear that client’s marketing people will start yelling at client’s maintenance folks, who will start yelling at us.

Considering we were upgrading Product A every once a couple of weeks (during maintenance window in the middle of the night) it was like a constant uphill battle. Yes, we were trying to limit problems but it was more like a band aid for a broken leg. Everyone hated those dreaded nightly updates.

Now, we upgrade Product B with similar frequency. I think we faced some issues twice in like year and a half. No one is even stressed about those updates. It is just another station on our Kanban board. Definitely not the most painful one.

There were people from project management, development and maintenance involved in discussion and neither of us would like to get back to what we had with Product A. I can’t say exactly how much time we spend writing unit tests although if I had to guess I’d say at least a few times less than we’d have had to spend fixing recurring bugs and upgrade issues.

Let me stress once more: none of different folks involved in discussion had any doubts about the value of unit testing.

Note: I don’t try to make it about team happiness because of reduced load of worst kind of work, which is chasing and fixing bugs, or about client happiness because of reduced volume of issues. It’s just a simple business case. Invest some time in quality up front and get your ROI when you implement and maintain your software.

A final thought: I don’t say maintaining unit tests is easy or it always works without a glitch, but I don’t believe it doesn’t work in your case unless you’ve tried. And I mean really tried, not added a bunch of them and call the thing “boring.”

And if you want to yell at me because of writing such basic stuff, look around – I don’t know how about you but I still see a lot of projects which completely ignore existence of unit testing.

This is the old story you heard a number of times if you worked for a big company: we’re doing poorly so let’s reorganize things a bit thus solve our problems. And then, a year later, let’s do it again as it surprisingly appears that we aren’t doing any better.

Well, if you believe in this pattern I have a bad news for you: coffee doesn’t become sweeter just because you’re stirring.

Reorganization itself is exactly like that: stirring. If you don’t have right ingredients in the cup stirring won’t cause any change. No need to expect anything else. And this is basically the point which most big organizations fail at.

Do I try to say that reorganizing things is evil, should be prohibited and people doing that should be forbidden to drink beer? Um, no, not exactly. First of all, I believe in continuous improvement which is just a series of tiny reorganizations and changes implemented to make our lives easy, pleasant and generally much better. Well, at least better from the hell we see around every day.

But then, when I say reorganization you don’t think continuous improvement and small changes. Or do you? You see big-ass change which makes everyone feeling insecure, long months of chaos, conflicts of interests etc.

So maybe the size matters indeed? Small change is good but big one is not? As a short guy I have to say that: small is generally better. But then, sometimes small steps aren’t enough. If the whole thing is screwed big time what you need is a big gun – The Big Change.

It’s like with a cup of coffee. Of course you can wait until sugar itself dissolves in your coffee but then you have sweet, but cold coffee. Fixed one issue; introduced another. What you need is some stirring. Reorganization.

So if you think about reorganizations think about content – do you have everything in your cup, just in the wrong order? If so, lucky you. If not, focus on finding right content and not about reorganizing things. Your cup is your organization and people are your content.

And this is exactly the point of reorganization. Fast change in the order so right people can find their way to right places. From this perspective the change is just an enabler to overcome status quo and it isn’t such an important thing what exactly you’re reorganizing and how. It also means that as long as you don’t have right people at hand you will fail, no matter how well-crafted your plan was.

You have to pour sugar into the coffee before you start stirring. Otherwise the only effect you can see is the pain in your hand.

Under my recent post about best engineering practices I was pointed that it is just another “do whatever works for you” or “I don’t know experiment” kind of advice. Well, it was that kind of advice indeed. Have I ever given you a different one?

Anyway I admit shot was on target. If someone is one of those battlescars who has seen much they probably would be more than happy to hear something like that. On the other hand if you happen to be a freshman you may expect to get something like a real advice. You know, the one which you can simply take and apply in your team without much thinking since “the wise guy said so.”

Coming back to best practices than. What can I tell you besides you should experiment with your practices to find what works for you? Well, if I had to choose one engineering practice which is definitely a sure shot I’d go for continuous integration. And yes, I’m not expecting a flame war under this post.

“Who the hell doesn’t have continuous build yet? We are in 21st century, haven’t you heard?” Yes, I used to treat continuous build as an obvious thing a decade ago and you know what? I was wrong. There are many teams and companies which don’t have continuous build implemented. Why? Because they think it is hard, because it takes time to setup the whole thing, because the project is oh so legacy, because no one cares, because no one approved order for build server, because, because, because… If you want to hit the dog you will find a stick. And many companies are still beating poor puppies hard. I could name huge systems sold to big institutions which never touched a build server.

I can tell it as an anecdote: pretty much every company I worked for set up continuous build once I was working for them. This basically mean the earlier you hired me the better. Not that every company I’ve worked for still exists but we aren’t discuss business here, are we?

If I think about setting up a team or project the very first task to do is getting and configuring a build server. It is a prerequisite to write a first program. And I’m not going to take a look at damn hello world application until build server is up and running. Don’t even say you dared to write any code without continuous build set up.

So this is my first answer about specific engineering practices we all should employ. Unfortunately once I started to give you specific answers I expect to hear “what’s next?” And from this point every answer can be only more difficult.

That doesn’t mean I won’t try though.

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?