...copyright Elena Yatzeck, 2010-2017

Wednesday, September 29, 2010

Schrödinger's Agile Leader

The "agile team leader" seems at first glance to be a sort of Schrödinger's cat:  if a project team is self-governing, then who is leading it?  If there's a leader, is it self-governing?  Is everyone a leader?  Is "the team" a leader?  What happens to individual responsibility and career development, and who watches over it?  Who makes the decisions?  What does an agile executive look like?  As Martin Proulx captures the issue in the title of his excellent August Analytical-Mind blog posting, "I don't feel so good, I'm a people manager in an Agile organization."  It's interesting to think about.



One way to break this question down is to recap some standard and helpful distinctions in vocabulary.  In the growing field of "leadership training," it has become well understood that a "manager" is not the same as a "leader."  See for example this ChangingMinds.org blog entry.  As managers aspire to become executives, they are sometimes prepared for this increased responsibility by undergoing a specific leadership training which talks about three total roles:
  • Doer:  gets things done
  • Manager:  ensures things get done right
  • Leader: ensures the right things get done
If we apply these terms to the problem of an "agile leader," within the context of an "agile team," we can see immediately that on an agile team, all team members are asked to play the combined roles of "doer" and "manager" for the team, and that being the "leader" is a different role.  In Scrum, the "Scrum Master" would to some degree ensure that things get done correctly, but a Scrum Master would not typically tell a BA, a Dev, or a QA how to do his or her job, but rather help be the conscience of the team in terms of making sure agreed upon Scrum practices were being followed.

In Scrum, the person who decides "what" the software should do would be the Product Owner, and the team might take guidance on "how" to implement the software from a technical lead or software architect.  So on the face of it, the Product Owner and Tech Lead could be considered the leaders.  But hold that thought for a second.

A final, helpful piece of vocabulary is the concept of the "Executive."  Jim Highsmith, who I'm excited to say has joined ThoughtWorks this month, has this helpful list of things agile "executives" can do:
  • aligning agile transformation efforts to business strategy
  • helping teams understand and deliver on business, product, and project objectives
  • creating an agile performance management system
  • facilitating a decentralized, empowered, collaborative workplace
  • fostering an adaptable product line and product architecture
  • creating an agile proficiency framework
  • creating both proactive and reactive organizational adaptation processes
  • understanding the agile development process
  • creating guidelines, training; and support for agile processes, practices, and tools.
But are we there yet?  I think not.  On the ground, knowing the goals, as the PO and the tech lead do for a Scrum team, or even knowing what the strategic goals should be, as Highsmith's agile executive does, is not the same as leadership either. 

I habitually turn to Joe Vranich for advice when I am in need of wisdom, and when I talked with him yesterday, he passed along this quotation from Peter Drucker to me:

“Only three things happen naturally in organizations: friction, confusion, and under-performance. Everything else requires leadership.”

Drucker's name doesn't come up frequently in the agile theory texts I've been reading lately, for a number of reasons (see this lovely Business Week eulogy from 2005), but doesn't this quotation really capture the essence of the problem?  A leader addresses sources of friction, confusion, and under-performance and does something about them.  So coming full circle, in an August 24 post on the Cutter site, Highsmith, too, talks about how leadership comes down to having the ability to reduce ambiguous situations to their essentials:

Agile leaders have the ability to cleave through this ambiguity, to focus on a decision when everyone else is floundering, to clarify direction when everyone else
sees confusion. This requires an ample supply of thought and analysis, but probably an even greater supply of guts.

In the end, I posit, leadership is a fundamentally human excellence.  It is not something which can be captured on a card wall or a burn-up, or guaranteed through daily 15-minute stand-ups.  Leadership is a human trait, and if there's something like a prototypical "Agile leader" we want to be nurturing, that person is going to be deft at working with that other prototypical Schrödinger's cat, the "Agile enterprise" which never quite settles upon whether to be a philosophy or a set of techniques.

Tuesday, September 21, 2010

Agile Fun

A colleague of mine just sent out a link to an exquisite Schumpeter blog in the Economist entitled "Down With Fun."  You must read this blog!  It skewers the concept of enforced workplace giddiness for strategic gain.  In my view, the blogger is unnecessarily grumpy that today's workplace has eliminated the kind of fun they have on "Mad Men," which includes smoking, drinking, and vigorous workplace fornication, but that's just me.

From The Economist, 9/16/2010

