LeadingAgile has moved...

Just a heads up...

I moved LeadingAgile over to a WordPress site a few weeks back and my subscriber count dropped by about 750 or so. I was wondering how this could have happened because the FeedBurner URL didn't change. It dawned on me the other day, that in the yearly years of LeadingAgile, I didn't use Feedburner... I used the default Google feed.

It makes me wonder if I have accidentally abandoned some of of my longest time subscribers.

If this has happened to you.... meaning that you get this post in your RSS reader... please re-subscribe using the Feedburner link. Here it is in case you have any problems:

http://feeds.feedburner.com/LeadingAgile

And by the way... there is new content that you might find interesting as well:

http://www.leadingagile.com/2010/11/the-role-of-high-level-estimates/

Subscribe to Leading Agile

Saturday Morning Ramblings... Bloody Stoopid Mary

Good morning everyone... I'm on a plane up to Philly to do a little work with the PMI Agile CoP. Delta bumped me to first class and I'm halfway through my second Bloody Mary. I'm asking that you be patient with me while I ramble on here a bit. I've got a nagging issue on my mind that I want to explore with you guys while I'm in transit this morning.

I was on my way home last night, on my way to the Buford High School homecoming football game, when my good buddy Dennis Stevens called and asked if I wanted to get together for a little while. I had a few hours until I needed to be anywhere, so I was like sure. You'd think that after a few years of knowing each other, we could find something else to talk about, but the conversation quickly turned to Scrum and Kanban.

You guys know that I am pretty pragmatic when it comes to selecting methodology... I genuinely feel that in the right set of circumstances, most methodologies... even Waterfall... have their place. What tends to set me off... and almost always forces me into some sort of a 'devils advocate' position, is when we start talking about these things as if they are absolutes.

Without going too far off in the weeds, we got to talking about Kanban's strengths when it comes to helping teams that have to blend operational or support work with other project work that has deadlines. Dennis was passionately making the case the Kanban is superior because it has classes of service, work in process limits, and explicit policies.

Of course this is all true... but what inherently makes it better? NOTE: getting ready to play 'devils's advocate for a minute. With every Scrum team I've spun up, we've had a conversation about how much time should be allocated to support. We just know that whatever is allocated to support, that allocation is going to lower our velocity.

We've implicitly define a class of service and we set an implicit policy around the work. What's the big deal? Sure... if I was a Scrum team that wasn't taking support activities into consideration, or doing something stupid like aborting the sprint every time a new support issue came in, Kanban might help. But I'm not talking about strawman Scrum here. I'm talking about well coached Scrum.

I suggested to Dennis that the premise of the discussion was fundamentally flawed. The real problem isn't which approach should I use to manage this variation... it's that this variation fundamentally exists in the first place. You see... I can manage variability using either approach... the problem is that we have work that inherently needs stability (new product features) being done by the same team that is doing work that is inherently unstable (bug fixing and support).

We can use either approach to constrain the amount of time allocated to the variable work, but what happens if all hell breaks loose and that policy has to be broken? Sure, we need to have a conversation about that... but I'm not convinced that Scrum or Kanban does a better job a prompting that conversation. Again... the core challenge is that these two concerns are competing for the attention of the team.

Someone goes away unhappy... either the customer waiting for a fix because the policy was enforced, or the product owner waiting for a feature because the policy was broken. So you see... this isn't a methodology problem... is a communication problem. It's an expectation problem. More than likely its a technical debt problem. And it's also likely that we haven't invested enough in the product to get done everything that needs to get done.

So... as long as we are talking to each other, and making good tradeoffs, and managing our efforts to deliver the best possible business outcomes... who cares what approach we take?

I would like less discussion about which approach is better... more about the core problems we are trying to solve... and more about how our various approaches help fix the core issues we are dealing with. Context is key... any statement of superiority in the absence of a specific context is a non-starter in my book.

Time to get back to my Bloody Mary... my ice is melting ;-)

Subscribe to Leading Agile

The Planning Fallacy

You know... sometimes I can't help but think that us agilists create unnecessary grief for ourselves when we talk about agile to our more traditional counterparts.

