Agile Chronicles

Scrum or Kanban... it's not Black or White

It's been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson... this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.

One of the things I found really interesting over the weeked was the words some folks were using to describe the value of Kanban. They were using words like 'increased visibility' and 'buidling trust' with the business. While I wouldn't argue with any of that... I was struggling to figure out how the benefits of Kanban were any different from how we would describe the benefits of Scrum?

If both methods 'increase visibility' and 'build trust'... there has to be something more. In my opinion... the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.

Let me explain...

Scrum takes the approach that the team is a black box. The business puts requirements in... and after some predetermined amount of time... they get working software out. Within that black box... the team gets to self-organize... they get to self-manage. The business gets to decide what... the team gets to decide how. The processes inside the team are abstracted from the business AND from management.

Kanban takes the approach that the team is a white box. The business puts requirements in... but rather than leave it up to the team to figure out how best to deliver the work... management plays a role in defining the work. There are explicit workflows... work in process limits... and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.

One of the earliest agile books I ever read was Mary Poppendieck's 'Lean Software Development: An Agile Toolkit". Not long after that I read David Anderson's "Agile Management for Software Engineering". Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months... I found myself wondering what was so new.

We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered... we are encouraged to help them get finished before we start on something new.

Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints.

For some teams... in some environments... it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That's where I am not totally sold. For now... for me... Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.

But what if I already know everything!?

But hang on a sec! You might be thinking that you have all the information you need... and if I have all the information I need... there is no need to hold off making that decision. Right?

The problem with making a decision early is that you don't always know what you don't know. By buying some extra time... by deferring an option until closer to its expiry... you create an opportunity to learn MORE information... information you probably didn't even know would come available.

You might even end up with some new options... and guess what... those new options have value too! And that is the real rub... it's not just the value of the of the options that you have now... it's also the value of the options that have not yet presented themselves. There are times when it makes sense to decide early... but make sure you know why. Fear of the unknown is not really a good reason to decide early.

If you are deciding early because you think you know everything... you might be closing off options you didn't even know you had.

The Price of Freedom

How do we measure our freedom? How much does it really cost to make decisions that help us remain free? What steps do we take to endorse continued freedom and what do we sacrifice to make freedom available to everyone?

To some this may sound like pure patriotic banter, rest assured, there is a much deeper message. For some time, I have been advocating empowering Agile teams and allowing them the freedom to make choices that impact the progress on the project they are working on.

I have also at great length discussed the level of accountability that comes with the power to make decisions. After a period of deep retrospection, I have come to realize that for every organization, there is a price to be paid for freedom.

For most, the price is small in the sense that minor adjustments help the team stay focused and on course. For others however, this is not the case. People harness their new found power and create a negative environment where the work takes sidebar to personal and team agendas. This in turn negates the value Agile provides and taints the pool of hope for Agile to succeed.

