TL;DR Many IT people (mainly executives & various managers) are guilty of building the walls between business and engineering parts of organisation: by introducing gated demand management, communication via specification, cooperation through proxy people and siloeing the competences they hope to achieve more order & control, additionally reducing the operational risk. What they get instead is crappy products, nose-diving trust, peaking inertia, "local" ownership & problems with knowledge sharing. Building software-based products is all about tight & CONTINUOUS co-operation (incl. feedback) between Business & IT. As we live in times where Agile Manifesto has almost the status…
All posts in agile
What's the most popular Agile method these days? FDD? Nah, no-one ever has seen a living FDDer - this method has been made up so there are at least 3 Agile methods on the list ... XP? Another fake - it's just a collection of programming techniques that: everyone has heard about barely anyone literally applies but all pretend to ... Scrum? Actually, Scrum is almost as rare as XP - it's the Scrum's lingo that is truly commonly used (it's passe to be a Team Leader these days, so everyone renames to Scrum Master) The most popular Agile method is Jesus-Driven…
What if ... a hypothetical company published a hypothetical job ad like that ... (this is not a real job ad, I'm not representing anyone or looking for any people - I'm just wondering whether industry is mature enough to call some things by their true names ...) We're looking for a software developer (technology X). Background, experience, past projects are irrelevant as long as you know the syntax of language Y & framework Z. Don't worry if you got rusty on any of those two. You'll start with a short, intense training to make sure you'll ready to rumble from the day…
A lot has change since I've gone pro in software development, one could say at least one era has passed since then, but some things never change - one of them is Enterprises loving Fuckin' Big Projects (FBP), dinosaurs of XX/XXI century. In defiance to the common sense ... Enterprises love FBPs because: big things tend to grab attention of big stakeholders, so yeah - politics in Enterprise, it's freaking hard to get valuable experts on-board due to their day-to-day duties - big project has got much higher chances as it may spawn some sort of new unit / entity within…
Have you heard about The Iron Law of Oligarchy (TILoO)? No? There's no shame, I haven't (until recently) either, but now since I did, I have some remarks hopefully worth sharing. OK, but first - what's the TILoO about? Here's the briefest version: Rule by an elite, or oligarchy, is inevitable as an "iron law" within any democratic organization as part of the "tactical and technical necessities" of organization. Robert Michels, "Political Parties", 1911 Don't freak out (just yet), I'm not bothered by the most obvious, political aspect of "democracy" :) What I'd…
I am sort of conference junkie. I'll skip the 'why' part, because I've described it already once or twice - instead I'll get back to what I like MOST (relax, just one thing) about conferences & why I attend them instead of just watching the videos published afterwards: to meet (in person) the practitioners who've succeeded greatly, listen to their stories & ask them inconvenient questions :^D Two important comments before you mis(/over)interpret what I've just written above: Every company is different & you can't just get practices / tools from company A, use them in the same way…
This blog post is about Enterprises whose core business is NOT IT, but they consider IT services as an important part of their everyday operations. Large Enterprises in 2015 (at least in Europe) are pretty from what we remember from 2000, 2005, 2010. There are still some dinosaurs & they'll be here for a lot of time, but there are many companies who have realized that IT is changing rapidly world-wide & so they have to remain in the game: more & more embrace DevOps, Continuous Integration, TDD, OSS, predictive / real-time analysis & other modern practices. It happens in some…
Few days ago I've written a blog post about feature teams - I wasn't hiding that it was inspired by C. Larman's book about scaling Agile. Or rather by one of the chapters that I've found very interesting & thought-provoking. There's another excerpt I keep coming back to, because I've found it very genuine & important: "The project manager became responsible for the coordination among teams and even for the communication to the Product Owner. He became stressed and overloaded with work. When we told him that his role is not needed, he laughed, and pointed out the amount…