My friend Angeline Tan (@agilemeister) launched a Twitter campaign this week to get the Agile Alliance to show some West Coast love and move the 2013 conference to San Francisco. There was quite a bit of interesting discussion, but in the end Diana Larsen (@dianaofportland) closed the debate... Agile 2013 will be in Nashville, the contracts are signed.

I thought that was kind of funny. A bunch of agilists planning far enough in advance to have contracts signed, what... two years in advance? I thought we were all about emergent outcomes? What happened to just in time planning? I thought we were all supposed to just show up in Nashville and self-organize a conference right there on the fly?

Wouldn't that be fun, just show up in 2013 start conferencing! (actually, that might be fun)

There is always some level of up-front planning necessary to pull off a big event. Likewise, there is always some level of up-front planning necessary to coordinate the efforts of dozens of developers trying to pull together a large enterprise class software system. Software at this level doesn't emerge. There is a ton of room to plan and design as we go, but the core structures and patterns have to be in place early.

I think we'd do ourselves well... as a community... to popularize some language about how we deal with this kind of planning. It seems that somehow... in our day to day discussions about agile... we've given the mainstream project management and development community the wrong impression about us. We value "responding to change OVER following a plan"... that doesn't mean we don't plan.

I bet the first contract in Nashville was signed two years in advance also. None of us showed up in Nashville to a flooded hotel, did we?

Subscribe to Leading Agile

InfoQ Sessions from LeanSSC 2010

Early this year, I was fortunate to get involved with the planning and execution of the LeanSSC conference here in Atlanta. I didn't do much heavy lifting at all, but was able help coordinate with InfoQ so we could get some of the sessions recorded and out on the net. Here is a listing to all the talks that were recorded and links to the InfoQ site so you can check them out:

The Easy Road to FLOW Goes through a Town named LEAN by Don Reinertsen

Single Piece Flow in Kanban, a How-To by James Shore and Arlo Belshee

The Limited Red Society by Joshua Kerievsky

The Need For Enterprise Agility – Vision and Case Study by Alan Shalloway

Standard Work and The Lean Enterprise by Alan Chedalawada

Risk, Lean Development & Profit: Getting Back to Basics by Bob Charette

Kanban for Video Game Production by Clinton Keith

Sibling Rivalry: Can lean approaches help integrate systems and software engineering? by Rich Turner

Teaching Lean and Kanban by Russell Healy

Making the Work Visible by Alisson Vale

Kanban and Accelerated Emergence of High Maturity by David Anderson

Through the Lean Looking Glass by Christophe Louvion

The Lean Change Agent’s Mantra by Siraj Sirajuddin

Feature Bits: Enabling Flow Within and Across Development Teams by Erik Sowa and Rob Loh

Feeding the Agile Beast by Dean Stevens

Lean Lessons Learned by Tim Wingfield

Reformulating the Product Delivery Process by Israel Gat, Eric Huddleston, Stephen Chin

The Power of Visibility: Driving a Lean-Agile transition by Kelley Horton

It's all great content... hope you enjoy!

Subscribe to Leading Agile

Kanban for Agile Teams Whitepaper

This paper has been a long time coming. The first draft of this was written while I was still at VersionOne. I pulled Dennis in to add his expertise and put some final touches on the content. We got the paper delivered, but it stalled on a technical debate over the definition of Lead Time vs. Cycle Time. The issues are finally resolved and the paper is ready for download.

Head over to the VersionOne site, download the paper, and let me know what you think. Here is the abstract:

Kanban has recently become popular with many project teams because of its ease of implementation, use of visual controls, ability to accommodate a wide variety of organizational design patterns, integration of stakeholders and relentless focus on the continuous delivery of value. Many development teams have found success with Kanban when more mainstream agile practices did not yield acceptable outcomes.

Organizations that are interested in adopting or improving agile methods should evaluate the underlying principles behind Kanban and how the principles can work together with more traditional agile methodologies. While there are meaningful differences between agile and Kanban, many teams will find that blending the two approaches can create tremendous value for their organization.

Subscribe to Leading Agile

Heading Back from PMI LIM...

Okay... So I'm totally out of the habit of writing now. It's kinda sad because I've actually had a ton of thoughts lately on various topics. The challenge isn't just finding the time... It's figuring out how to slice things small enough to make a readable post. I've got lots of big ideas floating around in my head... writing about them is a whole other story.

