Articles tagged “management”

• Faut-il embaucher un développeur inexpérimenté ? Lorsqu’on est at­ten­tif à ce qui se dit dans les com­mu­nautés comme les sites de Stack Ex­change, ou en­core par les lead­ers, tels que Joel Spolky, en matière de l’or­gan­i­sa­tion du tra­vail au sein des…
  workplace 7 management 34 hiring 15 french 4
• A failure as an opportunity Fail­ures hap­pen, es­pe­cial­ly in soft­ware de­vel­op­ment in­dus­try, where mul­ti­ple fac­tors can in­duce fail­ure, from un­re­al­is­tic ex­pec­ta­tions by the cus­tomer to the in­com­pe­ten­cy of the staff to the se­vere…
  management 34 communication 27
• Quantifying time and cost: why do we always get it wrong? Dis­cus­sions like this hap­pen all the time when you work in IT. You are giv­en a sum­ma­ry which bare­ly de­scribe the pro­ject, you have no time think­ing about it, and then you re­ceive a strong pres­sure from your boss be­cause some PHP code mon­key from a…
  communication 27 quality 36 management 34
• Deliver first, develop later No mat­ter which work­flow is cho­sen by a team, there is one com­mon flaw: the prod­uct is shipped only when it’s done. In this con­text, it is not sur­pris­ing that many prod­ucts fail to be de­liv­ered on time. The de­liv­ery process is both com­pli­cat­ed and…
  management 34
• Choosing a color for a brand It is not un­usu­al for some com­pa­nies to spend nu­mer­ous meet­ings dis­cussing the col­or(s) to use for a logo of a prod­uct. Some may waste hours or days be­cause no­body agrees about the col­or(s) but every­one agrees that choos­ing the wrong col­or will…
  management 34 meetings 1
• Playing the Russian roulette with your business · the excitement of the randomness Af­ter spend­ing a few months in an or­di­nary small French soft­ware de­vel­op­ment com­pa­ny, I’m tru­ly amazed at the ef­fort which makes the whole process high­ly un­pre­dictable and in­creas­es the odds of fail­ing at every step. If work­ing for a well-or­ga­nized…
  management 34 risk 1 rant 34
• Dockyard of ships that can’t sail Bad­ly man­aged pro­jects of­ten share an el­e­ment: the will­ing­ness to de­liv­er all fea­tures in a giv­en amount of time and with­in bud­get. Giv­en how we con­cep­tu­al­ize the no­tion of a de­liv­er­able out­side IT…
  management 34 rant 34
• Time estimation. Done. When I start­ed my ca­reer as a free­lancer, I used to re­cur to or­di­nary tech­niques of the good old wa­ter­fall-style pro­ject man­age­ment. It is not sur­pris­ing that I also scrupu­lous­ly tried to de­ter­mine the time and the cost of a pro­ject be­fore start­ing…
  management 34
• Ascending and descending representations of quality There are many pro­jects which start with very low ex­pec­ta­tions of the qual­i­ty of the source code and pro­ject or­ga­ni­za­tion. The idea is to get some­thing which sim­ply works, start to sell it, and then, ei­ther con­tin­u­ous­ly or in one bru­tal step,…
  management 34 quality 36 short 50
• Permanent prototype Each pro­ject fol­lows more or less one of the fol­low­ing mod­els, some­times sev­er­al of them com­bined: De­sign first, It­er­a­tive, Per­ma­nent pro­to­type. The first two ones are well-known. The first one is the clas­si­cal Wa­ter­fall mod­el. Pri­or to de­vel­op­ment,…
  management 34
• Seven lies to stakeholders Those are the points that are fre­quent­ly sub­ject of mis­un­der­stand­ings or plain mis­in­for­ma­tion be­tween IT per­son­nel and stake­hold­ers. En­coun­ter­ing one of sev­er­al of those points in a pro­ject is a good in­di­ca­tion that com­mu­ni­ca­tion should be re­viewed.…
  communication 27 management 34
• Don't ask writing good code What a sur­prise. Af­ter be­ing asked for months to sim­ply write code as fast as pos­si­ble, with no think­ing or test­ing, man­age­ment sud­den­ly crit­i­cized one of the col­leagues, be­cause the code of a new, un­sta­ble fea­ture im­ple­ment­ed to­day con­tains long…
  management 34 quality 36 short 50
