Agile in hostile environment

It can be tricky to apply agile methods in a fundamentally waterfall environment. So tricky in fact, that we might be better off without agility.

Agile Manifesto was created to help creating software of value, which - according to the founders - required a different approach and a different set of methods altogether. The neccessary shift of approach was expressed in nice and clean preferences from wich the methods are more or less directly derived. If because of the circumstances we cannot make the shift in the approach, using the methods stubbornly makes little to no sense. I start with the easy ones, see if I can ruin it all for you..

(1) If the deadlines and the scope is fixed, moreover you need to deliver certain results (documentation, software, test results, etc) at certain times, you are following a plan, instead of responding to change.

(2) If you need to provide detailed req.spec, estimations, design documents, etc, then obviously working software is only of second priority, since the signing and the delivery of the contract relies heavily on these documents, rather than on working software itself.

(3) If you have to have the req.spec and the corresponding estimations upfront, you and your client - forced by contract - are bound to them(i.e. requirements and more or less estimations too). And then with even the best intentions you can get your client involved in the preliminary discussion only which are theoretic almost by definition.

(4)I left the toughest one for last.
The sobering truth is that - and a sick plot twist is around the corner, you better watch out - in such a hostile, anti-agile environment, as the above depicted one - applying agile tools and processes, in fact might be the wrong choice, and for the wrong reasons too. Because this in itself goes against agile principles in that it chooses processes and tools over people, who can't enjoy the benefits of agile methods, nonetheless have to invest the extra effort they demand. And almost all of it is completely in vain, as the software won't be any more of value than it would have been with traditional methods, because it will turn out to be exactly the thing that was required/designed/estimated/agreed-upon before any line of code had been written and/or tested.

Read full post...

Transformers

Much of the agile literaure is focused on how difficult the transition from traditional to agile could be. They address the problem from many angles describing techniques how to help programmers to make peace with pair programming, how to get better at incremental design, some even suggest to use Organizational Patterns to introduce some of the practices to a team or a company. They all seem to be empathic with people who as a rule fear and loath change.
I don't see it that way. I actually think being a true "waterfall guy" helps you to accept agile, and helps you to execute XP practices and to a better outcome too(from this point on I'll be referring to XP, but probably most of what I have to say applies to other agile methodologies as well)

Having had been a true waterfall guy myself, with my precious UML diagrams, my very own modules and an ever strengthening habit of working alone on a laptop in pubs and cafes only occasionally checking in my work for my team to see, I had no problem at all transitioning to XP -- quite the contrary.
I enjoyed Pair Programming from Day 1, because I realised how much easier it is to pick one from the many possible ways to solve a problem, if you have someone competent to discuss it with. I learned not to fear to be stuck anymore, simply because it happens almost never, and even if it does, it's far less frustrating when you have someone next to you to share the pain. Becuse of all the implicit and explicit problems I had with the tradtional way, I appreciated Pair Programming a lot more then I would have otherwise.
To be able to do Incremental Design it's good to have had done a few BDUF yourself. It helps you to see the big picture - which some false interpretation of incremental desgin denies to be allowed - and it helps you to come up with sophisticated solutions quickly. But most importantly once you have seen first hand what's wrong with BDUF, you are ready to like Incremental Design for all of its benefits.
TDD is again something you appriciate more coming from a Waterfall world, because then you know how fustrating the bugfixing phase normally is, fixing and refixing bugs for months. You also know how frustraing and shameful it is not to make changes to code you hate and not to refactor at all due to either fear of breaking something, or an explicit order from your bosses, with something about changes are risky at this stage of the project, but the right stage for a change never seems to come. In which BTW they are absolutely right: without an extensive test harness, you can never be sure, even a little, that the changes you're about to make won't break the whole system.
All in all, the skills you learned and the bad experiences you had with waterfall all will make you a better agile developer.


Read full post...