Skip to main content

Posts

Showing posts with the label agile

Return of the Matrix: The Organization Around the Self Organization

Do you have a group of, say, 100 people, whom you want to organize optimally for a software delivery program?  Martin Fowler is famously on record saying that " scaling agile is the last thing you should do. " A better approach is to try to scale down your project. ...an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive. This brings to mind one of Tom Waite's "non-lethal weapons," the Shrink Ray, in the movie Mystery Men ,.  Aficionados of the movie (or comic) will remember that the ray is "based on simple dry-cleaning technology." From the Blu-ray site:  http://www.blu-ray.com/m...

Patterns for Agile Transformation Success: Agile Enterprise Adoption Without a Gut Rehab

Mike Cottmeyer has re-emerged in the blogosphere, after a bit of a lull, with an electrifying series of posts about enterprise agile, one of which is entitled How to Structure Your Agile Enterprise .  I love the whole series, and especially this post, anchored as it is in Cottmeyer's real life experience: First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year. Is this your enterprise business flow reality??  From http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx Cottmeyer provides some really crucial insights about agile at scale that may run counter to what you believe is "fundamental" to agile: "Feature teams" are not practical, if any given...

3 Reasons Agile is Best in Cynical, Cutthroat Cultures

As agile divas coaches, we are prone to think things like:  "agile is never going to work in a company [like this one] with a horrible, toxic culture. [but I will take the money and give it a shot.  What the hey, it's job security.]."  In fact, "company philosophy or culture" was one of the top two "leading causes of failed Agile efforts" for the 2008, 2009, 2010, 2011, and 2012 "State of Agile" Surveys administered by the Scrum Alliance.  And I don't think the 2013 results are out yet. One pictures the coaches of the world flouncing around in art deco silk wraps and soft curlers waving our collective hands and wailing things about "not being able to work under these conditions!"  It's poison I tell you, poison! From the excellent http://www.theculturedoctor.com.au/blog But let's turn the question around.  If we, as agile coaches, have a preference to work solely with small groups of (kind) super-geniuses in ...

Staffing for Scaled Agile: Retention is Better Than Acquisition

As you begin your large-scale agile transformation, you may find yourself printing out posters of The Big Picture , jack-hammering cube walls into pulp, and negotiating an awesome corporate site license for an Application Lifecycle Management (ALM) tool.  Plus you are likely putting rigorous product management, architecture and continuous integration practices into place, along with test driven development, and automated functional testing, without the last of which you will be completely helpless under your regression load. This is all heady and exciting stuff, and just keep doing it, but I would recommend that as you do, you put staffing at the top of your list of concerns, and put a fair amount of energy into the effort.  The Agile Founding Fathers weren't messing around when they put the words "Individuals and Interactions" at the very top of the manifesto.  Make no mistake--agile lives or dies by the quality, motivation, and communication of the people practicing ...

The Periodontal Probe: A Cautionary Metrics Case Study for Coaches

Did you visit your dentist today?  If not, perhaps it is because in modern dentist offices (at least in the US), a routine dental checkup consists of four key steps: A hygienist grimly and repeatedly stabs your gums with a pointy stick called a periodontal probe (6 stabs per tooth!), and loudly calls out numbers from 1 to 15 with each stab, where anything over 3 means "tooth about to fall out." These numbers, they assure you, go on your permanent record. The same hygienist scrapes some stuff off of the teeth along your gum line, a painful process appropriately known as "scaling." The hygienist gives you a choice of grape, watermelon, or mint toothpaste, and uses that little round tooth cleaning widget to clean the remaining surfaces of your teeth.  They don't say it, but you know and they know that the widget is actually a disguised drill.  The dentist comes in, looks things over, and gives you some summary advice and follow-up requests, like "come ba...

From "Agile" to "Astute:" Value Wrangling Requires Technique

I've been putting my shoulder to a wheel which Jim Highsmith has steadily pushed for a long time, and which Gojko Adzic has started actively evangelizing over the past year or so, which is a group effort to brand, rationalize, and advertise practices to help teams "build the right thing" as a complement to the fairly well established "agile" practices for helping those teams "build things right." Like the Agile Manifesto drafters, who came together in 2001 as established and successful software delivery practitioners, Adzic has brought together some wonderfully talented practitioners into his discussion space, many of whom have already published substantively on the topic.  To name just a few: Adzic himself with his 2013 book, Impact Mapping: Making a big impact with software products and projects , building on his previous explications of specification by example . Ellen Gottesdeiner and Mary Gorman with their 2013 book, Discover to Deliver:  ...

Fire Emblem Agile: The Pair is the New Individual

Like so many of you other senior agilists out there, I'm currently playing the latest entry in Nintendo's "Fire Emblem" series, Intelligent Systems' "Fire Emblem Awakening" for the 3DS (henceforth "FEA")  And I'm sure I'm not the first to notice the wonderful insights FEA provides on Agile software development!  But humor me as I spell it out a little bit. Free!  Fire Emblem Awakening wallpaper from Nintendo:  http://fireemblem.nintendo.com/downloads/ You may not have focused on this aspect of the game when you played it, but the essence of FEA is that the power of the team grows exponentially based on skill with which you, the player, build out the pairing between those characters using the game's new duel system in which you fight cooperatively with nearby comrades .  (This would be in addition to the game's "marriage" system, first i ntroduced with the fourth game in the series, Fire Emblem: Seisen no Keifu,...

In Defense of Mortgage Driven Development: That's Our Target Market, You Goofs!

I was speaking with a group of fellow would-be agile change agents last week, and one of us described "the opposite of agile" as "mortgage driven development."  Of course I found this funny and apt, and I looked it up online, where I found Jason Gorman's tongue in cheek manifesto for the MDD movement online: We are uncovering better ways of making money from software by doing it and hindering others from doing it. Through this work we have come to value: Timesheets and invoices over principles and ethics Unmaintainable software over clean code Contract renegotiation over a barrel Unlimited overtime over a sustainable pace Contracts that fall outside of IR35 over and over again But as I reflected on the matter, I realized I would prefer to describe the above manifesto in terms of "Marauder Driven Development" instead, if we must have a straw man abbreviated to MDD.  Our enemy isn't mortgage-holders with their desire to maintain a sta...

Agile Without Social Engineering

In 2006, Ivor Jacobson famously summarized , "Most important, agile is about social engineering."  And indeed one of the things that makes so many agilists so dar ned loveable is that we are , as a frie nd of mine put it yesterday, "the kind of people who want to create a work place where you can go and still be a human being."  Not a "resource," not an "FTE," but a human!  It's an inspiring dream! http://www.pbpp.state.pa.us/portal/server.pt/community/human_resources/5364/how_to_apply/494613 B ut you kno w what ?  I t's not a goal you can atta ck directly , even if you are, for some reason, under the impression that you're in charge.  In fact, in my view, a lot of us are completely wrong about what the "lead" and " lag" measures are for a successful "agile" transformation of an orga nization . "Lead" measures, you will recal l, are the little things you can observe which reliably indic...