• Roadmaps, goals, morale, beliefs and motivation One of the as­pects of de­vel­op­er per­for­mance to con­sid­er is the avail­abil­i­ty of the roadmap, a roadmap which is very pre­cise near the point the per­son is, and less pre­cise far from it. Why is it im­por­tant for a de­vel­op­er to have an im­me­di­ate ac­cess to…
  management 34 backlog 2
• Taking hostages with Waterfall It is ear­ly sum­mer, year 2013. A com­pa­ny I was work­ing for starts a new pro­ject sched­uled for re­lease in Sep­tem­ber. A few days ear­li­er, the pro­ject man­ag­er de­ter­mines that the pro­ject should take…
  management 34 agile 10 communication 27
• Brooks's law in Agile projects I was re­cent­ly asked whether [Brook's law][1] ap­plies to Ag­ile pro­jects as well. By Ag­ile pro­jects, the per­son ask­ing the ques­tion means ac­tu­al, real Ag­ile pro­jects, the ones where can­cel­ing a pro­ject and re­sum­ing it sev­er­al months lat­er with a…
  management 34 agile 10 short 50
• Visual management I dis­cov­ered [Vi­su­al man­age­ment blog][1] in 2013. Al­though I al­ready heard about Kent Beck's Big Vis­i­ble Chart, I've nev­er ac­tu­al­ly seen vi­su­al man­age­ment in prac­tice be­fore. For me, tick­ets went straight to Fog­Bugz or TFS and re­mained there,…
  featured 8 management 34 agile 10 productivity 36 communication 27 workplace 7 backlog 2
• What if the team would just circumvent the “productivity measures”? Work­ing with teams and com­pa­nies which ex­pe­ri­ence prob­lems, I can't no­tice a strong cor­re­la­tion be­tween the way man­age­ment treats em­ploy­ees and those em­ploy­ees treat pro­jects they are work­ing on. It al­ways amazes me how many CEOs are ex­pect­ing their…
  productivity 36 management 34 communication 27
• And what if most projects were research projects? When I start­ed to work on the lat­est pro­ject re­quir­ing skills in Lin­ux, Python and Node.js, that is three do­mains I nev­er used be­fore, I was very clear with my­self: the pro­ject will take what it will take, maybe two months, maybe six, maybe three…
  management 34 communication 27
• Measurements as a precursor of culture of quality When au­dit­ing dif­fer­ent IT com­pa­nies, the no­tice­able pat­tern is that com­pa­nies which per­form bad­ly have prob­lems in every imag­in­able area. I've nev­er seen a com­pa­ny which has out­stand­ing work qual­i­ty…
  productivity 36 management 34 quality 36 workplace 7
• Control Hu­man be­ings want to con­trol every­thing. Their lives, oth­er peo­ple, things around them, events which can af­fect them in any way. The il­lu­sion of con­trol gives them cer­tain­ty, the feel­ing of or­der, the…
  thoughts 6 short 50 management 34 agile 10
• Packages, dependencies and interaction between teams Re­cent­ly, a ques­tion of Pro­gram­mers.SE passed un­no­ticed, be­cause of its length. This is un­for­tu­nate, be­cause the ques­tion high­lights a bunch of mis­un­der­stand­ings with­in many teams on a broad range of sub­jects, from Con­tin­u­ous In­te­gra­tion to…
  rant 34 productivity 36 management 34 communication 27
• Visual management and the everlasting tasks Near­ly a year ago, I de­scribed how I im­ple­ment­ed vi­su­al man­age­ment in my com­pa­ny. My us­age of vi­su­al man­age­ment re­mained rough­ly the same, but over time, I dis­cov­ered one as­pect I wasn't think­ing of when I wrote the orig­i­nal ar­ti­cle: the tasks which…
  short 50 management 34 agile 10 workspace 1 communication 27
• Telecommuting and procrastination My col­leagues and I had re­cent­ly an in­ter­est­ing dis­cus­sion about let­ting de­vel­op­ers to work at home. They high­light­ed that one of the is­sues of telecom­mut­ing is that it makes it dif­fi­cult for the…
  productivity 36 management 34 quality 36