Anyway... I think I'm just going to try to get back in the habit of posting on a regular basis. I'll apologize in advance if my posts totally suck, or are just simply off topic for a while. Be patient while I get back in a groove. I want to start by talking a little about what I've been working on lately.

As you guys know... I headed out on my own a few months back. That was probably the scariest thing I've ever done in my entire life. It's really tough when you are used to having a boss and an employer to make that leap to being totally self-employed. It's easy to have the mindset that a company is going to take care of you. I'm enjoying taking care of myself.

Anyway... while LeadingAgile the blog is floundering, LeadingAgile the business is doing great. I managed to get myself booked full time with several clients here in Atlanta through the end of the year. My business development pipeline is pretty full and I'm expecting to fill up the first quarter of next year over the next few weeks.

It's been a lot of hard work, but I've been really blessed to have the support of my family and a number of great consultants that have given me some excellent advice along the way. Seriously... I think I'm going to have to do an appreciations post sometime in the next few weeks to thank the wonderful cloud of people that have been behind me through this.

The support has been overwhelming.

For someone that works full time in Atlanta, I feel like I've been on the road a ton. I've done a few trips out to San Francisco and one to Toronto... one of my clients has offices in several locations and that's kept me on traveling a bit. I've also done a little bit of conference travel and some community stuff over the past few weeks. It's been a fun ride.

I'm getting ready to amp up my participation in the PMI Agile Community of Practice. My good friend Jesse Fewell is stepping down (but still on the board) and I am assuming the Chief Product Owner role. I'm counting on the support of Dennis Stevens, Brian Bozzuto, and Jesse and I think we are going to be able to make some good stuff happen over the next few months. I'll keep you guys posted on how things go.

Speaking of PMI, I was in DC this week for the Leadership Institute Meetings. I have mixed feelings about PMI events... the are well done, but there is so much content that just doesn't interest me. That said, like most conferences, all the cool stuff happens in the restaurants and pubs... and we had a ton of restaurant and pub time this week. You guys should see the investment PMI is making in Agile... it's coming guys... you better get ready.

I'll share some picks on my Facebook page (www.facebook.com/leadingagile) for you to check out... it's crazy.

On another note... have you guys heard about the ICAgile project yet? I had the opportunity to spend the early part of this week with Alistair and Ahmed Sidky working through the model in pretty fine grained detail. Aside from being honored just to have a seat at the table, I think these guys are developing a really solid model. Again, something exciting going on that I think you should be paying attention to.

If you want more information on ICAgile, check out their website at www.icagile.com. I plan to blog on this a bit, that that is a whole post in an of itself.

Past that...

Dennis and I have made VERY LITTLE progress on the book. I take full responsibility for our lack of progress... last year I decided to turn my life upside down leaving VersionOne and joining Pillar. This year I did it again leaving Pillar and going out on my own. I finally feel like I've arrived where I need to be, and I feel settled. I am looking forward to restarting that project over the next week or two. More to come on that too, I hope.

On a personal note... my oldest son started high school this year. That's been fun. He is in marching band and we are doing all the Friday night football games. I think I have been to more of his games that I ever went to when I was in high school. Very fun. My youngest son is playing right tackle in the 8yo football team. That's a little scary, but he is having fun with it. My middle son likes to sit on the couch and play XBox... so we are trying to figure out what to do about that ;-)

We are planning a trip to New York over Thanksgiving. We have tickets to Wicked and want to see the Macy's Thanksgiving Day Parade. Past that we are open to suggestions. If you have any thoughts on what we should do, I am all ears. Left to our own devices, I'd go do all the typical tourist stuff. So really, looking for some help here. I've also got some time blocked over the Christmas holidays and I am going to try to spend at least half of them sleeping outside in a tent... wish me luck!

Anyway... I'm excited to start writing again. Hopefully I'll be able to create some momentum here and get back in my groove. Catch you guys later.

Subscribe to Leading Agile

Getting Predictable

Over the past few weeks, I've made two assertions about new agile teams. First... teams need to get good at calling their shots. To me, that means that over time, a well-formed, stable team should get good at being able to predict what they will get done over the course of the next iteration. Second... teams need to get good at knowing the size of their bucket. To me, that means that over time, a well-formed, stable team should establish a predictable cadence of delivery... one where their past performance starts to become a predictor of future performance.

