I Am Not A Supplier

Based on yesterday's thoughts on No Estimates, the discussion rolls back around to how I see myself as a developer:

I am not a supplier.
I do not simply provide services.
I am part of the business.
I provide value that moves the business forward.

As a developer, my goals are the same as the business I work for. I want to see the company succeed. The way I do that is to make the business run easier, more smoothly, and economically through the software that I build.

I am just as much a part of the business as Marketing, Strategic Planning, Operations, Sales, HR, and Maintenance. My role as a developer moves the company forward just like every employee of the company.

But this is not necessarily how the company sees me.

Just a Supplier?
This is a topic that I've written about before, and my thoughts have been coalescing over the years. At a company that I worked for, there was a Vice President of I.T. who had a goal: he wanted to be asked about the color of the carpeting in the new building.

What does this have to do with I.T.? Absolutely nothing. And that's exactly the point. In the executive meetings, the VP of Marketing was asked these types of questions, even though it has nothing to do with marketing. The VP of HR was asked these types of questions, even though it has nothing to do with HR. These groups were seen as integral parts of the company.

The VP of I.T., however, was only asked questions that had to do with technology. And this is indicative of the overall issue: I.T. as a supplier rather than a part of the company.

Coding to Specification Only

Unfortunately, many software developers see themselves as suppliers. They are not interested in understanding the business but are perfectly happy to simply code to a specification that someone else gave them. I've never been successful working that way. Only by being part of the business (and understanding the goals and how it works on a day-to-day basis) have I provided significant value as a software developer.

Common Goals & Vested Interest
This attitude of "just a supplier" has led to some issues that many companies are just now realizing. And it really comes to light with the phenomenon of outsourcing.

When you think of I.T. as a supplier, then it makes perfect sense to outsource it. It's not part of our core business, so we can get it from somewhere else -- like a utility. But then the reality of the decisions set in.

When a group is outsourced, they no longer share the goals of your company. Let's take a look at a scenario: your company sells consumer products on-line. The primary sales time is Christmas season (with a huge influx of sales on Cyber Monday).

Scenario 1: Common Goals
When the I.T. department is part of the company, then there is a common goal: success of on-line sales. So if credit card processing goes down on Cyber Monday, it's an "all hands on deck" situation where everyone is troubleshooting the issue. The network team is checking connections to the card processor; the server team is making sure that that servers are not overloaded; the database team is making sure that transactions are being committed; and the development team is checking to see how the applications are handling the loads.

Everyone is working toward one thing: getting on-line sales back up. It's what we do. It's the whole purpose for being there.

Scenario 2: Disparate Goals
Let's run that situation again, but with an outsourced I.T. department. Now the goals are different. The goal of the company is still the success of on-line sales, but the goal of the outsource company is to fulfill the service level agreements (SLAs) that are in the contract. The success of the outsource company is not dependent on the success of your company.

So if credit card processing goes down, there are trouble tickets that are opened. The company is concerned about every minute of outage due to lost sales. But the outsource company is concerned about making sure they fulfill their contractual obligations. This probably does *not* result in an "all hands on deck" situation (because that would have made the cost of the contract too high to be practical).

Unfortunately, I have seen this happen. Before outsourcing, we had dozens of team members troubleshooting various issues. After outsourcing, there was a conference call with the account managers and very little actually gets done.

There Is No "Us" and "Them"
One reason that the company treats I.T. as a supplier is because that's how we often act. We don't even act like a cohesive team within I.T. For some reason, we (as technologists) don't like to be seen as the party at fault. It may just be a side-effect of the other traits that make us good at working with technology. We like to be seen as infallible problem-solvers.

This leads to an "us" and "them" attitude with other teams inside I.T. So when a user calls in an issue with an application, we might say, "The application is working fine, so it's not us. It might be the network or database that's having problems. I'll forward you to the network team."

But we need to look at things from the user's perspective. The user doesn't care what the exact problem is or who is responsible for it. All he knows is that the application is not working, and he cannot do his job.

We need to react to the users with this in mind. If someone calls in an issue with an application, we should say, "I can't find the problem in the parts that I can see. Let me work with some other members of our team to figure out what's going on." Then work with the networking or database teams to try to nail down the issue.

And after solving the issue, the proper response to the user is, "We fixed the issue, and we're working to make sure that it doesn't happen again. But be sure to let us know if you run into the same thing." The user does not need to know whether the problem was the application, the database, or the network. The user doesn't care. All he wants to hear is that "we" (the I.T. team) have things under control.