What about fun, though?  Should we simply give up on workplace fun?  Is my employer, ThoughtWorks, wrong to make "fun" one of its core values?  The Economist warns that "...as soon as fun becomes part of a corporate strategy it ceases to be fun and becomes its opposite—at best an empty shell and at worst a tiresome imposition."  And indeed sometimes I feel a twinge of irritation as I leap away from a fast-moving oncoming scooter on the carpeting, duck from the path of an incoming beach ball, or put headphones on to avoid the guitar playing ("Kumbay-THIS, you long-haired jerk!" I think to myself, cranking the Mahler). 

The Economist blogger states, "if it's fun, it needn't be compulsory."  I would argue something much stronger than this:  if it is compulsory, it is no longer fun.

In 1905, Freud wrote an extremely long and tedious book entitled Der Witz which can completely spoil jokes for you for the rest of your life, if you read it.  So I hesitate to delve too deeply into the true nature of fun, but this is for a good cause.  There's a super cool web site called Visual Thesaurus which actually visualizes synonyms for you in a little map.  Here's what VT does with "fun:"


On the map, you can see that fun has a dotted line but somewhat distant relationship to "activity," which might include management-purchased oversized My Little Pony plushies in the corporate greeting area and management sponsored conga-line dancing and hat wearing.  VT shows fun much closer to "play" and "playfulness" in common usage.  And as Wikipedia, that font of information correct and incorrect says quite clearly, "Play refers to a range of voluntary, intrinsically motivated activities that are normally associated with pleasure and enjoyment."[1]

The key words here are "voluntary" and "intrinsically motivated."  And they take us right back to the basis of Lean manufacturing and Agile software development:  harnessing the intrinsic knowledge, good will, and power of the people closest to the work for greatest progress and gain. 

I once participated in a Rally training exercise which has stuck with me ever since, whereby we divided into pairs, the "boss" and the "staff person," and the boss had to direct the staff person through a maze.  We timed it, and it turned out when the boss had to provide turn-by-turn instructions to the staff person, it took 2-3 times as long as when the person was empowered to maneuver on her own to an agreed-upon destination.

And indeed my observation is that when you get a group of knowledgeable people in a room, get command-and-control management out of the way, and let the group progress organically towards a well-understood goal, even an evolving one, that is a very fun thing.  If the freedom to take charge of a goal allows people to bring remote-activated tanks, harmonicas, and even handballs into the workplace as well, so be it.  But the gadgets and the behaviors are only symptoms, and you have to be doing the work in the environment to know whether it's fun or just window dressing.

Thursday, September 16, 2010

Value Chains and Value Streams: Strategic Maps Are Better For Project Inception

I was working on some training materials this week, and I needed to whip up as-is and to-be business process maps.  These would be used to help trainees visualize how the software they were going to build in an agile way during the training would transform the fictional business for which it was being written.

I got completely mired down in this seemingly simple task, and I realized it is because the more you think about it, the more the business process mapping for the purpose of planning a software project is just not simple.

BPMN 2.0

If you're like me, you are probably thinking, "well gee, just throw together some circles, rectangles, and arrows, and you're done, what's the big deal?"  Indeed, I started down this track, and in the name of being professional, I spent an afternoon this week familiarizing myself with Business Process Modeling Notation (BPMN, currently at version 2.0).  I became fairly adept at BPMN, which is very nice for creating process flowcharts, and tried out a very cool tool, Lombardi Blueprint, which keeps track of all the arrows for you (as MS-Visio and OmniGraffle do not).  Blueprint also ensures that you create "legal" process flows, which means that each process has a single starting point and a single ending point, and within the process, each box has one or more entering arrows, and only one exit arrow.

Armed with a new knowledge of circles, rectangles, arrows, and a very nice "clock" widget, I quickly mapped all of the business processes relevant to the software process, and thought how handy the flow charts were going to be when planning scenarios and stories for the software
But that's when it hit me--what had I done?!  My "business analysis" was predisposed to think of the business process as a set of manipulations of database objects which could potentially be automated, and the moment I had chosen the BPMN flow-chart as the tool I wanted to use to map the business, I lost focus on the actual business problems which were spurring the need for new software in the first place.  I was describing "as-is" and "to-be" from a systems perspective without providing any particular way to notate why "to be" was going to be better than "as is," except perhaps by showing some rectangles being eliminated through software creation.

