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
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
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
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
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
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
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
I've always had a clear vision of how code ownership should look alike:
- each piece of code should be owner by 1 team
- code should be divided domain-wise (not tier-wise, so no "component teams", please)
- responsibility of the owner is not only for writing code, but also deploying, troubleshooting, supporting & maintaining as well
- in terms of testing - the owner team is responsible
"Commitment to the fixed scope."
Those three statements have made my flesh creep, did you get the same sensation? They are definitive, they are scrict, there are about formal responsibility & discipline. And they are the essence of traditional, waterfall approach.
Agile seems far more relaxed about that:
- story points are not exchangeable for any currency, they don't translate to MDs
There's one thing that freaks me about agile adoption in large enterprises. WAIT. NO.
There's one thing that particularly freaks me about agile adoption in large enterprises:
Full conviction that it can be done only in a top-down way
It has to be a shift in company's strategy, idea of chairman who had just recently had lunch with someone who's company's doing Agile. And
Self-governing, self-stating, self-managing, self-organizing TEAM.
Combined human potential. Direct interactions & co-operation. Simplifying communication routes.
Power to the (team) people.
Yes, that's right, agile approach promotes all the team-related statements listed above. Scrum team, in favorable circumstances, can perform magnificently without any kind of manager support (not mentioning one onboard). But does it mean that agile projects ...
... don't need managers at all?
Everyone is doing some sort-of-Agile stuff these days (you wouldn't believe me, if I could tell you ... I was surprised myself ;>). As a result, I'm clenching my fists while listening about ...
- test (or integration) sprints ...
- velocity variance between sprints limited to X% ...
- 1m sprints grouped in 3m increments, grouped in 6-9m releases (YES, you've read it correctly) ...
- POs obliged to meet the Dev Team