LeadingAgile

Interesting Post... 7/4/2010 through 7/11/2010

2010-07-11T18:37:00.005-04:00

Today is the last day of our beach weekend. The kids were pretty much over the beach after the first day. Their Mom grew up on the beach and can sit there for hours on end enjoying the sun and surf. I don't think the kids got that gene. I told my 8 year old that if he tried to have fun today, I'd let him bury me in the sand. I was hoping he might forget... he didn't. I spent about 30 minutes trying to get sand out of places where sand should never be!

As you can see from the length of this post, I continue to be extremely pleased with the performance of the Dlvr.it service. It's better than Twitterfeed ever was... even when it was working it's best. I go through a lot of blog posts every week, it kind of makes me sad how many were never getting out to you guys. It always seemed like I was reading and sharing more than would come up in these summaries... and now we know why... so anyway... it's fixed... I'll stop dwelling on it... really... I will.

Enjoy this week's installment of Interesting Post...

Interesting Post... Twitter Weekly Updates for 2010-07-11 http://dlvr.it/2WnrT

Interesting Post... So easy to talk about lunch http://dlvr.it/2WY3V

Interesting Post... Insubordinate... 50th anniverary free ebook http://dlvr.it/2VSyB

Interesting Post... What Does $35 Billion Look Like http://dlvr.it/2V59q

Interesting Post... Assessing Agile pilot projects http://dlvr.it/2V59t

Interesting Post... Changing Agile Roles - The Programmers http://dlvr.it/2Sq2m

Interesting Post... Elements of Project Controls http://dlvr.it/2SVTc

Interesting Post... Tell People a Story http://dlvr.it/2SVTd

Interesting Post... New “Agility Now!” Newsletter http://dlvr.it/2SNmc

Interesting Post... PMBOK 5 - Rejected http://dlvr.it/2SNjr

Interesting Post... The Art of Agile Development: Incremental Requirements http://dlvr.it/2SNfh

Interesting Post... Beware Bloated Processes http://dlvr.it/2SNcH

Interesting Post... Quote of the Day - Complexity http://dlvr.it/2RVqR

Interesting Post... Yes I am mocking you http://dlvr.it/2RVpz

Interesting Post... Agile and Re-Engineering http://dlvr.it/2RVpY

Interesting Post... Should We Build It Again? http://dlvr.it/2RVnl

Interesting Post... Dr. Seuss Inspired by Personal Kanban http://dlvr.it/2R9fW

Interesting Post... Defining Program Management and How Agile Helps http://dlvr.it/2R7w8

Interesting Post... SCRUM vs. Kanban it’s like Football vs. Soccer http://dlvr.it/2QvdH

Interesting Post... The path to software Craftsmanship http://dlvr.it/2QvdJ

Interesting Post... Agile & Culture: The Results http://dlvr.it/2Qt2b

From Leading Agile: Okay… Just What are we Transforming? http://dlvr.it/2QsdN

Interesting Post... Physical Percent of Planned Progress http://dlvr.it/2Q3SM

Interesting Post... Lean or Six Sigma? http://dlvr.it/2Pd5J

Interesting Post... Our Divisive Scrum Terminology Needs to be Deprecated http://dlvr.it/2NxNY

Interesting Post... Musings About Agile Program Management http://dlvr.it/2My3p

Interesting Post... The Fourth Career Mistake... http://dlvr.it/2MxsX

Interesting Post... Agile and Technical Complexity http://dlvr.it/2Mxch

Interesting Post... Defense Industry and Scrum http://dlvr.it/2Ms3t

Interesting Post... Bad Requirements? Actually, That’s Your Fault http://dlvr.it/2MnF3

Interesting Post... 1 FTE http://dlvr.it/2M582

Interesting Post... Software Calculus - The Missing Abstraction. http://dlvr.it/2LxFd

Interesting Post... Object-Oriented Design and Mock Objects: for non-programmers http://dlvr.it/2Lx3v

Interesting Post... Types of Scenario Tools http://dlvr.it/2Lx3t

Interesting Post... This Is Why The Kindle Is Winning http://dlvr.it/2LFG5

Interesting Post... Measuring Progress - What Can We Use? http://dlvr.it/2LF61

Interesting Post... Design-Build-Run http://dlvr.it/2LF0N

Interesting Post... The Limited Red Society – Joshua Kerievsky http://dlvr.it/2Ks5L

Interesting Post... 3 Aspects of Team Boundaries http://dlvr.it/2Ks2G

Interesting Post... How to do agile when we only have 50 crap developers? http://dlvr.it/2KGWP

Interesting Post... VIDEO: "I've already got the prize. The prize is http://dlvr.it/2Jk7j

Interesting Post... Four Type of a Program Management Office (PMO) http://dlvr.it/2JQyF

Interesting Post... Silos Aren’t Evil: They’re Just Icky. http://dlvr.it/2JJ3C

Interesting Post... The A - Z of Agile - W is for: http://dlvr.it/2J2RT

Interesting Post... Happy Independence Day! http://dlvr.it/2HzzC

From Leading Agile: Southern Fried Agile Conference... It's Gravy for your Brain! http://dlvr.it/2Hx3Q

Interesting Post... A Day of Independence http://dlvr.it/2HppL

Oh by the way... did I tell you about this great new service I found called Dlvr.it? You should try it out ;-)

Okay... Just What are we Transforming?

2010-07-08T10:06:00.003-04:00

I'm constantly reminded that context is king... that words have meaning... and that the meaning of our words is almost entirely dependent on our context.

Last night I had coffee with an agile coach here in the Atlanta area. We got to talking about the idea of 'agile transformation'. It became pretty clear, pretty quickly we were using the phrase in two very different ways.

His perspective was that 'agile transformation' involved taking a project team, teaching them agile values and agile practices, and helping them deliver better products to market faster, and with higher quality.

Worthy goals... no doubt.

My perspective on agile transformation looks a little different. To me, agile transformation involves influencing the structures and culture around the team. Only by influencing the systems around the team, can we achieve true end-to-end business agility.

Meaningful, long-lasting agile transformation starts by establishing a clear vision for the organization, and how we want it to operate when we get there. It involves creating a change management strategy that will get us from here to there as safely as possible.

Without transforming the organization around the team, the transformation within the team won't be sustainable. The forces that act on the team are often too great for the changes to stick. It's too easy to go back to the old way of doing things.

It helps to understand just what we are trying to accomplish with our agile transformation. If we just want to get a project team really humming... team transformation might be enough to meet our goals.

If we want ongoing, sustainable business benefit from our investment in agile, we are going to need to think beyond the team. We are going to need to think about the rest of the business and how we collectively deliver value.

No right or wrong here... you just gotta be realistic about what you are trying to accomplish.

Southern Fried Agile Conference... It's Gravy for your Brain!

2010-07-04T10:27:00.009-04:00

I wanted to let everyone know about a new regional conference coming up on July 23rd. The conference is called Southern Fried Agile. Pillar is sponsoring and helping organize the event in partnership with the Agile Carolinas group. The conference is featuring many of the premier Agile Coaches in the Southeast. We'll have three tracks... one for those learning agile... one for more advanced practitioners... and an open space so you guys can get in on the action.

