Pragmatic Agilist

Let's say you are in charge of the "services" operation within the IT department of a large enterprise.  You're a government entity, a telecommunications giant, or some other titan of industry.  Other IT organizations have grown up around you in the enterprise over time, and they're writing cute little front-ends that get information from customers to your services, and pass the results back.  They're doing iPods and tablets, and you're still dealing with Cobol.  Your colleagues are all concerned with "cascading style sheets" and "user experience" and color schemes and the like, but you're doing all the grungy, large-scale back-end work that actually causes the money to pour into your organization and keep you all paid. Image courtesy of http://www.apolloamusements.com Needless to say, your vast IT cube farm in the sub-basement is not equipped with a foosball table. Suddenly, one day, you get an edict that your enterprise is

If you are a BA looking down the barrel of an agile adoption at your work place, you may feel worried that you will be switching from reams of paper stored in large binders to index cards. And not the big cards either. You're looking at the 3x5 ones.  You feel this plan is ridiculous.  You may murmur something to yourself about "insane fads!" or "damage control!" or "keep secret requirements locked in my desk and bring them out later to save the day!"  Take heart, dear friends. card wall from http://www.scrumology.net/2011/09/15/kanban-kickoff/ (Mr. Yuck is public domain) Things may be different at start-ups, in small shops, and in places already whirring like Kanban tops. But in most fair-sized enterprise IT shops I've worked in, your first efforts at agile implementation will not aim to reduce the quantity of requirements documentation significantly.  Instead, they change the timing at which the requirements are written, and with th

Mike Gualtieri threw down an enjoyable gauntlet this week with his Forrester blog post, " Agile Software is a Cop-Out, Here's What's Next "  Gualtieri put some provoking words around two sentiments I've agreed with for some time, namely: 'Using "working software" as the measure of progress is narcissistic,' since it focuses on what developers are interested in (the software), not what the business is interested in (the value the software brings to the business) It's a further cop-out to think ' that great software can be developed through a process of dead-reckoning with business people.' (the hyperlink is Gualtieri's).  Incremental design by committee may be democratic, but it's not going to create any iPods. I found myself very entertained by this blog post.  Particularly the "dead-reckoning" reference.  Anyone who knows Johnny Cash's famous song, " One Piece at a Time ," has probably thought

It was a bright and sunny day, and suddenly an agile software development project began. Scott Ambler started his classic 2008 Dr. Dobbs article " Iteration Minus One " this way.  And of course he went on to drive home the point that projects don't just emerge fully staffed like Aphrodite from the waves. Somebody has to do the logistics. Botticelli's Venus, from http://www.paleothea.com/Gallery/VenusSea.html But how much planning and setup are you allowed to do on a project before they revoke your agile badge and change the secret handshake?  Although the Agile Manifesto celebrated its tenth anniversary this summer at the Agile 2011 "Return to Snowbird" conference, people seem as disagreeable as ever about what the runway should look like for an agile project, and how long it should be. Just before that conference, Vikas Hazrati's InfoQ article urged readers to put their teams straight to work: "every iteration needs to produce worki

My ThoughtWorks colleague Rolf Andrew Russell recently pointed out on our company intranet that there are implicitly two definitions out there of the agile manifesto 's principle of "continuous delivery of value": "'technical' CD - the stuff in [ Jez Humble and Dave Farley's book, Continuous Delivery ].  minimizing lead time from code check-in to production." "'business' CD - what we sometimes call the full monty.  minimizing lead time from idea to production and then feeding back to idea again." He further observed, "When a business person or executive hears the term 'continuous delivery' they naturally interpret it as the latter.  And this makes sense because 'business' CD speaks to the true business value and encompasses 'technical' CD.  But 'business' CD is way more than just the devops stuff.  It is changing the way XD, PMO, analysis, etc, work, and minimizing their lead times."