• Person-centered metrics and self-organizing teams We can­not re­li­ably mea­sure de­vel­op­ers' pro­duc­tiv­i­ty, and this is the ma­jor el­e­ments which push­es many man­agers to fo­cus on less rep­re­sen­ta­tive as­pects of de­vel­op­ers' con­tri­bu­tion to a pro­ject and a com­pa­ny. Some com­pa­nies do a re­al­ly bad job,…
  management 34 quality 36 productivity 36
• Official version control, competing systems and free market The way ver­sion con­trol ser­vice is or­ga­nized with­in many cor­po­ra­tions is that there is an op­er­a­tions de­part­ment which is in charge of the of­fi­cial sys­tem, and, de­pend­ing on the com­pa­ny, de­vel­op­ers are ei­ther forced to use this sys­tem, or are sim­ply…
  thoughts 6 management 34
• Expensive projects are really cool Fol­low­ing my pre­vi­ous ar­ti­cle, a col­league told me a sim­i­lar but much more im­pres­sive sto­ry which hap­pened to him. Since he doesn't en­joy writ­ing too much, he in­vit­ed me to tell the sto­ry here. Six years ago, Nico­las was hired as a free­lance…
  communication 27 featured 8 management 34 short 50
• Estimation vs. commitment I love es­ti­mat­ing soft­ware pro­jects. Oh, who am I kid­ding?! Most IT pro­fes­sion­als hate be­ing asked how long the task will take. They hate it for a good rea­son: they find it worth­less, and they know their es­ti­mates are usu­al­ly wrong any­way. As such IT…
  management 34 communication 27
• Working with the people you manage A few years ago, I worked in a com­pa­ny in Poitiers. Things went well un­til our boss left, and a new one ar­rived. The new one ap­peared to be, well, a bit proud of his new sta­tus, and, nat­u­ral­ly, de­cid­ed that he has plen­ty of im­por­tant things to do and…
  communication 27 management 34 rant 34
• “T-shaped” people model misuse In Hand­book for new em­ploy­ees (PDF, 4 MB), Valve in­tro­duced on page 47 a con­cept of “T-shaped” peo­ple. What it means that peo­ple who want to work at Valve are ex­pect­ed to be both gen­er­al­ists—“high­ly skilled at a broad set of valu­able things” and…
  management 34 short 50 thoughts 6
• On bug tracking systems There are no good bug track­ing sys­tems, and I'm about to ex­plain what makes them not good and why good sys­tems weren't de­vel­oped yet. To be­gin, let's il­lus­trate a jour­ney of two per­sons work­ing on the same team: one of the pro­gram­mers and a prod­uct…
  rant 34 productivity 36 user-experience 10 productivity 36 management 34
• Lazy programmer fallacy There is, among pro­ject man­agers, a think­ing that pro­gram­mers are lazy. Pro­gram­mers—they say—don't want to work; they pre­fer play­ing games or just do­ing noth­ing at all. This is all but truth. Ac­tu­al­ly, many pro­gram­mers en­joy pro­gram­ming. They have…
  rant 34 short 50 management 34 quality 36
• Minimum viable product An in­ter­est­ing ques­tion on SE.SE got my at­ten­tion re­cent­ly. The ques­tion is about things that may hap­pen to a pro­ject, in a con­text of a pro­ject which is tar­get­ed to be de­liv­ered eight months af­ter its start. A dis­cus­sion that fol­lowed showed that…
  management 34 agile 10 productivity 36 communication 27
• How to deadlock a project In 2014, I wrote the ar­ti­cle Tak­ing hostages with Wa­ter­fall, ex­plain­ing how Ag­ile moves the pow­er of de­ci­sion about the scope and the cost of the pro­ject from the ones who make the soft­ware to the…
  blog-engine 2 management 34 quality 36
• Edge cases Soft­ware prod­ucts are de­signed for the cas­es where things go right, the sit­u­a­tions, where net­works are per­fect­ly flaw­less, servers don't re­boot ran­dom­ly, and process­es hap­pen as they would hap­pen in…
  quality 36 management 34 interaction-design 9 user-experience 10