Speakers and Talks:

Mike Cottmeyer - Getting Started with Agile
Bill Gainennie - All That You Need to Know is that It's Possible
Joe Little - What's Lean Got to do with it?
Dennis Stevens - Using Agile and Lean to Lean Business Transformation

Paul & Ian Culling - Collaborative Chartering and Story Mapping
Bill Krebs - 10 Years of Scrum Meetings
Jared Richardson - Agile Testing Strategies
Mike Cottmeyer - How to Own a Really Big Complex Product

Head over to the Southern Fried Agile site for more information about the conference, the sessions, and our speakers. We've also got a link for you guys to register... and at only $49 for a full day of agile goodness, you'd be crazy not to make this happen! If you are within three or four hours of Charlotte, NC... this is a must attend event.

Remember... It's Gravy for Your Brain

Interesting Post... 6/25/2010 through 7/4/2010

2010-07-04T09:51:00.006-04:00

Hey everyone. It is a great week for my Interesting Post... updates. I finally gave up on Twitterfeed and went to dlvr.it. This new service is faster and more accurate that Twitterfeed ever thought about being. I finally have confidence that all the stuff I share in my Google Reader feed is making it out to the Twittersphere. I'm guessing that you'll notice the list here is longer than usual... now you know why.

Anyway... for all you guys in the US, happy 4th of July! My family has started a series of traditions around this holiday that I think are really fun. The kids and I got up early yesterday and drove to South Carolina to buy some fireworks. The really good fireworks are illegal to sell in Georgia, so the good people of South Carlolina provide stores just on the other side of the border so we don't have to drive too far.

The past few years, our tradition had been to cook many, many pounds of baby back ribs. We changed it up this year and made a shredded BBQ concoction of beef, pork, chicken, sausage, and bacon... plus my secret blend of sauce and seasonings. Very tasty.. we made it yesterday, but I'm really looking forward to leftovers later this afternoon. We did the whole fireworks thing last night and have plans to spend the evening with some good friends and launch the fireworks we got yesterday in South Carolina!

Have a great day and enjoy this weeks installment of Interesting Post...

Interesting Post... A Day of Independence http://dlvr.it/2HppL

Interesting Post... Organizational Complexity http://dlvr.it/2HHGN

Interesting Post... Who’s Got Your Back? http://dlvr.it/2H0VX

Interesting Post... Microblogging in Project Management 2.0 http://dlvr.it/2GMmT

Interesting Post... My Three Biggest Career Mistakes http://dlvr.it/2Fm4X

Interesting Post... Agile Metrics http://dlvr.it/2Fhp6

Interesting Post... The Southern Fried Agile Conference is Coming! http://dlvr.it/2FLqT

Interesting Post... How to be a Bad Manager http://dlvr.it/2FCMh

Interesting Post... How to improve a team's velocity http://dlvr.it/2Dzp1

Interesting Post... The difference between running and managing a project http://dlvr.it/2DkFF

Interesting Post... Which Compliment Do You Want? http://dlvr.it/2DfK3

Interesting Post... Agile Friday: "The Planning Game" Now Online http://dlvr.it/2DfBL

Interesting Post... Big Bang vs Evolution – A software look http://dlvr.it/2DBSs

Interesting Post... Agile 2010 – The words we use http://dlvr.it/2DBBw

Interesting Post... The Phrase That Should be Banned from Product Managers’ Vocabulary http://dlvr.it/2CwdK

Interesting Post... How can you know you're headed to the Ditch? http://dlvr.it/2Crsb

Interesting Post... Guest Post: Not Putting Out Fires http://dlvr.it/2ChgR

Interesting Post... TDD and Agile – What Does the Research Say? http://dlvr.it/2ChMc

Happy Day!!!

Leading Agile... Agile Atlanta in July... Dennis Stevens and Kanban! http://goo.gl/fb/RkDce

Interesting Post... New Chapter – Use Cases http://bit.ly/92URe0

Interesting Post... 19 Feeds for ProdMgmt, Product Marketing and Marketing Operations types: http://bit.ly/aOM5XY

Interesting Post... It’s The Values That Matter. Or Maybe It’s The Culture. http://bit.ly/cz0UQp

Interesting Post... Shorten and Reduce Variability in Lead Times using Kanban http://bit.ly/9ZB5me

Interesting Post... Refactoring with Fire http://bit.ly/agWuGK

Interesting Post... The Notion of a "Master" http://bit.ly/bXL6BU

Interesting Post... Web services in Java http://bit.ly/cnbjU0

Interesting Post... Ten Rules of Common Sense Program Management http://bit.ly/asxYow

Interesting Post... Define: ScrumMaster http://bit.ly/aqSKQZ

Interesting Post... The Art of War - Chapter 2 - Entry 1 - Knowing the Cost*"To http://bit.ly/aSTOuO

From Leading Agile: Ro-Sham-Bo... Shoot! http://bit.ly/9Zp8fH

Interesting Post... Always have a plan B when negotiating http://bit.ly/bHuuYG

Interesting Post... "Heavy Use of Math Puts People Off" http://bit.ly/aeYo5I

Interesting Post... Book Review: Your Career Game http://bit.ly/9gYZve

Interesting Post... Video: Kanban for Video Game Development http://bit.ly/9Zo92C

Interesting Post... New Trends In The Project Ecosystem http://bit.ly/9Z0ws0

Interesting Post... The Declaration of Interdependence http://bit.ly/aTHjGH

Agile Atlanta in July... Dennis Stevens and Kanban!

2010-07-01T15:03:00.002-04:00

Next Tuesday, July 6th, Dennis Stevens will be teaching us how to get started with Kanban.