Here's where I entered the world Dan Woods describes aptly as "Stalking and Capturing a Business Process."  I didn't want to start with procedural details--I wanted to understand in plain words what the company was trying to do, and where the pain points were.  I wanted to talk about value and strategy.  For this fictional widget company, it turns out, there's an inventory problem customers run into when trying to buy widgets.  You might guess that when you see the clock in the diagram, but the problem doesn't leap out at you.  I wondered whether other maps might do a better job at visualizing pain points.  I found two, which I'll race through here--I think I might need to write something longer one day, to do this topic justice.  (who knew?  I need to write a book!)


Value Stream Mapping

Mary and Tom Poppendieck lay out Value Stream Mapping in Chapter 4 of their awesome book, Implementing Lean Software Development.  For their purposes, mapping should start with a customer demand, and work back from there to show all the steps that lead the company to meet the customer demand.  A business process map looks something like this, and can be developed with a process the Poppendiecks describe, and which is also nicely laid out step-by-step in Ron Periera's Lean Six Sigma blog:

Note that this value stream map focuses on things which occur which impact the cost and timing of delivering goods or services to the customer, focusing on the customer.  Although it may be necessary, in Periera's example, to eventually create and describe an object model which includes customers and peanut butter sandwiches, creation of a flowchart which traces the movement of those objects is secondary to this first business process map, which looks primarily at strategic value and what may be getting in the company's way in delivering it.

Value Chain Mapping

Value Chain Mapping was first developed by a Harvard professor, Michael Porter (and in fact you can find out a lot about it by doing an internet search on "Porter Value Chain." )  Value Chain Mapping provides a more rigorous checklist of topics to evaluate in mapping business processes, and is likely appropriate when looking at a larger company than my widget store or Periera's peanut butter sandwich factory.  Porter formalizes the different areas which come into play with any company of size, in delivering a product or service to a customer.  Like value stream modeling, value chain modeling looks at the process that takes raw materials and converts them into something beyond what the customer could build for himself without help, and evaluates where and how value is added.  Here's Porter's scheme:



There's quite a good free web site describing value chain analysis here.

The Bottom Line

I apologize for flying through this quickly, but I wanted to put a bit of an outline out for people who are interested--the bottom line is that the type of mapping you do will heavily impact the way you think about problems.  As usual, I'm pushing tools which may help us to think more about strategic business value, at least at first, during project inception, and less about the systematic steps to improve it.

Author's note:  It's no coincidence that BPMN is embraced first and foremost by software engineering companies like Oracle who can handily map it to Business Process Engineering Language (BPEL), and thereby create the framework for a Service Oriented Architecture (SOA) software solution.  Further, it's no coincidence that the BPEL created this way is generally described as "not human readible," and that nobody has come up with a way to map BACK from BPEL to BPMN.  I would like to think that it simply stands to reason that the governing body which owns BPEL and BPMN (and UML, for that matter) has the acronym OMG.

Friday, September 10, 2010

Using Agile to Optimize Value of Projects

I was asked recently for guidelines on "how to use value points in agile projects".  I was glad to get the question, since some people, like the blogger who writes "Agile 101," say stuff like: value points are "not appropriate or particularly necessary in all cases."  Gah!  The Agile 101 author actually goes on to do quite a nice job describing how to use value points, and I recommend you visit the blog, but I would like to explain why I don't think all of this is an optional nicety.

If you were CEO of your company and you were being briefed on your project every two weeks, what do you want to hear from your agile team?
  1. "We delivered 14 value points this iteration" (which translates into some specific thing the company values, in terms of cost avoidance, expected revenue within a portfolio, increased quality, or faster time to market)
  2. "We delivered 14 story points this iteration" (which translates directly into "2 weeks of effort")
I think the answer is pretty clear.

Jim Highsmith first published details of this proposition in this blog entry on the Cutter Consortium site, and expands on it in the second edition of his watershed book, Agile Project Management.  In his book, he also expands on this concept of the "Agile Triangle" of Value, Quality, and Constraints, which replaces the traditional Project Management Triangle of Cost, Schedule, and Scope.

From Highsmith, Agile Project Management, Second Edition, 2009.
Highsmith's proposition is that when your company embarks on a project, you are making a financial investment in order to produce something of value to the company.  That value has two dimensions:
  • Value (extrinsic quality), which must be determined by the people in your company who are going to use the new software to create revenue for your company.  They will sell the software, or sell the things the software help them to build, and they should have an idea from market analysis and company strategic goals why they want to spend money on the project at all, and how much money the project is worth to company owners (stockholders, public bodies, or a private individual).
  • Quality (intrinsic quality), which must be determined by your software architects.  They will maintain the software you are building over time, and their goal should be to minimize the cost of this maintenance over time.