Forming a Partnership
I've written many times about forming a partnership with the business areas. And I have been most successful as a developer when I had a good understanding of what my users needed to do on a daily basis -- the steps they went through to do their jobs. When I understood this, I could automate the little things to make their jobs easier. And I could make suggestions on bigger things that could streamline processes.

I knew that I was successful at building these partnerships when our company was hit by a round of layoffs. Most departments took a 10% staff cut. The first thing that happened was that my users were calling me for help, "We just lost 40 hours of labor; can you help us automate this process that takes 8 hours a week? That will take off some of the strain as we re-distribute work and re-prioritize."

It was these partnerships that kept us all moving forward in the same direction.

Wrap Up
What does this have to do with No Estimates? It's really a first step. Last time, we talked about the trust that is required between the business and development teams. But what if we eliminate that line that divides these two concepts? What if instead of having "the business" and "the developers", it was all just "us" -- a group of people all working toward the same goal.

I don't think of myself as a supplier. I am part of the business. I add business value. And when the business moves forward, I move forward with it.

There are times that I wished I ruled the world. I would try to spread this attitude to all of the developers who think of themselves as suppliers. And I would try to spread this attitude to all of the companies that think of their I.T. departments as suppliers.

In this world, everyone would be working toward the same goals. I.T. teams would be a true part of the business and continually add value. And companies would be more successful.

These changes are made one person at a time. I hope that you join me in this quest.

Happy Coding!

No Estimates: Development by Subscription

Last week, I spent a couple of days at Agile Open SoCal. It was a great time to talk about various issues and successes and get some great advice from other people who are in similar situations. There's a lot for me to process, and a couple of topics really stuck out.

One of these was No Estimates. I'll have to admit that I've been following this discussion from the sidelines. If you want to catch up on what No Estimates is, check out what Neil Killick and Woody Zuill have to say. I will not do the description justice, so you'll want to go to these guys who have been thinking about it for a long time.