These two things are what fundamentally separates an agile project from total chaos. Without the ability to make and meet commitments, without the ability to look ahead and forecast what might be able to get done... we are asking our customers, our businesses, to make an indefinite investment in a project with no general ideal of what they are going to get when time and money runs out. To me... that is total non-starter.

So, granted... there are lots of barriers to a team being able to call their shots and establishing a stable bucket size. First, is that teams have dependencies... things beyond their control, that might prevent them from being able to get stuff done. In addition, many teams are NOT well formed, and DON'T have everything they need to deliver and increment of working software. Some "agile" teams just do the development and pass off their work to a dedicated QA team. All of this is not particularly conducive to establishing any sort of stable delivery patterns.

So... I see these patterns repeated so often, I'm getting to the point where... with every company I work with... we start the conversation with the idea of teams. If you want to do agile, you have to form teams. We can be successful doing something else, Kanban maybe, but the fundamental prerequisite for doing agile, and even having a shot at this level of predictability, is a well formed team that has everything they need to deliver an increment of working software.

That said, I don't think having a well formed team is enough. Even well formed teams are going to hit things they didn't anticipate. Teams are going to learn more about the requirements. They are going to learn more about the technology. They are going to learn more about their customers. When you are constantly dealing with unknowns, it's tough to establish any sort of baseline delivery pattern. The trick is to drive as many of those unknowns into the project as early as possible.

How often are we inclined to get started burning down the backlog by pulling off a few quick wins? Let's get some of the easy stuff out of the way so we can get started writing code really fast. That kind of thinking is what leads to late discovery in the project lifecycle. It causes late thrashing. You risk building software that is going to change once we are forced to tackle the hard stuff. You leave all the uncertainty until then end when you have the least amount of time left to do something differently.

In order to get good at making and meeting commitments, in order to get good at establishing a steady delivery cadence, you've got to deal with your risk and uncertainty... your thrashing... early in the project. That means we are going to build the really high value stuff early so we can get feedback from our customers to make sure we are building the right software. It means that we are going to build the hardest, most technically difficult stuff... the stuff we know the least about... first. That way, if we have to take a different approach, or the project is going to cost more than we thought, we know that as early as possible.

So sure... do I expect a team in this phase of the project lifecycle to be predictable? Of course not. I'm willing to make an investment of several iterations to build some product, reduce key risks, and get the project stable as fast as possible. After I am comfortable that we have sufficiently reduced our risks... I do expect the team to get into a delivery groove as we build out the rest of the product. That means being predictable. Getting the risk out early is an enabler of predictable delivery cadences.

So that's my take... building well formed teams and early and rapid risk reduction are the keys to becoming predictable. What's yours?

Subscribe to Leading Agile

Cool Agile Stuff in Atlanta... In September

Retrospectives Workshop with Esther Derby

Esther Derby is doing a one-day retrospectives workshop here in Atlanta. Esther is awesome and co-wrote the de-facto book on agile retrospectives. If you've spent any time with me, this is one of the books I always mention... and I'm not shy about drawing ideas from Esther's work when I'm in need of something new. The course is on September 21st at the AMA Atlanta Executive Conference Center. The price is $350 for folks attending the Web Industry Conference, $450 standalone. I asked Esther if she would give us a discount code, and she was able to make it happen... the problem is, I don't know how much off the code is! Give it a try WDUSA-DERBY.

Follow this link for more information or to register:
http://usa10.webdirections.org/workshops#agile-retrospectives

Agile Atlanta/Scrum Meetup with Esther Derby

So, as you know... Esther is in town to do here retrospectives workshop. I wonder where you heard that ;-) She is also going to do a talk for the Agile Atlanta group the very next day on September 22nd. Since that was the same day as the Scrum Meetup here in town, we are going to combine both events. The combined meeting will be at the normal Agile Atlanta location at Matrix Resources in the Perimeter Mall areas. Go to http://www.agileatlanta.org/ for the address, time, and directions to Esther's talk. I will be there, so if you are in town, come meet me too ;-)

Certified ScrumMaster Training with Lee Henson