Product managers can predict the revenue your company will gain from completing each feature of the project, and architects can predict the revenue your company will lose over the projected lifespan of the project by cutting corners in design at the outset.  "Cut corners" in design are what Highsmith and others call "technical debt."  Bad software is a hidden cost waiting to hit your company in the future, when you suddenly want to do something new and find you can't do it without starting all over, because what you built isn't flexible.

So as a company invests in a project, it should maximize the immediate and long term value from that investment, while operating within the constraints of cost, time, and potential features to be included.

Okay, you say, I feel motivated today.  I want to maximize my project's value, not just track the cost of the effort to deliver it at full scope.  How does that work?

Here are some mechanics:
  • For each project, assign an IT Lead to monitor what Jim Highsmith and others call "technical debt," so that as the software is developed, expected costs of maintenance do not cut into the financial values being tracked by the Product Owner.
  • For each project, assign a Product Owner, a decision maker whose job it is to predict, record, and then update the business value parameters for the project.  These consist of:
    • Project value:  the overall value of a planned software project to your company (predict at project inception, and update before each release planning meeting as needed).  This can be a financial return on investment, or some other appropriately quantified measure, such as increased speed to market, increased quality, or avoidance of future costs.  Cost avoidance could include such factors as regulatory compliance to avoid fines or building software to allow something new to be done in an automated way, rather than taking on new staff. 
    • Feature value:  the relative value of each requested software feature which is planned as part of the overall project (predict during project inception and update before each release planning meeting as needed).  Feature value should be determined through a method such as planning poker, which allocates value to specific features on a relative basis.  So the Product Owner should gather the right people together to think about the expected high level features of the project, and assign a "points" value to each feature.  Once a sum of points is established, that can be mapped to the overall predicted financial value of the project as a whole, and each value point is worth some fraction of that overall value.
    • Story value:  the amount of feature value delivered by each story, where each feature is divided into stories which can be delivered in 1-5 days.  The rule is that the story must provide some recognizable business value on its own.  (Assign as stories are carved out of features, during release and before or during sprint planning).  After the team determines which features should be targeted for a release, the first features to be delivered within a release should be divided into stories which deliver some proportion of the feature's business value in their own right, end to end.  Stories should be things which can be completed within a sprint.
You can readily see that once you are tracking value at project, feature, and story level, you can do a whole bunch of excellent things, each of which optimizes your company's bottom line:
  • Plan your portfolio:  now that you know the overall expected return on investment of a project, you can weigh that project's risks and potential returns and determine when to make it part of your active portfolio.
  • Speed up and maximize the return on investment for all of your projects:  each project is executed as a series of releases which have the most valuable features in the earliest release, and the most valuable work delivered earliest within each release.
  • Graphically track the value delivered by the project during each sprint and for whole releases, using a "value burn-up," (exactly like an "effort burn-up," but measuring something a lot more interesting to your CEO)
  • STOP your project once you get decreasing returns on investment, in favor of starting a different project in the portfolio which has higher-value features still to be delivered.
  • Collect returns on the working software through the expected lifespan of the design and beyond.
One final point.  Agile software development is premised on avoiding "Big Upfront Design" (BUFD), and so projects are started with some minimal inception phase to lay out an initial architecture design and an initial effort estimate.  All designs and estimates are expected to change over the course of the project as more is learned.   

Value points should not take years to estimate any more than your effort points do, even though they result from different techniques.  Do not leap out of the frying pan of the BUFD into the fire of Big Upfront Value Modeling (BUVM, sadly not pronouncable). 

Your decision-making Product Owner should try hard to limit the time she spends estimating its value.  Just as you shouldn't "start coding" on day 1 of an agile project, you shouldn't "pick a number out of a hat" as your business case.  But neither should you over-analyze, since you expect to be enhancing and revising your business case as the project proceeds.  And of course the market is going to be changing during that time anyway!  So as the project unfolds, the Product Owner should plan to revise the overall predicted project value and value of desired features on a regular basis, and the whole team should plan to adjust release plans appropriately as they go.

The main point is that value points, like their better known cousins, effort (or "story" points), can and should be estimated, written down, adjusted, and used for planning and reporting purposes by project teams.  They can be estimated in Planning Poker, burned up, burned down, and written in the upper-left-hand corner of your story cards.  ONLY value points, however, can tell you how well the project is returning on investment.  And that's why I don't think they're ever optional.

Wednesday, September 8, 2010

Slaying the Agile Scaling Lycanthrope with A Barrage of Silver Bullets, er Maturity Models