I know Woody from the SoCal developer community, and I had a chance to sit down and talk to him a bit last week. (He's also known for showing the success his team has had with Mob Programming).

We Suck at Estimation
One of the basic truths is that we (as developers) suck at estimation. But that's not really a surprise. We are constantly being asked to do things that we've never done before.

An experienced cook will be able to tell you how long it will take a bake a cake. After all, he's done it a dozen times and knows what to expect. But for someone who's never baked a cake (like me), I would end up "padding the estimate" on how long it will take me. Is it because I don't know how to follow a recipe? No. It's because I'm working with unfamiliar tools -- I don't know exactly how to use the mixer or if I'm going to mess up a batch by over-mixing or under-mixing.

And this is true in software. Whenever I'm looking at a new project, it usually contains 4 things I've done before and 1 thing that's new to me. Now, I'm not completely ignorant of the technology (I've seen someone use the mixer), but I don't know what problems to expect (if you don't grease the bowl before you start, you won't get an even mixture).

I do not like to not deliver on my commitments -- meaning, I would rather over-estimate and deliver early than under-estimate and deliver late. The same is true in the rest of my life: I'd rather arrive at an event an hour early than 5 minutes late.

This means that I have a tendency to over-estimate:



I don't do this so that people will think of me as a miracle worker. I do this because I want to make sure I deliver on my commitments.

But this doesn't make my estimates any better than someone who under-estimates. In both cases, our estimates are wrong.

Eliminating Estimates
So, the idea of No Estimates is that we get rid of the estimation process. Instead of coming up with a huge project plan with lots of incorrect estimates (that end up compounding the problem), we focus on continually delivering small pieces of value.

I like the idea of this. And as a responsible developer, I think that it would work well for me and my development style -- I like to make my users happy, and I can best do that by constantly giving them features that make their jobs easier.

But I have been skeptical for a number of reasons. First, not all developers can work this way. There are some developers who would take advantage of the situation and slow down their delivery. There's no longer things like "story points" and "velocity" that measure productivity. And even though those measurements are probably wrong, people like to have something tangible to look at. The solution to this is to have managers who can keep track of productivity (in other ways) and know the capabilities and output of their teams.

Second, many companies cannot work this way due to their budgeting process. The financial systems are built around large projects and schedules. Marketing wants this and Sales wants that and Operations needs this other thing. So let's figure out how long each thing will take, how much our development team can handle at one time, and then prioritize everything. On top of that, money for the projects comes out of different buckets depending on whether it is a capital or expense project. I have no idea how to resolve this issue.

No Estimates is more of a subscription model for development. Instead of the business areas putting aside money for Project X that will cost $50,000 (maybe), the development team is funded on an on-going basis -- just like the other teams (finance, sales, operations, maintenance) that add value to the company.

The Business Areas Already Do This
I had a realization about this based on my experience: even though the company does not work this way, the business areas do.

I worked at a large company (20,000 people on site, 100,000 people in the division), and I built software for the various business areas based on what came down from project planning. And this was a hassle for many of the business areas. Sometimes a department just needed a small piece of functionality. It wasn't large enough to justify an entire project -- maybe just a report to collate data. And even if it were big enough, it probably would not be prioritized near the top of the list. So it may take a year or more to get it on the schedule.

The solution: Shadow IT. I don't know if there's an industry name for this phenomenon, but this is what we called it in our company. A department would have someone on staff who was more technical than most and probably good at something like Microsoft Access. This person would then build all of these small pieces of functionality that the department wanted to make their job easier.

So the business areas have already bought into the idea of development by subscription. They have decided that it was worthwhile to pay someone in their department to handle these types of things. And this Shadow IT person was paid out of the same budget as all of the other employees in the department.

(And this arrangement isn't all puppies and rainbows. Since the majority of the Shadow IT people did not have any formal technical training or experience, some of the projects would run into scaling issues or simply stop working when the data got too large. At this point, the systems were critical to the department, so they would often turn to the development team to fix the issues or rewrite the system.)

So the business areas have recognized this as a way to add value to the company. Now we just need to get the company itself to realize it.

This would give the opportunity for the business areas to have access to actual developers who can deliver functionality quickly in a supportable way.

Wrap Up
I really like the idea of No Estimates, and I hope that it gains traction. There is a lot of trust required between the company and the development teams (but I've wanted to have better integration between the company and the development teams for a long time -- that trust is needed anyway).

It was an eye-opener when I realized that the business areas had already implemented their own version of No Estimates by having a Shadow IT person on staff. Next, we need to figure out how to formalize this so that the right people (developers) are doing the right work.

Happy Coding!

The Key to My Success: User Interaction

A couple months ago, I wrote about the importance of development teams and the business areas working together (Development and the Business - A Partnership).  This is a topic that I've been thinking about quite a bit recently as I review the applications I've been involved with.

The applications in my career that I consider to be most successful are the ones where I was constantly involved with my users.  There are other applications that have had limited user communication that have resulted in successful applications, but the process was extremely painful.  A couple of applications fall into the failure category, and these happen to be the applications where I had zero user contact.

This lines up with two of the four points in the Agile Manifesto:

o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan

These are elaborated in the 12 principles behind Agile.

So, let's take a look at some of the successful and not-so-successful projects I've worked on and why I consider user interaction to be a key component in what has worked well.

Just a quick note about my terminology: I would normally refer to people by name (since they are people).  But to keep things (semi-)anonymous, I will refer to someone as the "user" or "super user".  This is simply because I can't refer to them as "Frank" or "Janice" here.

My First Project - The One that Wouldn't Leave
I actually got into development as a profession almost by accident (I'll say almost because I wanted to be a developer and was looking for ways to break in, but this opportunity came up by chance).  I was on the user side of a multi-year project to build a system that would consolidate information from different departments around the company.  During the pilot phase (that is, figuring out what we wanted the development team to build for us), I got to know all of the people in the various departments that would eventually be using the system.  We were collecting the information manually and figuring out what we needed for incoming fields, approval processes, and outgoing reporting.

During this process, the manager who was working on the developer side of the project saw that I had some qualities that could make me a good developer.  So, about a year into the project, I was offered a junior developer position.  And that's how I got started.

Now, originally, the project had a team of about 6 people, and I was doing the types of things that you would give to a junior developer at the time: slinging around a bit of HTML and learning how to write Crystal Reports.

Fast forward a bit: the project is released, the senior developers go on to other stuff, and I end up as primary support for the application.  This made sense since a lot of the issues that came up were odd behavior related to reporting or some of the SQL behind it, and I could always ask questions of the original developers.

But it turned out to make sense for a much bigger reason: I knew the users.  Since I had spent so much time working with them on what the system needed (i.e., gathering requirements), I had built a relationship with them.  And I ended up supporting this application for close to 10 years (until I left that company).

A Couple Key Wins
The application had 2 primary pieces: a Windows application used for data entry / administration and a web application that was used for reporting.  I was given the task of re-writing the data entry application at one point, and I took that as a chance to add some things to help out my users.

The Tedious Process
The data entry application did not have any reporting at all (you had to go to the web app for that).  One of the business areas handled approvals for the items that were entered into the system.

I visited their office one day to talk about some things in the application. While they were working, something caught my eye. And it was something I hadn't anticipated.

In watching their process, I saw that they printed out a copy of an item after it was approved; this copy was then put into their files. And the current system was a bit tedious:

1. Open the data entry application to get the list of items to be approved.
2. Approve an individual item.
3. Open the web application.
4. Navigate to the Search screen.
5. Use the search fields to locate the item they just entered (and based on similar names, this was sometimes tricky).  This was generally the most frustrating part of the process.
6. Print out the item from the web application.
7. Go back to the data entry application to approve the next item.

This is what these users did for 3-4 hours per day.  I like to make jobs easier.  So when I saw this, I offered to add a Print button to the approval screen. This would take me about 5 minutes to do (I already had the code), and it would make their process much easier:

1. Open the data entry application to get the list of items to be approved.
2. Approve an individual item.
3. Print out the item from the current screen.
4. Go back to the list to approve the next item.

This completely eliminated the most frustrating part of the process and made their work much easier.

The reason I found this problem is because I actually watched people using the system.

Eliminating Data Entry
For some departments, the new system eliminated the need for them to maintain their own data.  For other departments, the new system would not be a replacement.  As an example, a department had a financial system that they used for resource planning and scheduling.  All the new system cared about was one small piece of their existing data.  This resulted in a bit of duplicate data-entry (at least to start with).

Once the new system was running and stable, we started to look at where we could eliminate the duplicate data entry.  Again, because I knew the users and spoke with them regularly, I could prioritize based on which of the business areas would get the most benefit.  If a department had dozens of items a day to enter, we could prioritize that automation over those that had only a few items a week.

Also, we could determine how to automate based on the timeliness of the information.  For items that were scheduled several months out, we could do a once-a-day import from the systems.  Conversely, for items that would result in immediate change to operations planning, we could tie more directly into the source systems for close-to-real-time data.

The Key to Success
My ability to make these choices -- the choices that ultimately affect the business -- was due to my relationship with the users in the various departments.  I continued those relationships for many years.  And when someone left a position, I went to go see the replacement in person as soon as I could (this was really easy when they were in the same building; a little more difficult if they were on the other side of the 100-acre property).  My goal was to establish very quickly that I was committed to their success.  Fortunately for me, most of the people who left positions told the new person that I was really good to work with.

The Project That Could Have Been a Disaster
One project sticks out where user interaction really saved the day.  This was a rewrite of an Access application that had been built by someone in the business area.  The application was having issues with scaling and was crashing fairly regularly.  They came to the development team to build a stable app.

I was the development lead, and my first request on the rewrite was for me to go out to the business area, do some job shadowing, and find out what they really need.  Unfortunately, that was not approved, and I was given the directive that the new application should do exactly what the old application did.

This is never what you want to hear.  In this case, there were 2 reasons I didn't like it.  First, I didn't know whether the current application actually met the users' needs.  Second, the current application consisted of about 20,000 lines of VBA code (it still gives me shivers to think about it).

I built a very good relationship with the super user.  He knew the functions of the current application, and he also fielded questions and issues from the users.  He became my source for real knowledge.

So, I dug through each module of the Access application.  More often than not, I found out that the application code was not actually doing what the users thought it was.  For example, there was an part of the application that looked at the city of a customer record and gave back the current local time for the customer.  The actual code had a hard-coded list of cities for each state along with the time zone.  The problem is that then a city wasn't found in the list, it would just pick the first city in the list.  This meant that it wasn't always accurate (particularly for states that had multiple time zones and/or multiple rules about Daylight Saving Time).

If I were to simply "do what the current application did", I would end up reproducing the errors.  If I wanted to make the function accurate, I would need to figure out a better way of getting the current time information (maybe a call to a web service?).  But it turned out to be much simpler than that: I talked to the super user.

In talking to the super user, I found out the intent of this function.  There were situations where the department would call a customer, and they wanted to make sure that they were calling within a particular window (for example, not after 8:00 p.m.).  It turned out that they didn't need the precision of a particular city, just a general idea.  So, instead of a function that would tell the time for a city, I provided a Time Zone map that showed the current time in each time zone.  This was a fairly simple solution that met the users needs.

I have many other examples from that particular application.  Time after time, communication with the users saved me from over-building and allowed me to provide a system that more closely met their actual needs.

Disaster averted.

Disaster Not Averted
Unfortunately, not all projects can be successful.  I can think of two projects in particular that were extremely difficult (and ultimately never made it to release).  In both of these scenarios, I was "insulated" from contact with the users through a project manager.

In one scenario, all of the requirements came through the project manager.  I was only given what the application should do (i.e., it should show data this way, it should print that way); I was never given visibility to the actual business issues that we were trying to solve.  I just had a solution.  And I was doubtful whether that solution was really what the business area needed.

Ultimately, that version of the application was never released (which was a frustration to me even though I only worked on it for a few weeks).  The good news is that a year later, an updated version of that project came up, and I got to work on it.  In that iteration, we were working closely with the user group and created a very successful solution.

In another scenario, the requirements were coming through a (different) project manager.  For whatever reason, she didn't want us (the two developers on the project) talking directly with the user.  I'm still not quite sure; it might have been for political reasons.  The problem is that whenever we came up with a prototype, we would give it to the project manager who would test it before giving it to the user.  When the changes would come back, we would never get the "why" of the change, just the "what".  And whenever we had a question about a particular function, it would go through the project manager and take about a week to get the answer back to us.

That project was put on the back burner several times, and it still wasn't finished when I left the company two years later.  Kind of sad because it was something that could have been very useful.  Sometimes we don't have as much control over the situation as we would like.

Wrap Up
I have many other examples from my career.  Fortunately, most of them have been successes: like the time that the project manager was someone who used to work in the business area.  Again, she had the answers to most of the questions, and if she didn't she had all of the right contacts.  In addition, she didn't insulate us from the users; instead, we had conference calls and were encouraged to talk to them directly.

I've worked on a number of different projects in different environments (at one company, I had primary responsibility for 20 applications when I left).  The projects that I consider to be most successful have one thing in common: constant user interaction.  Meet face-to-face when you can; we need to realize that we are all people, not just voices on a phone.

Building real partnerships with the business area is how I've been successful.  And I'm not sure how you can build a successful product if you don't truly understand who will be using it and what their needs are.

Happy Coding!

Development and the Business - A Partnership

A couple of months ago, I posted some thoughts on The Clean Coder.  Part of this included how developers should be in a partnership with the business area.

This was reinforced in a recent episode of .NET Rocks! (Is Agile Dead at CodeMash).  A panel member (sorry, I don't remember which one) polled the audience.  First, he asked how many people were part of the "business".  Result: one or two people.  Then, he asked how many people were part of "I.T."  The result was most of the audience.  He immediately said that this was wrong -- that everyone is part of the business.  That's why we (as developers) exist.

As another example, we can look at the Principles behind the Agile Manifesto. Specifically, "Business people and developers must work together daily throughout the project."

Forming a Partnership
So, how do we go about forming this partnership?  Previously, I mentioned that I really didn't know.  But it turns out, I did.  I just needed to look at my experiences in a bit of a different way.  I mentioned how I have worked in an environment where the development teams and business areas had very good relationships.  But even if we don't have this particular environment, we can work towards it.

Note: I'm approaching this from the standpoint of a corporate developer -- a developer who is building applications to help the company get work done.  You will need to modify these ideas just a bit if you work for a software company or build products for people who don't work for your company.

Watch: Learn How the Business Works Today
The first step is to see how your users do their day-to-day work.  Start by spending a day with one of your users.  Watch everything that he or she does.  Your job at this stage is to simply see how the folks in the business area get their job done.

Keep your mouth shut.  Think of yourself as a wildlife photographer -- you record what takes place in front of you, but you're not allowed to intervene.  If you see someone fumbling with a process or a piece of software, make a note of it, but let him fumble.  You're not there to give advice; you are there to see how things are done.

Take notes, but don't immediately start thinking about how you would change things.  As developers and problem solvers, we have a tendency to let our brains run wild.  But this distraction can keep us from making some important observations.  So, just keep watching.

Listen: Learn How the Business Wants to Work
The next step is to talk to your users.  Ask them what they think would make their jobs easier.  Find out how they want to work.  This is still part of the observation stage.  Don't immediately start trying to solve problems; just keep collecting information.  The key is to listen to how they would change things.  Periodically review your notes with the people you are talking to.  This will ensure that you are collecting the correct information and has the added bonus of giving the users confidence that you are really there to listen and help.

If you're dealing with front-line workers, also talk with their management team.  Ask the managers what they think works well and what doesn't work well.  You may find out that the management team would like the front-line workers to focus on different priorities -- maybe there are short-term goals that change from time to time.  If you can, try to sit in on one of their team meetings.  This will give you better feel for what is important to them.

As before, don't let your brain start problem solving.  You're still collecting information.

Analyze: Review What You Learned
After you've collected your information, it's time to start analyzing.  Now is time to let your brain run wild.  Think about the software that is being used (or not used).  Review the stumbling blocks the users may have had (for example, did they have trouble finding a particular function?).  Think about the processes that were not automated that could be.  Maybe you noticed that someone took data from an email attachment and re-keyed it into a different system.

At this stage, don't be afraid to follow up with anyone that you've talked to out in the business area.  Often, after you start analysis, you find out that you don't have all of the information that you need.  You can use some quick follow-up questions to fill in the gaps.

Contribute: Take Your Plan to the Business
Now that you've had a chance to come up with some suggestions, it's time to take them to the business.  Start by grouping your solutions into "quick wins", short-term, and long-term time frames.  Once you have this, go back to talk to the folks in the business area.

Hopefully you have a couple of "quick wins" to start with.  These are items that would be easy to implement from a technological standpoint (with minimal cost and resources) and would add good value to the business area.  This is where you start to build trust.  The quick wins show that you understand the business and that you are able to help.

If you "missed" on the quick wins, don't get discouraged.  If the business area did not like your ideas, it's your chance to gather some more information.  Ask some clarification questions and listen.  Figure out what you misunderstood and work toward correcting that.

If the "quick wins" are a hit, then give brief descriptions of your short-term and long-term solutions.  This is an opportunity to plant some ideas for future projects.

Continue: Constant Interaction
Congratulations, if you've gotten this far, then you are well on your way toward a good partnership.  Now you need to make sure that you continue this relationship.  If you start implementing some of the solutions, stay in constant contact with the business area throughout the process.  Give them prototypes and get feedback as you go.  Back to the principle we mentioned earlier: "Business people and developers must work together daily throughout the process".

Benefits of a Partnership
Ultimately, the business benefits from this relationship.  As a developer, you are more in tune with how the folks in the business area think.  Your software will naturally head in the direction that the business needs.  In addition, the folks in the business area will trust your judgment.  Once they see that you are all working toward the same goal (the improvement of the business), then they are more likely to accept your suggestions.

A partnership is about building on the strengths of both members.  The business area has operational experience -- they know what work needs to be done.  The development area has technical experience -- they know how to automate processes and build working software solutions.  Working together, the entire business benefits.

Getting Buy-In
One of the issues you may face is getting buy-in from your management team.  It may sound like you will be spending a lot of time "not developing" as you are doing "partnership" work.  But this really isn't the case.  Plan on spending one day a month in the field -- this really isn't all that much.  The rest of the time is touching base from a few minutes to an hour at a time.  You might spend a bit more time getting things started, but it will just become a natural part of your work after that.

"Agile" is a very popular term to use.  Many development teams claim to be Agile, but often they are only using a couple of buzzwords and work in "sprints".  But ultimately, Agile is about getting working (and useful) software into the hands of your users as efficiently as possible.  If you don't understand how the business works, then this becomes very difficult.  (Note: this is part of the discussion of "Is Agile Dead" from the .NET Rocks! episode mentioned above.)

Wrap Up
I have been fortunate enough to work in a very productive environment where I was able to form strong partnerships with my users.  In that position, my management team understood the importance of these relationships.  I was able to respond quickly to my users' requests (since I understood what direction they were headed), and I was also able to make relevant suggestions to improve the process.

Just remember:

• Watch
• Listen
• Analyze
• Contribute
• Continue

It's important to remember that we are all working toward the same goal: the success of the business.  The better that we understand it, the better we will be able to contribute.  And, ultimately, we will all succeed together.

Happy Coding!