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