Pragmatic Agilist

I don't mean to go all "woo woo" on you, but you already have a personal online brand.  Don't believe me?  Bring up your favorite browser and type your name in quotation marks ("Firstname Lastname"), and do a quick search.  Try it again with your middle initial added.  Did something come up?  THAT's it!  It's your personal brand! From http://tentblogger.com/blog-brand/ Do you like what you see?  If not, or even if you do, please, in this joyful holiday season, take some time to give yourself the priceless gift of strategic personal brand management.  Here are three personas to consider as you do it: The Shadow:  let's say you're a very private person, and you would like to minimize your online brand altogether.  Take some basic defensive measures.  If you participate in any online social media, learn how to use the privacy settings for each site you use, and set them to maximum.  You can set up Twitter, Facebook, an...

As a little palate cleanser, I thought I would do a quick blog today about my new Samsung Galaxy Tab 10.1, in case any of you are thinking of buying a tablet. The Apple Newton Executive Summary :  I'm pretty sure you should get an iPad.   But there are some things I learned while trying to get used to my tablet that could help you make your own decision.  If you read "the literature" online, you will see lots of people comparing screen brightness, processor speed, and number of applications available in the respective Android and Apple application stores.  Yadda yadda.  Here's what you should really think about first. Battery management:   it turns out you will want to use the device on battery power.  It's meant to be a "portable" sort of thing.  So find out before you buy:  how many hours do you need to charge your tablet compared to the number of hours it runs without being plugged in?  How long is the battery l...

I've been having many conversations recently about how to set up the agile teams I'm coaching with the right Product Owner.  As we all know, the PO must be empowered to make decisions, yet must also be knowledgeable enough about what the software should do that she can make constant small decisions for the team so they don't have to wait.  The PO understands the big picture, understands the small picture, and can set priorities. I blogged a few months back about how the "Team Room" must be considered a metaphor , not a literal prerequisite to trying agile for the first time.  I know I am stepping into equally sacred cow pies here, but I am going throw my weight behind greater thinkers than I who have already posited that the "Product Owner" should be considered as a team, not an individual.  A small village, not a literal person.  Consider these "Product Owner Team" proposals from Mike Cottmeyer , Ben Linders , and Marc Löffler , specificall...

I've been pondering further difficulties of being a product owner , both silently and aloud, so yesterday I was happily bowled over by a new idea on the topic from my new ThoughtWorks colleague Jasper "Dutch" Steutel (@dutchdutchdutch for twitterphiles).  He calls his discovery the "design spike," and we ended up talking together about a related concept, the "value spike."  So what's this all about?  Aside from being "Vampire Month" on the Pragmatic Agilist? From http://io9.com/james-marsters The Problem It may be different in a small start-up or a firm well-organized into small, highly integrated business/technology verticals, but in a typical large corporate enterprise with matrixed silos, it is quite challenging for a Product Owner to speak for all of the stakeholders on a project. The PO must be able to speak fluently to the technical people on the team The PO must be able to provide one reliable set of priorities which ...

Product Ownership is very difficult.  Take a big step away from the Agile Manifesto and think for a moment about project stakeholders, user stories, and how they don't fit together as neatly in real life as they do in Mike Cohn's User Stories Applied , as awesome as that book is.  How in the world is it possible for there to be a single person standing in for all project stakeholders in negotiating with the team? From http://www.implementingscrum.com/2007/04/23/the-cast-of-implementingscrum-infamous-yet/ Conveniently, Cohn himself points out The First Fallacy of the Product Owner .  And that is, of course, that such a being actually exists : On an ideal project we would have a single person who prioritizes work for developers, omnisciently answers their questions, will use the software when it’s finished, and writes all of the stories. This is almost always too much to hope for, so we establish a customer team. The customer team includes those who ensure that th...

As a coach and trainer, I have noticed that when I start the "Roles, Personas and Goals" discussions, attendees in the room are 40% more likely to start surreptitiously checking e-mail their smartphones than they when we talk about comparatively exciting topics such as "stand up meetings," "story boards," the "burn up versus burn down chart" debate, or "evolutionary design."   I had to lure you to this blog post, in fact, by riding on the coat-tails of the Breaking Dawn, Part 1 , premier tonight at midnight.  You aren't interested!   You have heard it all before!  "To write good software, you need to know who will be using it and what they want to accomplish."  Blah blah blah--sounds like something your mom would say.   "Give the roles names, and think of them as people.  If multiple types of people play the same roles, give them different names, and call those things 'personas'"  Now you sound trendy an...

Jim Highsmith recently posited that " velocity is killing agility !" which is kind of a fun hypothesis.  Jim observes that company leaders he talks with around the world these days are a little too quick to measure the effectiveness of their agile software development teams by keeping track of the teams' velocity (the average amount of estimated software effort the team delivers per software delivery iteration). From:  http://startofanadultlife.tumblr.com/post/6847194092/nigel-tufnel-the-numbers-all-go-to-eleven-look This is quite ironic, of course, since one of the rudimentary things you learn when you first study agile software development is that "velocity" is measured in abstract terms like "points," or "ideal hours."  The numbers are relative to each other, and mapping points to time is a fluid process, and only valid to one team at a time.  The idea of tracking velocity is so absurd, in fact, that there is an entire web site devo...

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....

Improvisational comedy techniques have been making their way into agile training discussions for some time.  The UK (and beyond) Agile Coaches Gathering devoted their 2009 autumn meeting to " Improvisation for Agile Coaches ."   Planning for Failure 's amazing Todd Charon did this wonderful lightning talk in 2010.  And this week, Lisa Crispin posted an enthusiastic review of Mike Sutton 's half-day improv session for AgileCoachCamp US. From Del Close's skull's MySpace Page I've always felt happier belonging to the "yes-and" teams much more than the "no-but" ones, but and I wanted to see for myself how improv philosophies and techniques could provide a useful framework for agile/lean software development.  So, inspired by Lisa, here's what I found out. Most inquiries into improv lead to Del Close, granddaddy of Chicago-style improvisational comedy, and co-author of Truth in Comedy:  The Manual of Improvisation .  Del fam...