In order to best take into account the one loose wing nut or rouge team within your organization, it is vital that some organization take place that sets a clear and solid mission with directive that establishes a goal with clear boundaries. Many people may feel like I am discussing Utopia here, I would argue that I am discussing practicality. It is OK to empower the team as long as the outer walls of the room still remain in place. It is more than OK to empower team members to make decisions that allow them to contribute at a higher level. It is not OK for team members to take this power for granted and create a price tag for hijacking Agile. (I wonder if that URL is already taken? http://www.highjackagile.com/?)

At this time of great economic recovery, we need to "let the product lead, make everything visible, and inspect & adapt often". Doing so, will allow for the price of freedom to remain low and afford organizations with Agile Implementations continued success. Now is the right time! Wave your Agile Flag! Consult your product council. Build tangible memories for years to come!

I'd Rather Be Wrong!

"If you choose not to decide, you still have made a choice" - Geddy Lee, Rush

Real Option theory tells us that our choices have value. In other words... the choices we make have an economic impact. Real Options also tells us that our options expire. That means we don't have an unlimited amount of time to make a decision. Playing the Real Options game involves figuring out just how long our options will be available... and using that time to gather as much information as possible... so we can make a better decision.

Earlier this year my wife and I were faced with a pretty tough decision. We were trying to figure out where to send our kids to school. The previous few years we had been running a small private school and our kids went there. We decided that our school was too much effort to run and no longer the best educational alternative for our kids... so we had a decision to make.

As we were trying to figure all this out... we identified three primary options that met with our educational goals... and were in alignment with our personal finances:

1. Continue to run our current school and send our kids there
2. Send our kids to a top notch public school that was nearby but out of our district
3. Send our kids to the nearby public school

Back in January we needed a plan but didn't have all the information. The pressure was mounting because if we wanted to pursue option #2, we had to apply and pay a rather hefty deposit. Pay the deposit and the option stays open... don't pay the deposit and the option expires. We decided to pay the deposit... not because we were sure we wanted to pursue option #2... but because it was worth the money to keep the option open a little longer while we figured things out.

What made the discussion interesting... and maybe even relevant our discussion here around barriers to agile adoption... was the difference between how I handle uncertainty and how my wife handles uncertainty. I am definitely the risk taker in our marriage... my wife likes to keep things pretty stable. On most things that is a great balance.... but sometimes when it comes to assessing risks and the best way to manage risk... sometimes we don't see eye to eye.

My wife's initial reaction was to commit to option #2... communicate our decision to disband option #1... and eliminate option #3 from consideration. The problem was that if option #2 didn't work out we would no longer have option #1 available. There was no economic value to locking in our decision early... but my wife's need for certainty would have caused us to commit before we had all the information. By waiting... by purchasing more time... we ended up with more information and that helped us make a more informed decision.

Its that fundamental need for certainty... and it is a need... is what makes the conversation difficult.

As a community... we are trying to get folks to embrace change and to embrace uncertainty. We've got to recognize that we might be asking folks to embrace more uncertainty that they can likely handle. The reality is simply that many folks would rather be wrong than be uncertain. If you are working with folks that are not risk takers... if you are working with people that value operating in highly predictable environments... Real Options can give you language to help them see value in deferring some subset of their decisions.

Making decisions early has an economic impact to our projects. If we can quantify that cost in terms of real dollars and risk probability... we might have a chance to change how people think about change and uncertainty.

Command & Chaos

Ever had one of those days where you just feel like you are reeling through the planning only to discover that once the plan is in place it is not exactly what you had hoped it would be?

As a result you decide the plan was poorly constructed and decide to plan again, only to find that by the third attempt that you may never get the plan just right. I am of the belief that a poorly designed plan that is executed actually gets the team farther than a perfectly designed plan that is never executed.

At the most recent Agile Roundtable we referred to this phenomenon as Command & Chaos. All too often we try to force the square peg through the round hole or try to perfect the square peg just so it will fit. A better approach would be to initiate contact with the square peg team and build a peg that works. A peg that can still be sanded, stained, and polished to look and work just as well if not better than the peg you started with. I have learned through experiences with my family that most often the poorly planned days turn out to be the most enjoyable. This is not to say that some planning is not important as a day at the pool in mid-January may not be as enjoyable as on a warm summer day.

When all is said and done, we should plan just enough to be responsible and execute as often as possible. Command & Chaos does not work and is certainly not going to solve your problems. Just ask Joe CEO (pictured above), and he will tell you that the Agile plan is in place to let him know sooner whether things are going smoothly or may not turn out as planned. The last thing we want to do is catch this guy by surprise. Be responsible, be accountable, be agile.

Are we Overly Compliant?

Last post I made the point that companies often have a hard time adopting agile because their management structures are not in alignment with their corporate objectives. We have project managers and resource managers and product managers. We have teams of specialists matrixed into product teams and project teams and component teams.

Each team has its own set of objectives... their own sets of metrics... and each are pulling the company in oftentimes competing directions. To create an agile organization... we need to get our core systems in alignment... we need to move toward common goals and objectives.

Legislation and Policy versus Intent

Paul Boos did a nice reply to my post and brought up a great point. Sometimes all those policies and metrics and such are self-inflicted. Paul works in the government and tells a great story about how legislation transforms from some idea with some worthy intent into a set of misguided policies and metrics at the department and agency levels.

Congress passes a law stating that government IT projects must have an Enterprise Architecture. The Office of Management and Budget then decides that all departments have to use their common architectural framework to be in compliance with the law Congress just passed. When Paul's particular department gets a hold of the legislation... and the guidance from the OMB... they determine that all technical decisions have to be passed through their governance committees. It's a way to make sure the USDA complies with the regulation coming down from on high. Now when Paul's specific agency get's a hold of the policy decision... they determine that the team is only allowed to use specific technologies that are already approved by the USDA and the OMB.

(NOTE: I slightly revised the previous paragraph to more closely reflect Paul's intent, and the way the government actually works... this is an oversimplified example by the way ;-)

The intent of the law was to foster collaboration and reuse between departments but gets implemented as a set of draconian policies that limit creativity and innovation. What would happen if we could rethink some of the policy and metrics and focus more on the desired outcomes?

Corporate Audits

Before I joined VersionOne I worked for CheckFree Corporation here in Atlanta (since acquired by Fiserv). Our PMO had put all these big tollgates in place so that our projects could pass audit. As our team was trying to drive agile into the organization... we would constantly get push back because our agile projects couldn't pass audit given we didn't have the right documentation at the right time to pass the formal tollgates.

Come to find out... the auditors didn't care about our tollgates... they only cared about our paperwork because we told them that was the process we used to create software. They didn't care that we used waterfall or PMI or RUP or whatever... they just cared that we followed the processes we had said we were going to follow. If we told them we were changing our process... they would hold us accountable to the new standard... and as a matter of fact... that is just what we did.

We took a fresh look at the audit process and established a framework that could be configured project to project. The new framework enabled traditional software lifecycles and agile lifecycles to coexist and both were able to pass an audit. By focusing on what we needed to accomplish... rather than how it was being accomplished... we were able to focus on optimizing the outcome rather than optimizing the existing processes we were using to get the outcome.

Monkeys and Bananas

Have you guys ever heard the story of the Monkeys and the Bananas? I sourced the story here... it is relevant to our conversation so here goes...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

Are we Overly Compliant?

So... how much of what we are doing is because we're a bunch of monkeys that don't know any better? How much of what we are doing is because it's the way things have always been done? How much of what we are doing is based on our interpretation of the law rather than from a firm understanding of the intent behind the law?

Have we taken the time to really assess these constraints and figure out what needs to change to accommodate our agile transformation?

Is your Organization out of Alignment?

Today is a good day. We got the kids up early... went out for a big country breakfast at Papa Jack's... and then drove up to South Carolina to pick up a mess of really awesome fireworks. You can't get really good fireworks here in Georgia... and since the South Carolina border is only about 90 miles North of Atlanta... we decided to make a trip. We've got about 20 lbs. of ribs basting in the oven... which should be ready in about an hour... so needless to say... but I'll say it again... it is a good day.

While we were driving this morning I got to thinking about my post from yesterday and why people fail to adopt agile in a meaningful way. We were talking about how often people fail to consider the human side of change. We tend to think in terms of process and practices... we don't think as much about the fears that are holding people back and preventing them from letting go. That said... and this was what was nagging me a bit... it's not fair to imply that fear, uncertainty and doubt are the ONLY reasons we struggle to adopt agile... often there are other factors at play

Our Trip to Disney World and Mike's Back Problem

I want to tell you guys a little story.

Up until last year... we used to take the kids to Disney World every October. Disney is great family fun and I highly recommend it. The only reason we didn't go last year was that the kids were getting older and decided they wanted to try something new. Last year we went on a cruise to Mexico.... but I digress. Back tot the point... the last time we went to Disney for vacation... I threw my back out the day before we left. I had never experienced anything like it. I've always been pretty healthy and have never had a back problem. I didn't know what to do and it sucked... sucked bad!

My kids we ready to go to Disney... my wife was ready to go to Disney... so we went to Disney. I spent the first two days walking the park... riding rides... and trying my best to have fun... but in reality I was pretty miserable. It's kind of funny... when I look back at the pictures from those two days... I had a smile on my face... but I can see the pain coming through the smile. Back problems are no fun at all.

The morning of day three I finally had enough. We were at Disney's Animal Kingdom and my wife looked over at me and told me I had to go to a doctor. Not knowing what the heck a doctor was going to do to get me through my vacation... short of prescribing some pain killers which I did not want.. I decided to go to a chiropractor. To that point in my life I had never been to a chiropractor and I wasn't sure what to expect...

Long story short... the chiropractor told me that my spine and pelvis were not where they were supposed to be and it was putting pressure on a nerve in my lower back. He did a minor adjustment and I was functional and relatively pain free the rest of the week. Good news is that I haven't had a problem since... the chiropractor found and fixed the root cause... I was out of alignment.

I had the desire to go to Disney... I had a great attitude... I tried to keep a smile on my face... I wasn't afraid to ride the roller coasters... the problem was it just hurt. My body was not in proper alignment to take advantage of all the fun that Disney had to offer. A bunch of the companies I work with are kind of the same way. They want to do agile... they want the business benefit... they want to change... its just that their organizational structure is not in proper alignment to get the full benefits. It's like being at Disney with a back problem.

How do organizations get out of alignment?

Our organizational hierarchies provide the basic infrastructure in which we operate... in which we run our business... that is our foundation. On that foundation we have many forces that pull that structure in lots of different directions.

We have projects run by project managers with schedules, budget constraints, and performance objectives. We have managers that manage teams of specialists... the managers are incented to optimize individual performance and get maximum productivity from each team member. We have products that have their own set of managers... each responsible for managing their markets and trying to get as many revenue generating features in their products as possible.

We spin up teams to do projects... so we have a project team view. We have to mange the component architecture outside the context of any single project... so we have an archtiectural view. Projects might also be part of a program or a portfolio, team members are matrixed across multiple projects, products, and architectural sub-components... all of which put different pressures on the enterprise. Its amazing to me sometimes that we manage to get anything done.

Steven Covey in his book The 8th Habit talks about how so few people in a company feel they understand the objectives of the organization... that that they are working on the most important stuff... or that they are pulling in the same direction as their co-workers. Covey compares this to a soccer team where:

• 4 of the 11 players on the field would know which goal is theirs
• Only two of the 11 would care
• Only two of the 11 would know what position they play and know exactly what they are supposed to do
• 9 players are competing against their own team

Getting on the Same Page

So... while the people issues are really, really important... it is also important that the organization get in alignment if we are going to make a serious go at widespread agile adoption. That means putting some thought into how we create teams... what we have them work on... how we measure their performance... and how we have them work together. Its a matter o aligning the structures of our organization and then aligning team to support those structures. That is fundamentally what will make an agile organzation work.

Like most things... that kind of change doesn't happen overnight... but realizing this is a problem is more than half the battle.

Why are you Failing with Agile?

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Yes... Agile Isn't Project Management...

...but it sure will change how you do project management.

I've got this talk called the Agile PMP: Teaching an Old Dog New Tricks. The first time I delivered the talk was last year at the Agile Development Practices conference in Orlando. So far this year I've done the talk for a few local groups here in Atlanta and then out in Vegas at the Better Software Conference and Expo. Later this year I'll deliver the talk at Agile 2009 in Chicago, the PMI Global Congress in Orlando, and the Agile Development Practices Conference... also in Orlando.

I've been pretty pleased with how well the talk has been received by conference selection committees and by the attendance at the shows. The talk works because it helps people understand Agile in the context of what they already know. We talk a bit about what is the same... and we use that commonality to explore what is different. At the end of the day... regardless of whether we choose to a traditional approach or an agile approach... we still have to deal with the fundamentals of project management.

Agile projects have to have a way of dealing with the triple constraints... there has to be some concept of time... some concept of cost... and some concept of scope. We have to manage risk... decide how we are going to communicate... and how we are going manage quality. How we go about doing these things on an Agile project might be different, but we need to have a shared understanding of how all this stuff is going to be accomplished. By helping folks understand Agile in the context of the PMI process groups and knowledge areas... we provide a solid baseline of understanding.

My core message centers around the triple constraints and our typical assumptions about uncertainty. Most traditionally managed software projects begin by defining what we are going to build... by defining scope. Once we know what we want to build... then we'll assess the requirements to see how much it is going to cost and how long it is going to take. There is always some acknowledgement of time and cost constraints up front... and there is negotiation with the stakeholders to get the three variables to converge... but starting with scope causes many software projects to start slow and finish even slower.

The problem happens when we go off and decide what we want to build without any idea of what it is going to take to build it. We create a wish list of things we'd like to have in the release and product managers get married to the ideas early on. It becomes tough to see how we can deliver value to market without everything we have spent all this time and energy to specify for the development team. I have worked on projects that needed to be delivered in six months and the product team created over five years worth of requirements.

When you push back... the discussion usually goes something like... well just do the estimate and tell us how much we can get. The problem is that it takes time to learn enough about the set of possible solutions to actually do an estimate... there might be technical dependencies... there are clearly resource dependencies... so evaluating a multi-year project to determine what can be delivered in the next six months can be a huge waste of time and resources. This problem is further compounded by changing market needs and the fact that software has a tendency to evolve... a lot... as it is actually built.

We create a false sense of certainty about what it is we are going to build and when we can get it done. Once time and cost commitments are made... being married to a fixed set of requirements is going to get in trouble. There has to be some room to negotiate as we go.

While Agile is not a project management methodology... it does impact how we do project management... mainly because Agile is going to have us make a different set of assumptions about our project constraints. Now... just like anything... these new assumptions and constraints need to be validated in your specific environment... but in general... on Agile projects we are going to decide that scope is not the primary driver. Rather than starting with scope... we are going to start with time and cost. We decide first when we need to go to market and how much we are willing to spend to get a product out the door.

Rather than create a giant wish list of features... we are going to start defining features to fill the time and money allotted. When we have filled up the time... and planned to spend all the money... we have to decide if we have a release that could be taken to market. There is a very subtle difference at play. There is still negotiation... still an assessment of the viability of the release... its just that we don't spend time assessing features that have no chance in hell of actually getting implemented.

In effect, we are talking about what agilists call product planning and release planning. We create a product plan... a roadmap... that gives us some confidence around what the customer is going to get... when they are going to get it... and what it will cost. The main difference is that we are starting with time and cost and figuring out what we are going to build within those pre-defined constraints.

Just because we started with time and cost... that does not mean that we can fix scope... we need some room due to our new assumptions about the certainty of our estimates and the stability of our requirements. Again... we are going to start with the notion that time and cost are our primary constraints and that we'll want to fine tune the scope as we go to deliver the greatest business benefit possible. Because we deliver working code on short cycles... and we have empirical evidence of our progress... we can constantly evaluate how we are doing against where we hoped to be. The project stakeholders have the ability to control the project... either by adjusting scope... or by adjusting the time and cost constraints... in real time as the project is progressing.

If at any time we learn that the business objectives and ROI targets cannot be met... we have the opportunity to kill the project... or radically alter its course... having invested as little as possible to make that decision. We are using the real data... being generated by real teams... writing real software... to provide feedback into the higher level roadmap. It really does put the business back in the driver seat. This idea that we are just going to start building software and let the backlog emerge.. the architecture emerge... and product emerge isn't workable in most contexts.

With all the talk of late regarding Kanban and single piece flow... I wonder if we will lose the ability to make any kind of commitment back to the business. I think that in some contexts... this is probably appropriate. In many though... we will still need to have the concept of roadmaps... vision... release plans... and product backlogs. I don't see these things as waste... but more as an acceptable level of overhead to give the business some idea of what they are going to get... when they are going to get it... and what it will cost when we get there.

So... again... we find that Agile is not a one size fits all strategy. We have to use our brain... we have to use ALL the tools and practices and principles we have at our disposal... we have to come up with the best approach to deliver the project given the constraints the business has imposed. At the end of the day... we are still doing project management... its just that agile changes the game a bit and introduces a new set of tools... and a new set of assumptions... and a new set of constraints which we'll use to deliver projects in more uncertain environments.

June Is For Commitment!

I, Project Manager, take you, Agile Methods, to be my wife.
I promise to be true to you in good times and in bad, in sickness and in health. I will love you and honor you all the days of my life.

I, Agile Method, take you, Project Manager, to be my ScrumMaster. I promise to be true to you in good times and in bad, in sickness and in health. I will love you and honor you all the days of my life.

Now on the surface this may sound ridiculous, but the real question seems to be who are we married to and why? What is the level of our commitment to success? What do we vow to do and what expectations do we have of others in the relationship? How serious are we about the projects we engage and how we leverage our teams?

Is this a marriage with a happy ending or is it destined to end in divorce? (We all saw what happened to Jon & Kate). Just as any good psychologist or Marriage Counselor would ask, what are you doing to enhance the level of communication in your relationship? What are you doing to make the relationship work better on a whole? What steps have you taken to work better together as a team towards a common goal? Have you set both short and long term goals for your relationship? Have you set and agreed to accept ground rules?

Is this an eternal commitment or is it until death do us part? Where do you expect this relationship to go and by what metrics do you measure success? The good news is that Agile Methods are for the most part very attractive spouses! They tend to help you increase your visibility and productivity.

With Agile Roots just completing and Agile 2009 just around the corner, I think it may be a good time to re-evaluate our relationships and make choices that support a healthy relationship. Even if that means revisiting the things in the beginning that drew us together as a pair. As people make more and more vows in the month of June, may we take a moment in retrospect to look at our own commitments and at what level we are working to exceed our partners expectations!