Speaker: Dennis Stevens
Date: July 6th, 6:45 PM
Location: Matrix Resources, 115 Perimeter Center Place, Suite 250 (South Terraces Building - facing Dillard's at Perimeter Mall)

Learn what Kanban is and how to implement it on your teams. Kanban Software Development focuses on the flow of work to lower delays to delivery and increase quality. It provides significant visibility into how a team works, enabling evolutionary improvement and an improved relationship with management. Kanban can be used in a wider range of environments than many Agile methods because of its ability to be tailored. It also compliments existing Agile methods as it scales beyond the development team and across more complex efforts. There will be plenty of time for Q&A to learn how Kanban may specifically fit into your environment.

Upcoming meetings:
August 3rd: Mike Cottmeyer, How to Manage a Really Big Complex Product

Ro-Sham-Bo... Shoot!

2010-06-28T14:32:00.005-04:00

I had a fun experience last week that I want to share with you guys. It was my first week with an awesome new client. The plan was to start with two days of general agile training, followed by a day of release planning workshops, and then iteration planning. Once the team starts sprinting, I'll come back for a day a week to do a little coaching, and to help keep everything on track. All in all, a pretty standard engagement.

This team has a solid product vision, and a pretty good understanding of their features and needs. The features and needs were pretty easily translated into high-level, value driven epics. We spent some time breaking down the first set of features into finer grained user stories. Because the team was new to agile, and really had no idea of their capacity, we took the extra time to break their user stories down into tasks.

Okay, so you guys know the drill. User stories get estimated in points, tasks get estimated in hours. We decided to use the Fibonacci series for the user stories, but the team wanted to use a binary sequence for estimating task hours. I'm okay with either... and since it's really not my call... we went with binary. The only problem was that we didn't have enough binary planning poker cards so that the entire team could get involved. We had to get creative.

The ideas came quick, but what we ended up with was a version of the old rock-paper-scissors game. Someone realized that each of the allowable estimate values, could be represented as a single digit, using a power of two...

1 = 0
2 = 1
4 = 2
8 = 3
16 = 4
32 = 5

...and, we could each vote with one hand by throwing the exponent, rather than the entire estimate value. Only, in a room full of software developers would someone come up with that. It was elegant... it was geeky... we could do it without supplies... so we went for it.

Since there was no way to hide your estimate using fingers (say, by putting the card face down on the table) the developer leading our session introduced the rock-paper-scissors idea. But... rather than saying rock-paper-scissors-shoot... he went with Ro-Sham-Bo-shoot. I had never heard that version, but once again... it was funny... it was geeky... and the team loved it... so it stuck. Each time, after they talked about a task, someone would look around and ask... 'rochambeau' ?

Once everyone agreed... they played their hand... literally.

It was an awesome... fun... emergent experience, and we came up with a new approach that I am sure I'll want to use with other teams. The estimating went really fast, faster I think than messing around with physical cards. Either way, it was a great team building experience. It was a creative and effective way of playing planning poker. I'm curious if anyone has every played planning poker this way? Is it documented somewhere?

If you happen to be interested... here is a link to the Wikipedia entry for Rochambeau.

http://en.wikipedia.org/wiki/Rock-paper-scissors

The Urban Dictionary had a much more colorful explanation... this one made me laugh out loud.

http://www.urbandictionary.com/define.php?term=ro-sham-bo

Give this approach a try and have some fun with it!

Interesting Post... 6/14/2010 through 6/20/2010

2010-06-20T17:57:00.005-04:00

Okay... so get this. When I go to my Google Reader feed and look at all the stuff I've shared over the past week, I get one list. When I go to my Twitter page and pull all the 'Interesting Post..' articles I've shared over the same time period... I get a different list. There is some overlap but neither is a subset of the other. My guess is that what I've actually shared over the past week is a superset of both lists. Oh well, again... maybe one day I'll spend some time trying to figure out what's up. Either way, this is a pretty good list of all the stuff that I noodled through over the past week.

Hope you like this week's installment of 'Interesting Post...'.

Corporate stuff http://bit.ly/caURkK

PMBOK, Agile, and Some Tips http://bit.ly/bA10TB

Connecting the Dots to PMBOK http://bit.ly/aQXo1w

Are things getting to complicated? http://bit.ly/93cV9r

8 Habits of Highly Excellent Bloggers http://bit.ly/cnIbX5

Getting Ahead, Really? http://bit.ly/cSG3D1

8 Transformational Leadership Lessons From Seth Godin http://bit.ly/dcdLxA

Stop Whining and Get Started! http://bit.ly/aWtuJZ

What Does It Mean to Be Agile? http://bit.ly/daoMJc

Using Agile To Scale Agile – Part 1 http://bit.ly/cbMJ3M

Fridays Digest #18 Scrum vs. Kanban http://bit.ly/968w3L

The Pepsi Challenge of Waterfall Agile or Kanban http://bit.ly/clDBr7

Agile in Everyday Life http://bit.ly/8ZJNly

Your Software is not a House http://bit.ly/a98OPH

Scrum and the PMBOK http://bit.ly/daxNlc

New to agile? Learn how to fail well http://bit.ly/d6wVj3

The Context Machine: The Essence Is Context http://bit.ly/adHbT3

T-Shaped People http://bit.ly/92aQK9

Change Without Motivation http://bit.ly/c7amuo

Come Play Innovation Games for the Agile Developer Skills Project! http://bit.ly/c5omCk

ScrumMasters Now Earn More Money Than Project Managers http://bit.ly/92ahVw

Kanban: What are Classes of Service and Why Should You Care? http://bit.ly/aodC4t

The Oath of Non-Allegiance http://bit.ly/91Pxhh

Your Product Is Done http://bit.ly/dmn9aT

And as an added bonus for making it all the way to the bottom of the post... here is my last update from summer camp. I am home now, we came back yesterday, but the last night I did an update was Thursday. I feel a little guilty for not doing one the last night, but I got back to camp late and we had a campfire to go to. Anyway... this is Day #5... Family Night!

Let's Define Our Starting Place

2010-06-16T21:26:00.003-04:00

I'm telling you guys... if you're not participating over on the AgilePMI Yahoo! Group, you are missing out on some great conversation. Think about it... this is THE issue going on right now impacting the agile community. We talk about agile and transformation... but the traditional establishment holds the keys in most of our organizations. Unless we can show them how to transition safely, we are relegated to bottom-up, grass roots agile initiatives... most of which have a very low probability of making any kind of meaningful difference in our companies.

That said, one of the problems I think we have... not just on the Yahoo! group, but as a community in general, is that we often talk past each other on pretty key issues. I was going back and forth with Dan Mezick and Dennis Stevens on the idea of team authorization. All of a sudden it dawned on me that Dan and I agreed in principle on where we wanted to take the organization, but Dan wanted to discuss the organization as it should be... I wanted to talk about the organization as it was, and how we can be successful in it.

It seems to me, that in any conversation, we have at least three possible starting points for debate:

1. The current state
2. The future state
3. The transition state

My guess is that most people in the group agree that something is wrong with the current state of software project management. That is why they spend time reading and posting and exploring how to do things differently. I'd also guess that most folks in the agile community agree on the ideal end state. We might have some differences of opinion around Scrum or XP or Lean or Kanban, but I think we all value the idea of empowering teams, respecting individuals, and helping organizations deliver the most value possible.

Some of us are so passionate about the way things should be, that point of view becomes the starting place, and they argue for change right now. Others of us have heard those messages and found that they don't resonate given the current regulatory climate in our companies. These people want to talk about what they can do today... without some sort of massive transformation. They don't have any clear way to make the kinds of changes that the 'future state' people are advocating. Others, like me, want to talk about how to get from point A to point B as safely as possible.

Understanding the point of view from which the other person is arguing from can be really valuable as we're trying to move this discussion forward. I hate seeing us run in circles with each other when there is probably more we agree on than we really think. The futurists hold the vision, the today people have the current reality, and the transition folks want to find a way to bridge the two. Maybe if we can start our conversations by clearly stating our starting point... and have more meaningful discussions around all three different viewpoints... we might have a way of moving this thing without constantly going around and around, without ever really increasing our understanding.

By the way... here is a link the Agile PMI group if you are interested in joining the conversation:

http://finance.groups.yahoo.com/group/pmiagile/

Oh, by the way... here is day #3 and day #4 of Summer Camp... have fun!

Summer Camp Day #3

Summer Camp Day #4

Fundamental Attribution Error

2010-06-14T19:29:00.003-04:00

Anybody ever heard of this phenomenon? Here is the definition from Wikipedia:

In social psychology, the fundamental attribution error (also known as correspondence bias or attribution effect) describes the tendency to over-value dispositional or personality-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors. The fundamental attribution error is most visible when people explain the behavior of others. It does not explain interpretations of one's own behavior - where situational factors are often taken into consideration.

When we talk about methodology and roles, how often do we attribute to the methodology... or the role... some sort of evil bias? How easy is it to dismiss traditional project managers as command-and-control, when in reality, these people are doing the best they can, given the situation in which they find themselves? Do we acknowledge that these people are only doing what the organization expects of them?

How often do we give a failed Agile project a pass, maybe on the basis that they 'tried' or were 'fighting the good fight', but view every failed waterfall project (and the traditional project manager running it) as incompetent? Do we ever acknowledge that people in these projects might just be playing the hand they were dealt? Working within the system they were hired to support? That the very structure of the organization around them accommodated no other way of moving forward?

If we want people to behave differently, we have to be able to influence the systems that are driving their behavior. I'm telling you guys, much of what we talk about in the agile community does not play well in the environments where many traditional project managers find themselves. Company culture and organizational structure drive behavior. Until you address those fundamental structures, meaningful change will be hard to come by.

The problem isn't the people involved, or even the leadership... the problem is the system in which those people are operating within. People want to be successful, but if the system around them is not conducive to empowerment and self-organization, people are going to change until the system changes. Authorized teams, without the appropriate organization to support that authorization, will expose both the company and the individual to an unacceptable level of risk. We've got to acknowledge that risk and help people deal with mitigating it.

(Those last two sentences were for you Dan!)

More scout stories from our brutally hot week... I think my 14 year old son has gone insane... Watch out... this clip is PG-13!

Interesting Post... 6/6/2010 through 6/13/2010

2010-06-13T21:17:00.004-04:00

Okay... so this has been one HOT Sunday afternoon. Today is the first day of Boy Scout camp... our annual trek to a really HOT and humid place to spend the week living outdoors. It was about 96 degrees today and probably about 96% humidity. I smell like a barn animal, there are showers, but that squeaky clean feeling DOES NOT last long.

Fortunately, there is an administrative building up the dirt road that has AC and Internet access. I'm going to try to get some writing done tomorrow while the kids are out working on merit badges. I hear they have a coffee pot too. If you are interested, scroll down to the bottom of this post for a little video log from our days adventures.

Enjoy this week's installment if Interesting Post...

Your Product Is Done http://bit.ly/dmn9aT

Silly Saturdays: Mac vs. PC http://bit.ly/cGd2ve

The Reality of UI Test Automation http://bit.ly/9Oi0sS

Projects that are NOT Agile Software Projects http://bit.ly/akTOJa

Fear of shipping http://bit.ly/9xjhna

Agile Isn't Latin http://bit.ly/9WFS22

The new CST application process http://bit.ly/ccsNrW

Status Reporting Intervals http://bit.ly/d5VSTs

Are you being creative? http://bit.ly/dwR69w

PMBOK is NOT a Method - Part Deux http://bit.ly/cka0ND

Kanban and When Will This Be Done? http://bit.ly/cohJ0n

Big Binders And Checklists http://bit.ly/ci0Sk3

The 19 Keys to Successful Agile Projects http://bit.ly/aEBXnJ

Scrum Gets Going In Bangalore http://bit.ly/aHrrQZ

PMBOK is NOT a Methodology http://bit.ly/cUyJVm

Artificial Critical Paths http://bit.ly/cypzpC

Base lining Story Points http://bit.ly/ajF9ix

Why Is There Still Talk About Agile v. PMBOK? http://bit.ly/9ojMy9

What DONE Looks Like? http://bit.ly/9gFksS

Schizophrenic Use Of Methods http://bit.ly/aQ7xy7

Agile is in the PMBOK so it must be true http://bit.ly/c4pw7L

Hyperproductivity in Scrum

2010-06-13T20:59:00.004-04:00

Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.

According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:

"We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience."

Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:

"The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of points completed is the baseline velocity."

When I first read that, I was like "what am I missing here". Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn't strike me as a very fair metric, you'd think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.

But here is their key assertion that supports the measurement:

"At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative"

I don't know about you guys, but I'm kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I'm not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren't. It might also be interesting to see the team stabilize first, and then see how much better they'd get by systematically removing impediments.

These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?

BTW - I loved the image here... seemed pretty much with the Shock Therapy theme. Check out the artists website at http://llynhunter.blogspot.com/2008/05/electricity-if.html

Is Kanban just Waterfall with Small Batches?

2010-06-12T10:34:00.006-04:00

Often when I introduce Kanban to teams that are just getting familiar with Scrum, one of the first comments I'll get is... it looks a lot like waterfall. So, here is the question, is Kanban just waterfall with small batches? Let's say you kept all your functional silos in place, and simply started running smaller projects... small to the point of being a feature or an MMF... would you get better business outcomes?

I haven't been in a situation where I could actually try this approach at any kind of scale, but my gut tells me that you would get better performance. You'd increase the rate at which the organization created value, you'd decrease the amount time spent doing up front planning, and you'd decrease the number of in-flight dependencies you're managing at any one time. Decreasing the batch size would make it easier to change direction when business conditions changed.

My guess is that's why some folks are so excited about Kanban... you get better overall performance, without having to change anything about how the organization is currently structured. You get incremental improvement without the transformation and change issues that come along with a Scrum adoption. In addition, you'd now have a way to explicitly visualize the work, manage the flow of value, and drive conversation that incrementally improves how the overall system behaves.

So... what do you think? Is this the preferred way of working? Do we abandon teams and transformation? Is adopting Kanban as simple as working on smaller batches, value stream mapping, and setting work in process limits to create flow? If we took this approach, what would be our tradeoffs? Would we be leaving anything out by not transforming?

BTW - It is worth marking the occasion... this is my 300th post on Leading Agile. That's kind of a cool milestone.

Motivation, Insight, and Introspection

2010-06-11T20:57:00.003-04:00

I've had the idea for this post noodling around in my head for the past few months. To be quite candid, there was a part of me that wasn't quite sure how much of this I wanted to share. Even though I don't know all 2400 of you personally, I've always had this desire to be transparent. My hope is that that my experiences, agile or not, could somehow help you guys get better doing what ever it is that you do.

It's not been any secret, at least I don't think it has been a secret, that these last few months after leaving VersionOne have been really challenging for me. Working for VersionOne was a great gig. Someone else sold my engagements, and I just showed up where I was supposed to show up, when I was supposed to be there. When I wasn't on client sites, I did papers and blogs and attended conferences. It was a pretty fun way to make a living.

When I joined Pillar, all that changed. Now I was working constantly to build a business here in Atlanta. My life became all about generating sales. Rather than trying to solve the big problems in the agile community, I was trying to solve the big problem of managing a sales funnel and running a small consulting business. Much of what I'd been doing was brand new to me. I was like the guy that loved to make bread that opened a bakery. Now, rather than making bread, he was running a bakery. Not quite the same thing.

The time between the Scrum Gathering in Orlando and the LeanSSC conference in Atlanta was pretty tough psychologically. I spent a lot of my time stressed out, and sick to my stomach. There was so little correlation between the effort I was putting in, and the outcomes we were seeing, the stress was really getting to me. I wasn't writing, I wasn't connecting, and I wasn't enjoying life. To some degree I felt like I had lost my way... I had somehow lost sight of the big picture and what was really important. I needed to refocus.

Four books that helped me refocus

One night at the LeanSSC conference, I was sitting in the lounge having a drink with Jean Tabaka and Dennis Stevens. Jean was telling me about some of the books the folks at Rally were reading, and about how several of them were having a profound impact within their company. Jean turned me onto the first two I want to talk about today: Seth Godin's Linchpin and Daniel Pink's Drive. I like Jean, and I think she's smart, so I took her advice and started reading them.

Come to find out, some of the guys at Pillar were reading Drive too, and turned me onto a third book, by Chris Anderson, called Free. I think the Pillar guys are smart as well, so I picked up Free and starting reading it also. The fourth book was Gary Vaynerchuk's Crush It. I'm not sure where that one came from, but I'm really glad it showed up in my life. For me, these four books were the right four books, at just the right time. Together, they really helped me see, and articulate the core problem that I was struggling with.

I want to first highlight a few simplified takeaways from each book, and then tell you guys why there were meaningful to me.

Drive by Daniel Pink - The main point of this book is that creative people are intrinsically motivated. That means that they create for the joy of creating. They love being in a state of flow. They love being challenged. They love helping people. The idea behind this book is that people need to have their basic needs covered, but once that happens, extrinsic rewards don't increase performance. More often than not, they decrease performance. I have found that while I want to earn a boatload of money, it's not really about that. It's all about the intrinsic motivators. The money is a distraction.

Linchpin by Seth Godin - This was a big book with lots of big ideas, but I think what really resonated with me was Godin's take on how society is changing. The social contracts that told us to go to school, get an education, get a job, and conform... and in return society will give you lifelong employment... are broken. To be a linchpin, we need to think outside the lines. We need to be creative. We need to bring our passion. We need to give. We need to make ourselves invaluable by bringing our whole person to our jobs. This book helped me rediscover the path I had been on and why. Excellent book, my favorite of the four.

Free by Chris Anderson - I'm still reading this one, but the general idea here is that, as it gets cheaper and cheaper to distribute information, the cost of that information goes down exponentially... to the point where it is so close to free that it is less expensive to round down than to sell. In an economy of open source software and free services, how does someone run a profitable business. You give away one thing in the hopes of selling something else. Free helps me stay connected to people, to build relationships, until the right opportunity presents itself... and if it never does, that is okay too.

Crush It by Gary Vaynerchuk - Gary V. is a guy that turned a moderately successful local liquor store into a 20 million dollar business, and ultimately an online wine seller called Wine Library. He did this using social media and the power of the internet. His message is about family, hard work, focus. Great businesses are not build in a month or two months or even a year. You have to do what you love, so you can work your ass off while the thing isn't making any money. If you don't love it, you won't have the energy to sustain it. This book gave me a few more ideas for connecting, and reinforced that patience really is a virtue.

What I Learned About Me

Over the last 8 months, I've been in a situation where I've had incentives to do the things that I used to do for free. I could go to a conference, show up and network, try to be smart and polished, and go home. The VersionOne brand hopefully benefitted, but past that... I didn't have any part of my compensation tied to how much software we sold. Sure, I had a paycheck, but at VersionOne, there wasn't any further incentive to go out and sell business. I trained people for a living... I blogged and networked and attended conferences, just for the love.

When those things became direct marketing activities, things that had an impact on how much money I make... they got uncomfortable. Now it wasn't about helping people, it was about finding leads, and seeing who I could impress. It was about making sure I got a business card so I could reach out to someone later, to maybe move some of our consulting services. It felt inauthentic. I struggled to find a way I could sell, that allowed me to keep my personal integrity. More than once I was called out because something about me was different, I wasn't being myself.

If I was going to do this for a living long term, I had to find a way to decouple psychologically, what I love doing, from how I earn a living doing what I love... at least from a direct financial perspective. What I found is that when these things were directly linked... it had a profound negative impact on my writing, my interactions with people, and how I fundamentally viewed the world around me. All in all, it hasn't been a healthy place for me to be. To be successful going forward, I had to think about things differently so I could continue to bring my whole self to my job. What I was doing, wasn't working.

I am fortunate that I love what I do, and I've found a way to make a living doing something that I deeply care about. It's not just about software development, it's about the quality of our human condition, it's about making work/life balance, it's about working in environments that make sense. It's about meaningful work, and creating real value. It's about putting people into systems where they can be successful. The methodology that surrounds that is just a means to an end... not a goal unto itself... no matter how interesting the technical details happen to be.

What I learned through some of these books, is that the stuff that really drives my passion, the stuff I love, is the stuff that I need to give away for free. It can't be tied to a sale. To maintain passion and enthusiasm for my craft, I have to contribute, I have to feel like I am making a difference, and I can't feel like every interaction is something to be monetized. I want to connect with people, in meaningful ways, that aren't always about selling someone something. I feel like the pending sale diminishes the quality of the relationship.

It makes me feel a little queasy and it's not who I want to be as a person.

Rethinking the Sale

I'm getting better at distilling what I like about this field and what has me excited to wake up in the morning. It's not the sale... it's not the chase... it's the connection. It's about helping people connect with each other. It's about helping people connect the dots in their organizations. It hit me a few months ago when I was doing this public class in Atlanta. We had 22 folks representing 12 companies. By the middle of the second day, they were talking to each other and exploring ideas and possibilities. I switched from teacher to facilitator and let the discussion play out. It was awesome.

I've decided that I don't want to sell. I want to help people be successful. I want to help people grow. I want to connect them to each other and to the community. I'm going to bring my whole self every day... try not to worry about quotas and revenue. I have to trust that if I do all the right things, and work really hard, the rest will follow. Integrity is about being internally congruent. What I'm really doing is, I'm learning how to sell with integrity, in a way where I can live with myself.... and do what I love as a result.

I don't know that I have the details worked out yet.. but this feels like the right way to think about things. I feel like I've gotten myself finally on the right path.

It's About Context, People!

2010-06-11T11:07:00.003-04:00

In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.

We used a big-up-front-design, traditional estimating, and Gantt charts... even on the agile side. We did 'black box' the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.

We didn't do a death march, there were no 11th hour surprises, the deployment went exactly as expected.

Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It's a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known... it's possible Scrum is not the best choice, even on a software project.

I think part of our problem right now is that we've somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That's not a knock on Scrum... it's just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.

The Gist of My Agile Dev Practices Talk

2010-06-10T23:40:00.003-04:00

I know this is really high level... but I want to see what kinds of questions this level of description generates. Does it make sense? I'm really trying to figure out how to explain some of these ideas with fewer words.

Talking Points

1. Scrum works under certain conditions, if it works... use it.

2. Scaling scrum works under certain condition, if it scales... do it.

3. Scrum requires significant transformation for most organizations.

4. People underestimate what it really means to transform.

5. Transformation is too disruptive for many companies, these people will fail.

6. We need a credible transition strategy for everyone else.

If you are an 'everyone else', go read my last post... I'll wait.

7. Define a static organization model.

8. Find the constrained capability, create an agile team there.

9. Do agile for a while with that team, do it again with a few others.

10. Define your first agile multi-team project. Use expand and collapse Kanban, across teams, to limit WIP.

11. Define your next few multi-team agile projects, now you have a portfolio. Use expand and collapse Kanban, to limit projects in progress (PIP?), and manage WIP across teams.

12. Define capabilities outside of IT... extend agile to them.

13. Wash, rinse, and repeat

Key Concepts:

1. Scrum will break in complex product organizations.

2. Use a Static Organizational Models as the basis for agile pilots.

3. Use Lean and Kanban to intentionally limit WIP at the project level and the team level.

In general the talk was well received. A handful of people walked out... maybe this wasn't what they expected, maybe they just needed to use the restroom ;-) A few folks challenged the ideas I presented... Bob Galen and I had a follow-up conversation. More than a handful stayed after, talked to me in the hallway, and took business cards.

This is not everyone's problem... but if it's your problem, you need to go into your agile transformation with your eyes wide open... and some credible strategies for incrementally adopting agile.

You Need a Static Organizational Model

2010-06-10T20:17:00.003-04:00

Okay... I want to make an assertion here. In order for agile to work, you've got to understand the static organizational model for your company. Why? If you are organizing around things that are transient, like projects, you are doomed to fail. Agile requires teams that stay together, period.

Most organizations are organized around one static model, the resource team. This is our much beloved organizational pattern where we pull all the BA's into one group and all the developers into another group. People are assigned to project teams, but the resource organization is the strong side of the matrix, the project organization is the weak side. Resource teams don't deliver value by themselves.

Agile asks us to organize around the parts of the business that deliver value, and in common practice, that is usually the product. It makes sense, we make products, let's organize around the stuff we make. This is where we get the whole, give the team what they need to deliver, and they'll give you working software at the end of every sprint routine. Single PO + Single Team = Delivered Business Value.

That works awesome in small product driven organizations. In the complex organizations we've been talking about here, this approach is problematic. Why? Investment is not always level across products. Sometimes I need a full staff and sometimes I don't. Sometimes I want to improve one set of product capabilities and just keep the other capabilities in more of a steady state.

Uneven investment in products over time is what drives our obsession with project work. We know that we don't need the same people doing the same thing all the time, so let's deploy 'teams' to go build some value for us. When they're done, we can break them up and have them go do something else. From an agile perspective, the problem is that this approach doesn't keep teams together over time, and that makes it really hard to really do agile.

I'll admit, you could create multi-disciplinary teams and run your project work through these static teams. This is on the right track, but still breaks down when the skills required project to project ebb and flow. I'm all for building teams around specializing generalists and bringing work to teams, but in complex organizations it is a stretch that every team is going to have every skill they need to do every project.

So... back to our static organizational model. If we are going to keep teams together, we need to organize the teams in our complex product organization around the things that aren't likely to change over time. We need a static model for the organization that is resilient. One that reflects the core delivery capabilities of the enterprise, capabilities that can be staffed and deployed to solve specific business problems

In our complex product example, the delivery capabilities might be the various products delivered by the organization. The services they provide to external customers, or to other internal products, become the capability the organizations is expecting them to deliver. A capability could also be something like marketing, or sales, or support, or even some external service provider that you depend on for a fully functional product.

Before you begin your agile transformation, you need to think about your organizational structure. Ask yourself if you are building teams around stuff that will predestine them to be broken apart when the work is done. Are you piloting something that has no chance of long term successes when it get's out into the wild? It is important to understand what the non-transient, static model for your enterprise looks like, first.

Then, and only then, should you decide where to pilot your first agile team.

Scaling Agile Past the Team - Agile Dev Practices Edition

2010-06-09T17:43:00.002-04:00

If you guys have been following my updates here and on Twitter, you know that I'm out at Agile Development Practices in Vegas this week. I'm speaking in about an hour... and just putting the final touches on my presentation. The content is not fundamentally new, I think though I'm learning how to talk about this stuff better. So... here is the slide deck I plan to go live with. Have fun, and let me know if you have a group that would be interested in this topic. Depending on your schedule and mine, I might be able to come out and do the talk for you live and in person!

Scaling Agile Past the Team - SQE Agile Dev Practices West

View more presentations from Mike Cottmeyer.

Interesting Post... 6/1/2010 through 6/6/2010

2010-06-06T21:40:00.005-04:00

Twitter search won't seem to give me any of my tweets from before 6/1 today, so this installment of Interesting Post... is going to a be a little short this week. Hope you enjoy...

Interesting Posts from 6/1/2010 through 6/6/2010

Why Is There Still Talk About Agile v. PMBOK? http://bit.ly/9ojMy9

What DONE Looks Like? http://bit.ly/9gFksS

Schizophrenic Use Of Methods http://bit.ly/aQ7xy7

Agile is in the PMBOK so it must be true http://bit.ly/c4pw7L

Real Men of Agile Genius Sweepstakes http://bit.ly/9AnaMY

Agile Scrum, Or Not-So-Agile Scrum? http://bit.ly/aPpbam

Is this noise inside my head bothering you? http://bit.ly/bjVgt8

Kanban and Conversations http://bit.ly/ahdSUd

Big Pie in the Sky... And Other Stuff!

2010-06-05T22:44:00.004-04:00

Time has been absolutely flying by the past few weeks. Lot's going on here in Atlanta, some of which I want to share with you guys this evening. First of all... I've got to tell you about the place we went to dinner tonight.

Big Pie in the Sky

We are big Man v. Food fans in our house. Somehow, me and my boys get a kick out of watching Adam Richman travel the globe looking for the biggest, greasiest meals... and then watching him eat the entire whatever in under an hour. A while back, Adam hit three places in Atlanta, one of which was a place called Big Pie in the Sky. That's where we ate tonight.

The challenge was for two people to eat a 30 inch, 11 pound all-meat pizza in under an hour. Needless to say... that was out of our league. We did order the 30 inch, 11 pound all-meat pizza, but it took seven of us to put a dent in it. We still came home with leftovers. The kids got a kick out of driving across town to eat at a place we saw on TV. It was really fun... and definitely out of the ordinary.

ATdL100

I got a great invitation to attend an executive networking meeting last week called Atlanta TechDev Leaders (ATdL100). Van Williams, my former SVP at CheckFree/Fiserv was the host, and put together an excellent panel to talk about Innovation. It was really cool hearing these senior leaders talk about what factors contribute to innovation in their companies. More often than not I heard colocation, collaboration, and iteration. If I didn't know better I would have thought I was at an agile meet-up.

Dan Pink - Drive, The Surprising Truth About What Motivates Us

I've been doing quite a bit of reading the past few weeks. This one I actually downloaded from Audible.com and listened to on my iPhone. This is a game changing book, and a must read for anyone that needs to get the best out of their team. The main takeaway from the book is that knowledge workers tend to be intrinsically motivated, the are more inclined to perform for the sheer joy of the work. Offering extrinsic rewards often results in lower performance and gets us exactly the behavior we don't want. Again... a must read

Seth Godin - Linchpin, Are You Indispensable?

I don't even know where to start with this one. First, excellent book. Next, go read it. Godin starts off talking about how our schools and our society are setup to get people to conform. He explains how the old social contracts, the ones that rewarded conformity with lifelong employment, are no longer in place. Workers are doing their part, but the security that we used to have in return is no longer there. Godin makes a strong case that successful people are those that make themselves indispensable. Success comes from giving, being part of communities, and shipping.

Chris Anderson - Free, Future of a Radical Price

This is the one I am reading right now. The book explores the economics of the Free economy... from open source software to illegal song downloads. It's another one that challenges conventional wisdom and shows you how to make money by giving stuff away. The general premise... remember I'm only just starting... is that as the cost of delivery goes down, it is almost impossible to make money from the distribution of information. Give the ideas away for free and make money off of something else. Again, a very powerful and very radical idea. Somewhat counter-intuitive.

Pillar Southeast

We've spent a bunch of time and energy investing in relationships with a few dozen companies here in the Atlanta area. That investment is starting to pay off, and we are beginning to sell some business here in the region. I love this new gig, but the sales cycle for some of these deals has taken much longer that I ever thought. It is really nice to start seeing the other side... the light at the end of the tunnel you might say. I love getting out and helping people, and I'm excited to be on the ground working with clients on a more regular basis.

Kanban Training

Dennis Stevens and I just wrapped up the first ever Kanban course in Atlanta. We had an excellent group of people... almost 20... attend the class. The class went very well and everyone learned a lot. I think some of us get desensitized to how fast new ideas are emerging from our community. Many people are still just hearing about Kanban... if they've heard anything about it at all. It is cool to introduce people to such new and powerful ideas for the first time. It is very rewarding to see that light go on as people discover that there ARE solutions to some of these problems they have been wrestling with for so long.

COHAA Conference

A week or so ago, I was up in Columbus, Ohio... reprising my Agile PMP talk for 350 (or so) agile practitioners. The Central Ohio Agile Association did a great job organizing the conference and I really, really enjoyed hearing Ken Schwaber, Michael Mah, Patrick Wilson-Welsh, and Isreal Gat speak. It was one of the first conferences in while that I actually went to attend sessions and learn. It was interesting hearing Ken Schwaber's take in the new Scrum.org group. Ken had quite a few great lines... but one of the things I really respected was when he said 'whatever we do will be wrong... but we have to do something'. I can live with that.

Agile Development Practices West

I'm heading to Vegas next week to do my talk on Scaling Agile past the team. This talk is really about applying Scrum (and Lean and Kanban) to manage agile delivery in complex product organizations. My thinking on this has gotten clearer over the past few months, so I am putting some effort this weekend into refactoring my slide deck. I speak on Wednesday and am tied up Monday and Tuesday... so I better get busy. If push comes to shove, I can always fall back to the original presentation.

Agile 2010

Lowell Lindstrom asked me to produce the Enterprise Agility stage... this was first for me and quite a good experience. I also had my talk on scaling the product owner role on large complex products selected, so I'm happy I'll get to speak too. It's funny, I think the material in my scaling agile talk, and my talk on product ownership in the large, are starting to converge. There are a couple of core themes that keep coming out. I think they are really important and stuff that our community needs to understand... so I'm geeked. That said, I'm bummed we had to move from Nashville, but Orlando is always an excellent place to have a conference... and of course it will be fun to see old friends!

Agile Development Practices East

Lee Copeland was gracious enough to allow me to do my Scaling Agile talk in Orlando too. Again, I think this is a strong message that people need to hear. I am happy to have a forum to spread the word.

Raising Boys

As my kids get older, I am constantly amazed watching them grow. My oldest turned 14 this year. He is a great kid, plays percussion in the marching band, and is a straight A student. That said, he is pushing his boundaries and trying figure out his limits with his Mom and me. A few weeks ago, he got busted making out with his girlfriend in the dugout at the high-school. It was totally awesome watching the consequences come down from the school system, and seeing him learn a lesson that I didn't have to impose. I love watching these guys grow up... totally awesome!

Stephen King - Wizard and Glass

If you follow me on Twitter, you may have caught that I am slowly working my way through Stephen King's Gunslinger series. I just finished the 4th in the series called Wizard and Glass. I wasn't sure what I thought of it as I was working my way through, but now that it is done, I think it was probably my favorite of the four so far. I've decided to take a few weeks off before I start reading book 5.

Scout camp coming up

Last but not least...after Agile Dev West, I'll be up in Gainesville, GA at Scoutland chaperoning 10 teenage boys at Summer Camp for the week. Once we are done, Zach should be a Life Scout and Daniel should be a Star Scout. I am personally looking forward to a relatively relaxing week. I plan to take that time to get going on our book again. I am anxious to get back into the habit of writing daily, I really miss it. It has been tough being creative when there is literally no space in my life.

All good stuff... just freakin' busy! If you made it this far, thanks for coming along for the ride!

Trustworthiness... Then Trust

2010-05-21T09:21:00.005-04:00

Trust is an import part of what makes agile really work. It is so important, we are intentional about creating the opportunity for that trust to emerge within the team. We are intentional about creating a planning, delivery, and feedback cadence that helps trust form between the team and the business. Trust is a fundamental precondition to how we write requirements, how we estimate, and how we assess progress. Without trust, agile isn't really very agile.

But what do you do if you are in an organization where trust is really low? What if you are working in an organization with a long history of distrust between the development team and the business... an organization where the business has unrealistic expectations and a perception that development never gets anything done. You might decide to adopt agile, but that history isn't going to go away overnight. In this case, is it fair to ask the business to trust the team?

One of the biggest complaints I hear from new agile teams, is that the business does not trust them to deliver. They are convinced that all their problems would go away if the business would just trust them to do their jobs. These teams want the business to trust them first. The problem is that the business has no history of getting what they want. They have no history of software being delivered on time. They have no history of getting the quality they need to be successful with their customers.

If you were the business, would you trust you to deliver?

What teams don't realize is that they aren't safe to be trusted. The business is on the hook for delivering value to their customers. They are on the hook for revenue and market share. With no foundation of trust to build on, asking them to trust is like asking them to take their hands off the wheel of the car. They are responsible for getting from point A to point B and want some degree of assurance that they are going to get there. Trusting the team feels like an irresponsible loss of control.

If you are a team that wants to be trusted, I would suggest that you stop asking the business to trust you. When you frame the problem this way, it makes you powerless to do anything about it. Either the business changes or you can't be successful... the problem is beyond your ability to influence. What you need to do is become trustworthy. Becoming trustworthy is something that you have power to do something about. If you are trustworthy long enough, you will earn the trust of the business and won't have to ask for it.

Subordinating the Scrum Team

2010-05-16T21:01:00.004-04:00

Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.

Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.

Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.

Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.

We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.

Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.

I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.

When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.

While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.

It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.

COHAA: The Path to Agility

2010-05-16T14:33:00.007-04:00

If you happen to be in the Columbus, OH area on May 27th... you should really come see me speak at the COHAA Path to Agility conference. I'm doing a variant of my Agile PMP talk... exploring a little bit around the intersection of traditional and agile project management.

This is one of those great one day events that are low cost, full of great speakers, and give you a great opportunity to network with some really smart people in your community. Every time I do one of these one day events, the value delivered is always so much greater than the cost!

Ken Schwaber is doing the keynote... that should be enough right there, but it doesn't stop. We've got Patrick Wilson-Welsh, Steve Harmon, Tim Wingfield, Michael Mah, Daryl Kulak, and one of my all time favorites... Isreal Gat. And that is probably only half the speakers that will be there to educate and entertain.

So... do yourself a favor, head over to the conference website, and figure out a way to be there. See you on the 27th!

Interesting Post... 5/10/2010 through 5/16/2010

2010-05-16T08:39:00.003-04:00

It's been a little while since my last Sunday morning installment of 'Interesting Post...' I don't usually like to fill my blog up with summary articles like this... so when I'm not writing real content, I don't tend to want to do these.

Also, I've gotten to where I don't really trust TwitterFeed a whole heck of a lot. TwitterFeed is what monitors my Google Share feed and turns them into tweets. It just doesn't seem to be as reliable as it once was. Some day when I have some time, I'll either figure out what I've done wrong, or I'll find another service.

As for now... enjoy this round of tweets from the week.

Arrogant http://bit.ly/dvceBv

APLN Board Update http://bit.ly/c9L3Ey

Agile and regulatory compliance http://bit.ly/cXRaFD

You heard me but are you listening [video] http://bit.ly/bIx9je

All you need to know... http://bit.ly/cbChgL

Toward An Event Driven Scrum Process http://bit.ly/caztRX

Agile and Lean Product Development – Yesteryear, Today and into the Future http://bit.ly/cEB9F0

Academic TDD links http://bit.ly/cxZdYy

3 Legs to Running an Agile Transition http://bit.ly/aWGH63

Personal Brands: The Testicle Defense http://bit.ly/9lWEQz

Agile: Chasing a points total http://bit.ly/bxUYBy

What's so good about scrum? http://bit.ly/9yEZkG

How To Harness Influence http://bit.ly/ajVRh1

Agile: It’s a Healthy Lifestyle Choice http://bit.ly/aSEDY0

Approaches to Organizational Change http://bit.ly/cTZvRy

Ultralight Backpacking and Other Saturday Morning Musings

2010-05-15T09:22:00.006-04:00

I've been a pretty big fan of Seth Godin for the past few years. I don't love everything he does, but his latest book Linchpin is excellent, and he's been on a roll the past few weeks putting some great stuff up on his blog.

Last week Seth relayed a story about an ultralight backpacker that was able to get his pack down to 14 pounds... including food. I like to fancy myself a bit of backpacker, and I can tell you... getting a pack down to 14 pounds, including food, is really hard.

When people asked this guy how he was able to pack so light, he would tell them "all you need to know is that it's possible". The point being, that when you stop saying that things can't be done, you figure out how to make them work.

That comment has been haunting me for the past few days.

Think about it... we can't do agile here? All you need to know is that it's possible. Can't get stories small enough to fit into a sprint? All you need to know is that it's possible. Can't get developers and QA to work together? All you need to know is that it's possible.

What else is possible if we stop saying that stuff can't be done?

There Are No Spherical Chickens!

2010-05-12T07:40:00.003-04:00

Just in case you are wondering... I'm not suggesting that our Credit Card Processing team shouldn't do Scrum. I'm not suggesting that they shouldn't improve. What I am suggesting, is that if the organization stops with this one team, they won't get the business benefit from Scrum that they expect. All the value created by the Credit Card Processing team will be obscured by the underperformance of everyone else. Furthermore... you shouldn't be surprised when your Scrum team gets downsized, outsourced, or reorganized... just like everyone else who didn't deliver.

If you don't have the ability to influence the rest of the development organization, it probably won't make any difference if the Credit Card Processing team adopts Scrum. Sure, the team will probably enjoy their work more. Maybe if they get really good at delivery, they can jump in and help out some of the other teams. If the culture is open enough, maybe everyone else sees the benefit of Scrum, and they become the catalyst for more widespread adoption. That just hasn't been my experience with this kind of grass roots hopefulness.

Most large companies I have worked with are full of silos, full of politics, and full of protectionism and fear. Accountability structures don't necessarily reward working well across teams. Incentives are geared toward individual performance first, and team performance second... if at all. Organizational or divisional objectives are so far off people can't directly influence them. We are allowed to build empires that only serve to grow the headcount in our particular group, often at the expense of our ability to work well with those around us.

The thing we most often forget when adopting agile, is the impact that agile needs to have on the culture of our organization... and the impact it needs to have on the fundamental structures that reinforce that culture. So... I have to tell you I am a bit cynical about the whole... give agile a try and everyone will be enamored with it's goodness routine. Most people would rather try to be individually successful in the system they know, than risk being unsuccessful trying something risky and new.

In a complex product, all the pieces and parts have to work together to deliver end business value. If you agree with that fundamental premise... and you are willing to agree that team level adoption does not typically spread (unintentionally) out to the rest of the organization... you are left with two options. You can 1) subordinate your Scrum team to the delivery cadence of the rest of the enterprise... or 2) plan to systematically introduce Scrum everywhere else, and learn how to manage the flow of value across the various Scrum delivery teams.