VersionOne is hosting a local Certified ScrumMaster training course. They are doing the course in their Alpharetta offices. Lee Henson will be your CST. I used to work directly with Lee back in the day at VersionOne. He is a great guy and you will have a blast taking his course. Lee was the person that did my CSM training, so I can attest to that first hand. VersionOne is offering early bird rates and a 20% off promotional code. The code is V1Scrum.

Follow this link for more information or to register:
http://www.regonline.com/builder/site/Default.aspx?eventid=869442&mkt_tok=3RkMMJWWfF9wsRoiv6jKZKXonjHpfsXx6%2BsrW6Gg38431UFwdcjKPmjr1YAJScN0dvycMRAVFZl5nRpdCPOcc45P9PA%3D

Innovation Games Workshop with Jason Tanner

Here is another great opportunity in September. Jason Tanner from Enthiosis is doing an Innovation Games Workshop on September 29th and 30th. These are also being held in the VersionOne training facility in Alpharetta, so the location is excellent. I don't know how much you guys know about Luke Hohmann's work on Innovation Games, but they are great facilitation techniques for helping people get really creative in the product development process. I use Luke's games in a variety of settings... from product visioning to retrospectives. It's is excellent material, and you will get a ton out of this course.

Follow this link for more information or to register:
http://innovationgamesatl.eventbrite.com/

I hope you can make one or more of these events. It is great to see world class thought leadership here in town. There is a lot we can learn from these folks!

Note: Each individual in this post asked me personally to promote their offering. I'm happy to do this kind of stuff when I can. If you are in town and have something valuable to offer the agile community, please let me know and I'll do what I can to help you out. I am not affiliated with any of these courses in any way, other than I really, really like the people offering them ;-)

Subscribe to Leading Agile

How Big Is Your Bucket?

A few posts back, I asked if an agile team should be expected to call their shots. In other words, should we expect that over time, an agile team should be able to accurately predict what they'll be able to deliver at the end of the iteration? My assertion was that predictability at the iteration level is the only thing that separates an agile project from total chaos. Without the ability to make small commitments on a regular cadence, we have no ability to forecast what we can get done.

I'm working with one team right now that has gotten really good at calling their shots... but... people keep getting pulled in and out of the team. Having a stable velocity is predicated upon the team working together, staying together, and learning how to estimate and plan together. The constant churn at the team level is making it really tough to establish a consistent velocity iteration over iteration. While the team is great at calling their shots, they are still not able to really say what they can get done... and by when.

I'm a big believer that if we can't get some idea of what we are going to deliver, and when we are going to deliver it... pretty quickly after spinning up a team... agile is almost a non-starter for most companies. Many of the companies I work with are not prepared to make an indefinite investment, with no idea of what they are going to get in return. Sure... agile teams fix time and cost, and vary scope to meet iteration objectives... but we have to have some ability to look ahead and manage the expectations of our customers. We have to have good data to help them make good decisions.

What I am really saying here, is that while calling your shots is essential, calling your shots isn't really enough. You also have to get good at understanding the size of your bucket. What does that mean? It means that iteration over iteration, I need to establish some kind pattern for how much feature functionality I can deliver back to the business. Out of the gate, I don't really care what the team delivers... or even how much they deliver... I want to know their delivery capacity over time. Not a hard fixed number, but a stable trend that I can base product decisions.

Over time, we will remove the teams blockers and help them deliver more effectively, but initially... they need to get good at calling their shots... and establishing the size of their bucket. So please... let me know what you think. Am I expecting too much from our agile teams? Should teams just be able to do what they can with no expectation of committed delivery? Even at the iteration level?

Subscribe to Leading Agile

How to Own a Really Big Complex Product #agile2010

Hey folks... here is the deck I am doing this morning at Agile2010. I am pretty excited to do this talk... I finally feel like I've got the slide sequence and story right. It's amazing what a good night sleep will do for you! My talk is in E-2 on the Ballroom level, hope to see you guys there!

How to own a really big complex product v3

View more presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Interesting Post... 7/31/2010 through 8/7/2010

Okay… we are going to do a Saturday evening edition of Interesting Post… Tomorrow I am going to get up early, do a little hike through the woods, bring home bagels for Kimi and the kids, toss the football with Noah, and then head to the airport for a week in sunny Orlando and the Agile 2010 conference. I'm totally geeked heading to Orlando as an independent agile coach. Did I say I'm geeked ;-)

