And you are here why?

There is a persistent myth — particularly prevalent amongst control freaks— that if you get the  requirements  detailed enough, you can assembly-line your way through  development . Dig deep enough, and you’ll find that to them,   Agile is the same as Iterative Development   . Oh, they absolutely get the bit about “ user feedback ”, “ short sprints ”, “ incremental releases ”, and so on. However, in their minds, all of these steps apply   only   to the development process, i.e., you do all of these things   after   you’ve nailed down all the requirements, as shown below From their perspective, you just iterate through the development cycle in a succession of sprints, in what is basically a linear progression. In each sprint, for example you cycle through  Design → Development → Release → Review  for 10% of the requirements, and at the end of 10 sprints,  voila! you’re done! Oh, if you want to get a little pedantic, t...

Estimating sucks, doesn’t it? I mean, sitting through those sprint planning meetings is, easily, the worst part of the job, right? Or wait, maybe those endless discussions about what exactly a story point is,  those , are the worst part of the job. Or maybe trying to figure out whether you should switch to T-shirt instead of story points, maybe  that’s  the worst part. /via http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/ID/2388/How_do_you_estimate_your_Business_Analysis_or_IT_project_work.aspx Spend any time in product/development circles, and you’ll run into (a lot of?) people who wear their loathing for estimation as a badge of honor, who swap horror stories in hushed tones, and reflexively glance over their shoulders when they do so. What’s more, there is a bit of an implicit assumption that estimates are all just Dartboard Games anyhow, because, in the end, you’re just guessing… Hyperbole? Yes. And also no, because there is definitely ...

/via http://www.commitstrip.com/en/2017/01/09/that-little-problem-with-agile/ The thing is, the higher up you go in the organizational food-chain, the more lip-service you get towards agility/flexibility. Actually, that’s not quite true — you’ll get the commitment,  as long as everything goes just right . The easy part to get buy-in on, the thing that they  totally  get, is the bit about  user feedback ,  short sprints ,  incremental releases , and so on. The part that you have to be  very  careful about though, is that in their minds,  this,  literally , translates to a linear progression , where, for example, over 10 sprints, you do 10% of the work each sprint.  User Feedback, in their minds, is User Validation! To belabor the obvious, their intuitive understanding is that there are no “ wrong roads taken ” and no “ failed hypothesis ”. Be very,  very , careful about this, and do your damndest to overcome this. I...

“ Netsplits are rare, so I don’t think about them ”  —  #CowboyDeveloper The thing about the above statement is that even if you aren’t a   #CowboyDeveloper , it’s not necessarily wrong .   That’s for a given value of “rare” mind you, and   you ignore it at your own risk . The question you should ask yourself before making the above statement is “ What is the risk associated with a netsplit? ”, and the answer to that should inform your engineering decisions (•). And that brings us to the main point here — this is not just engineering decisions about network partitions — it’s   all   your engineering decisions! So great — you assess the risks, plan / design accordingly, and it’s all copacetic, right? Well, no, and that’s because “assess the risks” is carrying a lot of water. The issue here is that the   people   implementing the systems are, well, human, and as humans, they are quite likely to end up with some combination of 1. “ If I don’t kn...

So yeah, you’re Agile, you’ve got two week Sprints, your requirements are Tight, and you religiously do retrospectives. Great. Seriously,  great . Most people actually don’t do any of the above, so you’re already way ahead of the pack. The thing is, even with the best of intentions, retrospectives end up being about the current sprint, the task at hand, or, hey, even the user stories that you were working against. What they are  not  about is about underlying assumptions, the mental framework that you have in place that led to the current set of requirements, user stories, and so forth. To put it differently, we are all trapped within the bounds of the our current thinking processes, and rarely step  outside  our comfort zone. And therein lies the rub — working within our existing frameworks will, at best, lead to incremental change. For the truly significant improvements you really,  really  need to examine (and adjust!) your priors. And t...

Process is not the solution. Process is never the solution. It can, however, be the means to the solution. Do not, repeat, not , confuse the means and the end... Mind you, I have seen "Agile" and "Scrum" used most frequently to just mean "now you have more work to do..."