Skip to main content


Showing posts from 2011

Choose Your Online Personal Brand Persona

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!

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, and most blogging sites so that your content is viewable solely by p…

Samsung Galaxy Tab 10.1 Review

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.

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 life of your device?  What applications are available to he…

The Product Owner is a Metaphor Too

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, specifically whe…

Just In Time Software Requirements: Introducing "Value Spikes"

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?

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 teamThe PO must be able to provide one reliable set of priorities which reflect acquiescence among all of the PO's hori…

BDD, Feature Injection, and the Fallacies of Product Ownership

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?

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 the software will meet the needs of its intended users. This means the customer team may include testers, a prod…

Roles with Teeth

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…

Agile Velocity: The Numbers All Go To 11

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).
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 devoted to the concept of estimation using fruit (cherry for very small amounts of effort; watermelon for large amoun…

Iteration Showcases for Backend Systems

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.
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 going to "go agile!"  A perky trainer, most l…

Business Analyst Corner: Write Later, Not Less

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.
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 that change in timing, reduce the work you will spend as a BA filing and executing change requests, and r…

Next-Gen Agile: Demote the Non-Coders?

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 of that song…

Life Before Iteration 1

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.

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 working software."  He cited George Dinwiddie, Alistair Cockburn, and Ken Schwaber, conc…

The Full Monty: the Continuous Delivery Business Case at Scale

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

And yet i…

Eleven Improv Commandments for Agile Teams

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.

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 famously bequeathed his skull to Chicago's Goodman Theater, to…