There are so many people that I want to talk to and so many things I want to do and see while I am in town. I'm am looking forward to having one heck of a week. If you are going to be at the conference… give me a call, shoot me an email, or DM me and let's find a few minutes to get together. I'm doing my talk on How To Own a Really Large Complex Product… so come see me there too!

Travel safe and I'll see you in Orlando.

Interesting Post... Process: friend and foe http://dlvr.it/3WFjb

Interesting Post... Agile Conference - Speakers - Don Reinertsen http://dlvr.it/3VtlW

Interesting Post... What is Test-Driven Development? http://dlvr.it/3TsNz

Interesting Post... Kanban for Service Desks http://dlvr.it/3Tg81

Interesting Post... What's next for the agile community? http://dlvr.it/3TZT9

Interesting Post... 30 Days of Getting Results the Agile Way http://dlvr.it/3S085

Interesting Post... Kanban Experience Complete – Thank You LSSC10 http://dlvr.it/3S084

Interesting Post... PMBOK and detailing leadership http://dlvr.it/3Ryvj

Interesting Post... Agile Rollout Warning Signs http://dlvr.it/3Ryvd

Interesting Post... One Size Does NOT Fit All! http://dlvr.it/3QcGN

Interesting Post... Creating an Agile Environment Fit for a Marketing Team http://dlvr.it/3QbCC

Interesting Post... I won’t be staying late with you http://dlvr.it/3QbCB

Interesting Post... Bob Payne and the Art of Agile Philanthropy http://dlvr.it/3QbC9

Interesting Post... Re-Think Transactions http://dlvr.it/3QbC8

Interesting Post... Yes You Kanban! http://dlvr.it/3QbC7

Interesting Post... What Should Done Mean? http://dlvr.it/3Pqf0

Interesting Post... Scrum Butt and the Nokia test http://dlvr.it/3PpVP

Interesting Post... Can Agile Work If Some Of My Development is Outsourced? http://dlvr.it/3PmsC

Interesting Post... Agile Software Requirements: We Have a Foreword and a Cover – Can a Book be Far Behind? http://dlvr.it/3PlnJ

Interesting Post... The Gordon Pask Award http://dlvr.it/3PlnG

Interesting Post... DZone RefCard Update http://dlvr.it/3PlnC

Interesting Post... The Difference between Lean and Agile http://dlvr.it/3M1XT

Interesting Post... Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared http://dlvr.it/3KWGb

Interesting Post... Minimum Concepts for Earned Value Management http://dlvr.it/3KTlL

From Leading Agile: On Leading Agile... Change... The Only Constant http://dlvr.it/3GLFX

Interesting Post... Top Excuses Why Automatic Builds Suddenly Fail http://dlvr.it/3GCc1

Interesting Post... Agile Communications http://dlvr.it/3FGZZ

Interesting Post... Project Management Definition - Part Three http://dlvr.it/3FCJs

Interesting Post... If your dev team jumped off an agile bridge, should your marketing team jump too? http://dlvr.it/3FCJt

Interesting Post... Keeping in Tune http://dlvr.it/3FCJv

Interesting Post... Good Agile software team looking for an agent to represent us! http://dlvr.it/3F6Zs

Interesting Post... If It's Painful, Do It More Often http://dlvr.it/3F6Zj

Interesting Post... The painful reality of many meetings http://dlvr.it/3Dzpb

Interesting Post... Are We Agile Yet? http://dlvr.it/3DzpS

Interesting Post... Agile Coaches Gathering UK 2010 http://dlvr.it/3DzpR

Interesting Post... Getting unstuck: solving the perfect problem http://dlvr.it/3DzpN

Interesting Post... Ten Principles for Agile Testers http://dlvr.it/3DzpJ

Interesting Post... Design what you know http://dlvr.it/3Dzp9

Interesting Post... Fire everybody! How to start transitioning your marketing team. http://dlvr.it/3Dzp1

Interesting Post... Agile: It’s a Healthy Lifestyle Choice http://dlvr.it/3Dznw

Interesting Post... Every Team Must Be a Value Unit http://dlvr.it/3Dzns

Interesting Post... Do architects define the software development process? http://dlvr.it/3Dznm