I am clearly in the camp of option 2.

Before we wrap for the day... I want to go back to why I think this topic is so important. A year or so ago, Ken Schwaber famously said, and I paraphrase: '75% of the organizations using Scrum won't get the benefit that they hope from it". If you care about agile, and you believe in the value that it brings to people and teams, and you have seen it work, that is a really depressing statistic. Our community's response seems to be... get more dogmatic about Scrum. If you aren't doing Scrum by-the-book, that is why you are failing.

I'm sure there is some of that going on, I am sure that there are some people bending Scrum to hide their dysfunction. My take is that this complex product idea strikes more the heart of why the underlying dysfunction exists. Vanilla Scrum does not work for these organizations because the value stream is bigger than a single team. Rather than assume that we live in a world of spherical chickens, I'd like us to explore how agile works, why it fails, and most importantly... what are our options for making things better when we can't wave a magic wand and change our cultures and structures overnight.

So... in the context of our financial services organization, and our Credit Card Processing team in particular... I want to explore a bit more why, in the absence of a broader change initiative, you have to subordinate their performance to the cadence of the rest of the enterprise. After that we'll get into how to scale Scrum from the single team, to multiple teams, to projects and portfolios, and then the enterprise. We'll explore blending approaches, how to leverage Lean and Kanban, and how to deal with multi-tiered values streams. We'll talk about how to break down requirements, deal with architectural challenges, how to do planning and context setting, etc.

I might take me a while... be patient.