Scott Ambler became my new hero in an instant today when I reached the conclusion of his dazzling Scaling Agile: An Executive Guide, published on his Agility@Scale blog site in February, 2010, where he refers to corporate productivity challenges as "lycanthropes." [p. 19, if you want to skip right to it.]

I had been hoping to write about scaling agile to large organizations today and will doubtlessly do so immediately, heavily referencing Ambler, whose blog you really must visit early and often.  But I hadn't heard the word lycanthrope before, and I just had to pause and marvel at the aptitude of the metaphor, in a way I haven't done since I encountered Dan North and Martin Fowler describing the relationship between business and technical people in a software endeavor as the "Yawning Crevasse of Doom." 

If agile enthusiasts gain any traction at all in this world, and apparently we are (Ambler quotes a survey showing that 76% of American corporations were at least experimenting with agile techniques in 2009), I would like to think it's because we are so frequently able to reap a fiscally significant corporate harvest from the hours of effort we've invested in the colorful worlds of J.R.R. Tolkien, StarCraft II (Wings of Liberty) and DragonQuest IX (Sentinels of the Starry Skies).

Back to the point, however, as agilists, we seem to have moved on since Martin Fowler's 2003 keynote on "Why Scaling Agile is the Last Thing You Want to Do."  Although his advice to "scale down projects" before "scaling up agile" is still true, by 2009, would-be organizational transformers had produced so many models to describe agile at scale that InfoQ had to publish a roundup.  The models annotated are either prescriptive, like CMMI or PMI, or purposefully heuristic and descriptive, as proposed by Ross Pettit

Now that the dust has settled a little and Ambler has produced his own model, I thought it might be time for a look at what he and two other practitioners offer, and how their models can help:
  • Ambler's Agility Scaling Model (ASM), referenced above.  Ambler's bottom line advice is going to be to retain IBM's Global Services and Rational teams to embed experts into your organization and help with the specifics of applying the model to your situation.  The framework itself is awesome in its own right, however, suggesting an evolution from:
    • "Core Agile Development" (a team iterating) to 
    • "Disciplined Agile Delivery" (an IT organization delivering a business solution from ideation to money-making production), and finally to 
    • "Agile at Scale" which describes a whole IT organization operating in an agile manner for all projects across all necessary continents.
A blurry approximation of Ambler's original.
  •  An earlier and also highly regarded framework has been developed by Ahmed Sidky and Greg Smith, and is included in their excellent book, Becoming Agile in an imperfect world.  The model, called the Sidky Agile Measurement Index (SAMI), is one which Sidky would ideally like you to engage his company, X2A Consulting (recently acquired by ubroadcast, inc), to help apply to your organization, but Sidky and Smith provide detailed information about how to do this for yourself in Appendix A of their book, "Readiness assessment tables by practice."  The book as a whole provides a helpful reference narrative describing steps you might go through in your own organizational transformation.  Like the ASM, the SAMI does not lend itself to intra-blog rendering at readable scale, but here is roughly what it looks like:
From Becoming Agile in an imperfect world--read the original!
  •  Michael Spayd has an interesting perspective on corporate agile conversions, and has developed methods for implementing XP within the framework of the CMMI, for companies who need to do so.  More recently, however, he has developed an agile-specific Seven-Layer Framework which usefully lays out the different layers of the organization which need to be addressed in order to successfully transform it.  Spayd, like Ambler and Sidky, can offer guidance on use of the framework through his company, CollectiveEdge Coaching.  Spayd's framework is useful in the way it helps you devise appropriate strategies for transformations of different demographics within a corporate environment:
    • Individual
    • Team
    • Management
    • Program
    • Strategy
    • Leadership
    • Organization
From Spayd's Agile 2009 Presentation -- read it in full!

The available published 2010 maturity models have in common that they do not provide a point-by-point guideline as to how to change your organization.  As my brief descriptions above suggest, the owners of these models want you to hire them, and there are other companies out there who have their own proprietary models as well.  And that is a good thing. 

Returning, as is my wont, to the Agile Manifesto, I suggest that organizational transformation, like so much in life, is going to be about a relationship between an owner of a corporate productivity problem of some size and one or more people who are going to help that person solve it.  We in the agile community, both suppliers and demanders of advice, are going to want to educate ourselves on different ways to think about the problem, and apply different lenses to evaluating how things are going.  In the end, maturity models won't increase corporate productivity, just as surely as silver bullets don't kill werewolves.  You need people to slay both figurative and literary lycanthropes.