Interesting Post... Traditional versus Agile — false war? http://dlvr.it/3Dzng

Interesting Post... A Pattern for Using Scrum and Kanban http://dlvr.it/3Dznf

Interesting Post... The Lean Product Backlog – Limit Variation and Prevent Overburden http://dlvr.it/3DznW

Subscribe to Leading Agile

Should Agile Teams Have to Call Their Shots?

What do I look for day-one coaching an agile team? The first thing I want to know is if the team is really a team? Do they have everything (and everyone) they need to deliver an increment of working software? Do they plan together, do they work together, do they deliver together? I'm generally of the mind that if you aren't going to recognize the team as the fundamental unit of value creation, you will struggle with almost everything else agile has to say about product delivery. You might be doing something... it might even produce working products... but it probably won't look very agile.

Once I have the team in place... the next thing I want to know is if they can make and meet a commitment. I want to know if they can be predictable. Right out of the gate, I am not all that concerned if the team can deliver fast... I might go so far as to say, I don't even care that they deliver value. To me, the most important thing is that the team gets good at establishing some sort of baseline velocity metric. I want them to be able to break down work into small chunks, put some sort of reliable point estimate on their work, and get good at doing what they say they are going to do.

Making and meeting commitments on a regular cadence is the heartbeat of an agile team.

Any of you guys ever play pool with your kids? When my kids were younger, they'd just walk up the table, quickly eyeball their shot, and do what they could to get the ball in the pocket. Every now and again they'd actually make a shot, but they'd never beat me playing an entire game. They were doing their best, but they never won. To really be successful playing pool, you have to be able to sink the ball you are trying to sink... and do your best to set yourself up for the next shot (or two... or three). Unless you are able to call each shot, you really don't have any idea how you are going to win the game. Success is accidental at best.

If the team can't call their shot... in other words, if they can't predict their velocity at the beginning of the sprint, there is no point doing any kind of forward thinking, any kind of release planning, or even trying to make a guess at what you are going to put in market when. Your product delivery dates are nothing but fiction. Having a stable velocity is the fundamental prerequisite for managing the expectations of the business. It's essential if you are coordinating with other teams to deliver the release, and essential for making tradeoffs when things don't go exactly as planned. Stability builds trust with your product owner and it builds trust with your business.

Do what do you think? Is it important for agile teams to be able to call their shots? I think it's essential.

Subscribe to Leading Agile

Change... The Only Constant

Sorry to be so quiet lately... lot's going on with me, both personally and professionally.

I need to bring you guys up to speed on a pretty big announcement. As of last Friday, I've left Pillar to go out as an independent agile coach. Pillar was a great learning experience for me, and I am thankful to Bob Myers and the great team of folks at Pillar for everything they've done over the past year. In trying to spin this thing up in Atlanta, I found myself spending most of my time doing sales and business development... and not working hands-on with teams and organizations.

I'm going to try to flip that around a little and try to spend most of my time on the ground coaching teams, and maybe if all goes well, I'll get to spend less time on the sales side... we'll see. What was cool about this whole thing, is that the guys at Pillar totally understood and supported me through this transition. We've decided to maintain a partnership... and a friendship... and where it makes sense, Pillar will help me scale some deals that would be tough to scale as an independent.

So... where does that leave me now? I've incorporated LeadingAgile and managed to find enough work to keep me afloat for the next few months. While I'd love to work close to home, I've got no geographic limitations. I need to fill my calendar through the end of the year and am interested in working with interesting people, solving interesting problems... where ever they happen to be. If you think my brand of agile is interesting to you and your organization, give me a call.

I'd love to talk about working together.

(PS - My contact information is at the top of this blog ;-)

Subscribe to Leading Agile

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

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 ;-)

Subscribe to Leading Agile

Okay... Just What are we Transforming?

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.

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

Ro-Sham-Bo... Shoot!

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!

Subscribe to Leading Agile

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

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!

Subscribe to Leading Agile

Let's Define Our Starting Place

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

Subscribe to Leading Agile

Fundamental Attribution Error

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!

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

Hyperproductivity in Scrum

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

Subscribe to Leading Agile

Is Kanban just Waterfall with Small Batches?

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.

Subscribe to Leading Agile