AdrianCarr.com ^1.0

I recently gave a talk at CodeStock entitled Agile: What's in it for Me? You can download the PowerPoint presentation here or watch it below.

Sprint Reviews- The Product Owner and the Team present to the End-User

These are some notes that I put together for use in a longer post, but haven't found the time to write it. I thought this might be helpful for someone out there as it is, so I'm posting it. If you do find it helpful, or have any questions, you can let me know at my contact page.

• Demonstrates working software, instead of promises of working software. As we know from the Agile Manifesto principles, working software is the primary measure of progress.
• Enhances communication, from the team and to the team.
• Force the team to tie up loose ends and get "done" software together.
• Forces testing early and often.
• Forces surprises to pop up early.
• Allows end users and stake holders to actually see the software that they will be using, and this helps to eliminate surprises.
• Enables team to get feedback from end users on actual working software early and often.
• Allows the team to get a pat on the back every few weeks. Helps motivate and energize the team when people are excited about the work they are doing.
• Builds trust that the team is truly building functionality and not working on vaporware.

Tips:

• Make them fun- Serve food or some sort of refreshments.
• Make them be informal, so people are willing to talk and ask questions.
• Minimize the use of PowerPoint, and make most of the review about the working software.
• Invite questions, criticism, & feedback.
• If the review is the first time your Product Owner has seen the software, you are doing it wrong. Get the Product Owner onto your team, sitting with you. Get them to help test from time to time, and let them see changes every day. This minimizes surprises and rework.
• Schedule reviews at the same recurring time so the team, management, stakeholders all know what to expect. Avoid the "Oh, now that the sprint is done, I have to find time for the review." If people know that you run three week sprints, and the review is always on the third Wednesday at 9:00 AM, there are no excuses. This encourages people to arrange their schedule around your review, rather than your review around their schedule.

For some strange reason, I think a lot about software, business value, economics, work environments, technology, and mostly about how all these things come together. Sometimes, to help me make better sense of my thoughts and to keep them from getting all jumbled together, I write them down.

Not too long ago, I started sharing them out on the internet. At the time, I really didn't know why I decided to share them. Most (probably all) of the people around me are smarter than I am, and I really don't write very well, and I'm definitely not a great programmer (when compared to the amazingly smart people around me). So why should I write about and share these things when there are others that are much better at this than I am?

Well, I'm glad you asked.

One of the reasons is that I know from experience that it is a very, very bad idea to go off and work on software for a long period of time and then eventually hand it over to the customer and hope you got everything right. For some people (and me at one time), this is a revelation. I mean, how could we not get everything right when our business analysts spent so much time interviewing and meeting with the customer and getting every last detail agreed to and then signed off on? This concept became very clear to me several years ago when working on a multi-year project where the company I worked for provided a very large software package for Toyota Financial Services.

Talented Business Analysts.

First of all, we had extremely talented and very thorough business analysts. These business analysts were smart and knew their stuff. They had years of experience in the banking industry, and they knew our product really well. They went to California and worked with Toyota business analysts and gathered the requirements and spelled them out in great detail. It was really important that the requirements be spelled out because the contract, including pricing and timeline, was based on these requirements. Since the contract was based on the detailed requirements, changes were strongly discouraged so the requirements had to be right from the start. It seemed like they haggled and negotiated over the contract for months, but eventually, it was finally signed off by both parties.

Great Project Managers.

We also had great project managers. The project was broken into three phases that were scheduled over a couple years. Project managers created very detailed charts and timelines and strategies for success. The requirements for the first phase were handed off to us developers. We designed and developed the software for months and months. The project managers created beautiful progress charts from the weekly status reports we filled out, and distributed them to the managers and to project managers at Toyota. We all felt great about it for quite a while. We all smiled, the company threw parties, and life was great.

These status reports remind me of a presentation by Scott Ambler about agile practices that I attended at a Dr. Dobb's Best Practices conference in Boston. Someone stopped him and asked "What about the status reports?" Scott calmly turned to everyone in the room and asked them: "How many of you have to fill out status reports?" Around 80% of the people raised their hands. Scott then asked them: "How many of you trust the status reports? Two or three hands went up. This was in an audience of about a hundred people. It was immediately obvious. Status reports are too often inaccurate, and people are usually making the numbers "look right". I used to do it, thinking that I'll have a breakthrough soon where I make a giant leap forward. Traditional status reports are a waste of time and often give people a false sense of security.

The Development Process.

After a while, I became a team lead, and soon realized that I wasn't the only developer stuck at a status of 80-85% done for week after week. It seemed like that last 20% took half of the time, especially when we ran into some ambiguous detail that a person could read in a couple different ways.

"Your entree comes with a salad and fries or green beans." 

Wait a minute. Does that mean I always get a salad and I can choose between the fries or beans? Or, does that mean I can either have a salad or I can have the fries and beans?
On a software project, one way might mean a couple days of work. The other way might mean a couple weeks or months of work. So clarification is important, but sometimes takes a lot of time, especially when the communication has to filter its way through lots of people. Then, what happens when the clarification comes back and everyone on our side wrongly assumed that it meant the easier option? Or, what about when the you reach a technical limitation and you aren't going to be able to deliver the exact feature as described? Uh oh. Change management time, and arguing over the contract, who's going to pay for the increased time to develop it, and who meant what when they wrote the requirement, whose fault it is that the misunderstanding occurred, etc. It's not pretty.

Late to QA and Getting Later.

Eventually, we finished the last little bits (well most of them, with the unfinished part to be tacked on to the next QA cycle) and handed it over to our QA department. Of course, by this time, we were running late. Then, an unexpected (at least, unexpected to me) thing happened. They found all kinds of bugs. I mean LOTS of bugs. Big bugs, little bugs, hairy bugs. So we fixed most of them and gave it back to them. They found more bugs, and we fixed them and gave it back again. We did this over and over and over until we finally had a pretty stable release ready. We sent off a release to Toyota to install and for them to do some quality assurance on.

The QA staff at Toyota now had their turn, and a surprising (at least to me) thing happened. They found some bugs. All kinds of bugs. Not nearly as many as our QA department had found, but quite a few nonetheless. Well, we fixed most of them and gave a version to our QA department who verified that they were fixed, and we gave Toyota another, cleaner version.

Of course, by this time, we were running pretty far behind schedule. The managers and project managers were wringing their hands and having lots of meetings and I heard some rumblings about the contract, but the old timers on the development staff didn't seem too surprised by all this, and looked at it as quite normal.

Delivery Time.

Once the release was ready and all the details worked out, our managers asked for volunteers to travel to Toyota to support the install and release. I signed up to go. I had never been to California, I enjoy traveling, and like a good adventure from time to time, so why not?

User Acceptance Testing.

While I was there, I watched people use the software for the very first time. I showed up bright and early the first day, and waited with nervous anticipation for the install and everything to be turned on. After a couple small hiccups that we were able to overcome and document and promise would never happen again, we turned on the system and a few people logged in. One of the first people to login for the UAT was a really nice lady. I don't know what her normal job was, but clearly, she was used to doing some job that our new system was going to have an effect on and she had been asked to evaluate it. She used our software for about five minutes before she called me over because she wanted to show me something. Imagine my surprise when she told me that our new, fancy, multi-year, multi-million dollar system wouldn't work for her and couldn't possibly go to production. I was floored. I mean completely flabbergasted. I couldn't hardly believe her. But, she patiently showed me why it wouldn't work, and explained her job to me and how her old system worked, and how the new system worked. A Toyota business analyst came over and looked at it, and studied it for a long time, and eventually agreed with her.

I didn't know what to do, but a light bulb came on for me. I thought to myself: "How could we have missed that? If the developer who did that work knew what the end user really wanted and had worked with them, they would have gotten it right the first time, with ease." This was the first time I realized that maybe something wasn't quite right with this long discovery-document-design-development-test-deliver strategy. But, that thought didn't last long, because my next thought was: "Hmmmm..... I have the source code, and I could fix that in about half an hour." After some meetings, some explaining, negotiating, documenting, and hand wringing, they actually let me make the change and recompile right then on my laptop. I was pleasantly surprised, but glad that we could keep the project moving forward.

Production, and Phase two

We eventually got the first phase of our system in production about a year after starting the project, much later than originally planned. It didn't take long for new bug reports to come in, and feature changes to be requested. We had lots of situations where the detailed specification just didn't catch all that was needed, or the programmer completed it as described, but not in a way that was really useful to the actual end user who had to sit down and work with it day after day. Now, we had a dilemma. Since we were already behind, we needed to get right to work on the next phase of the project. But, we also had more work that came out of the release than we expected. Once again, many meetings, org changes, wringing of hands by project managers, and contract renegotiation. It wasn't pretty.

Back to the grindstone.

Eventually, the project managers figured it all out and we got back to work. We worked through the bug list, and added the feature requests and unexpected changes to the list of planned enhancements. It wasn't long before we were back in the same situation we were before, where we were running behind, lots of bugs, endless QA cycles, painful change management meetings, and eventually, loooooong days and some weekends.

The Eventual Outcome.

I won't bore you with the rest of the details, but suffice it to say that we basically repeated the process from phase one. The project went downhill, ran later and later, ended up costing lots more than originally planned, the company lost lots of money on it, and Toyota ended up suing us. Parts of the project were in production, and parts never made it. Millions of dollars worth of hard work, careful planning, and functionality never made it to production. Millions of dollars spent without the business value realized.

Could this project have been successful?

I think so. I saw both sides, and besides being a developer and team lead, I filled in as a business analyst, and even did a short stint in a project manager role. I may be dreaming, but I really think I could take this same project and make it successful with what I know today. If I'm completely wrong, it would at least fail faster, and as a result, save millions of dollars, some bad feelings, and a lawsuit.

What would I do different?

The first thing that I would do differently is that I would run the project with agile principles instead of as a traditional project.
As a review, here is what the Manifesto for Agile Software Development says:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

Get the people together.

One of the first things that I would do is get the people on the projects together, even if it was only temporary and occasional. Since Toyota Financial Services is headquartered in California, and we were in Georgia, this would have been difficult and expensive, but worth it. I want people on a project to know who they are working with and developing for, not just what they are developing. I would have the people from Toyota show the old system to the developers, and show them how the business works and talk about what they really hoped to accomplish with the new system. When developers know whose problem they are trying to solve, and what that problem looks like from an end user's perspective, they typically do better work.

Create a better contract.

With traditional contracts where the cost, scope, and time are fixed, someone is going to get the bad end of the deal almost every time on a large project. This has worked several times for me on small projects, but on large projects, it's a losing game. Think about it. Let's assume you're going to sign a contract with me that says you will do "x" for "y" dollars in "z" time before we ever start the project. You have a motivation to make sure you don't get the bad end of the deal, so you make a lot of assumptions and then "pad" the amount of time and the cost upwards to make sure you don't lose money. From my point of view, I feel good because I know what my expenses are going to be. Now, the financial risk is on you. However, I also know that I have to get my requirements defined up front, and while we will probably have some small amount of changes specified in the contract, I have to make sure I get almost all of my functionality defined before we even sign the contract. Now, stop to think about this for a minute. At what phase of a project does everyone know the least about it? Answer:At the start of the project. Why do we think it makes sense to try to define everything and contractually obligate ourselves at the point where we know the least? This is stupid. What it leads to is a lot of guessing and assumptions on everyone's part so they don't get a bad deal. It also has the side effect of adding unneeded functionality to the list of requirements. If change management is resisted so hard, and the contract doesn't allow large changes later, I have to add things to the requirements that I may or may not need, because if I figure out that I do need that functionality later, it is too expensive or difficult to add it after the project has started. Several studies have shown that a huge percentage of features in large software systems are never used. (You can read more about this here. )This is a waste of money and time. Agile projects allow the business to get the highest value features and functionality in production soon, before all of the less valuable stuff is implemented.

I would still have a contract, and I won't go into a lot of detail here, but it would be crafted in a way that would encourage us to work together, rather than foster an "us" vs. "them" mentality. I wouldn't fix the time or the scope. If they needed to put a cap on the cost, that would be fine, but the contract would require regular payments as functionality was delivered, and we would keep delivering until the cost cap was reached. Hopefully, by the time the price limit was reached, we would either be done, or would have built a level of trust that allowed us to continue working together. This encourages us to deliver useful, working software early and often. There would be requirements and rewards for regular delivery of useful software. There would be some protections for each "side", but encouragement to keep the project moving forward in a manner that serves both parties. Changes would be welcomed, and encouraged. To sum it up, the contract would be written in a way that encourages "customer collaboration over contract negotiation".

Build Quality In

Our QA department was pretty good, but they never got to do any testing until the end of the development cycles. Often, I'd get a bug report and have to go back and fix it, and I hadn't worked on that code in months. I'd long since moved on to lots of other features and changes. It sometimes took a while just to remember what exactly I had done and why I had done it. Not only that, but almost every time, we had to cut the planned QA time drastically, and they often didn't have time to test everything.

I would also integrate the QA staff onto small teams with the developers and business analysts and have them all sit near each other and work together daily from the start. As discussions were happening between the developer and business analyst, the QA person would hear what was being discussed. I'd get the QA person involved in design and database discussions so they understood things better.

Automate testing. I would require that my QA people be able to write automated tests. I would also require that my developers write unit tests. Now, this would have been particularly difficult on this project because the code base was huge, and old, and written in Visual Basic 6. However, it can be done. As more and more unit tests get created, you get more and more code coverage, and you get more confidence in changing complex business logic, and faster feedback when things are broken.
Here's a great quote from a member of the Agile Atlanta User's Group:

Top-producing teams don't correct errors, they prevent them, using all tools at their disposal, including their own attitudes; that's why they are top-producing teams. -Joseph Beckenbach 

Frequent Delivery of Working Software

In the project described above, the primary measure of progress was Gantt charts, documentation, training manuals, and promises of working software. The primary measure of progress on an agile project is working software. I wouldn't even think of going a year without delivering software to production. I would work with the client to figure out what valuable features we could get out the door quickly. It isn't until the actual end users get to touch and feel and use the system that they figure out what works and what doesn't. This doesn't mean that we have to deploy the whole thing at once. I would figure out a way to make lots of small deliveries along the way, each time building on the last. As people see that working software really is being created, trust is established. There was no trust on that project, and this was one of the primary reasons for its failure.

I've seen a better way.

So, that's it. That's why I write. Because I've been very involved on both sides of the coin, and seen a better way of doing things. Here's the inverse of the Agile manifesto, and exactly the way we ran the project I've described here. It's a terrible way of delivering software, and a terrible way of working. It even sounds stupid, but it is exactly the way most software projects are run.

• Processes and Tools over individuals and interactions
• Comprehensive documentation over working software
• Contract negotiation over customer collaboration
• Following a plan over responding to change

I hope by writing these thoughts and experiences down that I will help others avoid these same mistakes. I view it as similar to contributing to the free and open source software community, except instead of software, these are my thoughts and experiences for free. Do watch out, because just like in free open source software, sometimes you get what you pay for. (;~)

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Some of you recognize this as the last item principle in the list of principles behind the Agile Manifesto. There are whole books written on the subject.

If you want to really, really know all there is to know about retrospectives, you can go and buy the book. My intent here is to provide a simple overview. I hope you find it useful. (If you do, you can let me know.)

Just to make sure we're all on the same page here, this post is about Scrum retrospectives. In the classic book, Agile Project Management with Scrum, Ken Schwaber states very simply "The purpose of the sprint retrospective is to inspect how the Scrum process worked during the last sprint and adjust it to improve the next sprint." Wow, that's pretty simple. Not a lot of guidance here. It's not surprising to me that people get so confused about it. I see questions about retrospectives pop up on the Yahoo! ScrumDevelopment board quite often, and there are whole sessions about retrospectives at the large agile conferences, so don't feel too bad if you're here trying to figure this out.

Retrospectives aren't something that we normally do in traditional software development. Sure, we might have a "post mortem" at the very end of a project, where we talk about all the things that went wrong, and vow to never do them again, and a project manager will take notes and maybe even send them out to everyone, but in reality, they get filed away and forgotten, and we repeat the same mistakes over again on the next project.

Retrospectives don't have to be difficult, but it is important to keep some things in mind. Scrum is simply a framework for developing software in an agile manner, and it provides some fairly easy rules and guidelines that are based on the principles behind the agile movement. Anytime we do something because Scrum says we should, it would help us to keep the corresponding Agile Manifesto principle in mind. The corresponding principle to the Scrum retrospective is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

So, given that statement, let's take a closer look at the individual parts of the principle and then go ahead and get the easy one out of the way: The first part is "At regular intervals...". Since Scrum sprints are normally from one to four weeks, our "regular interval" should be at the end of every sprint, after the sprint review. The retrospective should take place after the sprint review because you will normally have stakeholders, managers, and end users who show up to see what the team has accomplished. These stakeholders will say something about what you are showing them, and you should be paying attention. The feedback you receive should be discussed in your retrospective, whether it is good or bad. If you aren't responding to feedback early and often, you're missing one of the key benefits of agile. Retrospectives are a great place to capture real feedback from the people you are working for.

Since we've discussed when to have the retrospective, the next question is who should hold the retrospective? Well, according to the principle, the team should be the ones doing the reflecting. Sure, managers, stakeholders, etc can reflect on how the team can be more effective, but the team is required to do this. If someone outside the team has input on how to be more effective, I would encourage the team to listen. Many times, managers see the bigger picture, interact with several other teams, and have great ideas or advice. Since we know it is the team's responsibility to reflect, a question that sometimes comes up is "Who is the team?". Unfortunately, the answer varies from team to team. Ideally, your team consists of the regular team members (developers, testers, designers, etc), but also includes the Scrum Master and Product Owner. Yep, the product owner, but only if they really are a member of the team. By "member of the team", I mean if they sit with the team, help the team, eat lunch with the team sometimes. Do they have skin in the game and help the team to accomplish the goals, or do they blame the team when things don't go exactly according to plan? Another way of putting this is: "Are they a pig or a chicken"? I've seen it both ways, but I can promise that I've seen it work far better when the Product Owner is a part of the team.

OK, enough about the product owner. Back to "the team". Who is NOT a part of the team? Managers, stakeholders that happen to be "chickens", and anyone else that isn't working together with the team on the project day to day. Retrospectives are a place where transparency is vital. If people are afraid to speak out or speak up, your retrospective won't be as effective as it could be. This is the place where the team reflects not only on what went right, but what went wrong. Team dynamics, individual weaknesses, team members not doing their best; these are all fair game during a retrospective, and the team should feel free to discuss these without fear of management reprisal. If you don't think that Ted is pulling his weight, you need to be able to say it (in a thoughtful, kind way) without worrying that a manager will take note. You also want to be able to discuss things that didn't go well, or could have been done better, and you may not want stakeholders present that wouldn't understand the day to day details that take place.

Great, we've got the when and the who. Now what does the team reflect on? The team should reflect on how to be more effective. Huh? More effective at what? The primary thing to reflect on is "How to satisfy the customer through early and continuous delivery of valuable software". Come on, that's your job. Do it well, and look for ways to do it better. Instead of just complaining about outsourcing, find ways to be so efficient and valuable that you don't worry about offshoring that much. Sure, you still won't be completely immune to decisions to outsource you, but the better value you provide, the better chance you have of people up the corporate chain thinking that they don't need to replace you, especially as more and more companies get bitten by sending their business know-how out of the country, and find that quality typically suffers.

In addition to looking at how to be more efficient at delivering software, this is a great time for the team to take note of accomplishments, jobs well done, problems solved, and any other good things that happened during the last sprint. If a team member really shows improvement, let them know. If there are things that could make your job better or make the work more fun, bring it up. Sometimes, simple improvements can make a big difference in people's attitudes or enjoyment of their work, and this is good for everyone. Happy programmers have happier end users, because they are willing to go the extra mile and pay attention to the little things that make big differences.

There are many different ways to reflect on how to be more effective. Different teams use different techniques. What works for one team may not work for another. For the team that I'm on, we've settled on this set of questions/statements that we discuss and take notes on during each retrospective:

1. What did we like about this sprint or do well? It's a good idea to get the meeting started in a positive fashion. This is a nice time to pat ourselves on the back and take note accomplishments and work completed.
2. Room for improvement/lessons learned:
3. What caused us pains this sprint?
4. What would we do differently if we started this sprint all over again?
5. What are some things that we want to try or do next sprint?
6. Concerns (long term, short term, etc)
7. Concrete Action Items

The last one is very important. As Bob Schatz once said: "Retrospectives that don't result in change are sterile and frustrating." This is where the rubber meets the road, and a good way to implement the part of the principle that says "....then tunes and adjusts its behavior accordingly". Take a look through the list of things that caused pain, or things that you would like to do differently if you could. Also look closely at the "Things we want to try or do next sprint". This may be as simple as "show our tester how to do make css changes", or try pair programming". If the team really means it, this is their chance. Don't put eleven different things on your concrete action items list. Pick the top two or three, maybe four if they aren't real big. Chances are, some of the smaller easier ones will happen over time without you really thinking about them.

Be sure to post these action items, or somehow make sure they really do happen. ( Scrum Masters, pay attention here.) Whatever you do, make sure the team tunes and adjusts their behavior accordingly.

Here's another retrospective idea that I came across one day. I'd like to give credit for it where it is due, but I can't remember where I saw it. It's very simple. Basically, just draw a big chart on a whiteboard that looks like this:

Liked:	Didn't Like:	Do Next Sprint
-Ted brought donuts	-Lots of bugs found really late -Waited too long to test	-Take turns bringing donuts -Deploy QA drop at end of first week.

The important thing is that the team always tries to be more efficient and better. Don't become complacent, or settle for "good enough". As you may have heard before: "Good enough is the enemy of great".

Just for fun, and as a gauge to see what technologies are currently in demand, I subscribed to the 37 Signals job board a few months ago. It didn't take me long to notice a definite difference on this board that sets it apart from other job lists: Many (certainly not all) of the companies that advertise on 37 Signals have bought into the 37 Signals philosophy, at least to some extent, and understand the importance of recruiting and retaining good people. My guess is that these postings aren't put here by the normal HR person who really doesn't give a rip about whether or not they bring another person in that they have to fill out paperwork for. (I think it was Jeff Foxworthy who joked years ago that the last person you want to send your resume to is someone in HR, because the more people get hired, the more paperwork HR has to do.)

Most large corporate behemoths just need to get "resources" in the door. The normal job posting for a large bureaucratic company goes something like this:

Sr Software Engineer
Job Description Qualifications: Act as a trusted advisor to project managers, development teams, and product management teams. Seven – Ten years experience in the development of .....  Experience in data architecture and development with ....  Experience with all phases of the product development lifecycle including ..... Experience leading application or web development teams and projects.... A portfolio of commercial products and designs that have made a positive impact on key business objectives .....

Duties: Create Architecture designs of..... Investigate new or competitive design and development technologies..... Create and manage a core complement of application architecture documentation and artifacts, including... Develop presentations to communicate concepts.... 

My Fake Large Bureaucratic Company, Inc. and its subsidiaries are Equal Opportunity Employers, blah blah, blah and so on and so forth required here by our policy police....

This basically says "Here's what we are, here's what we need. If you're lucky and you accidentally get called back by someone, you might actually get a job here." That's it. A job. It'll pay the bills. Fun? No. Challenging? Maybe. I'm sure it'll be a challenge to get anything done efficiently. It reminds me of a friend who recently went to work at IBM who told me "I couldn't respond to your question during the day because I don't have internet access."

Smart companies take a different approach at recruiting because the postings are put up by someone who has a problem they want to solve, and they know that the people who regularly solve the hardest problems typically have plenty of options. (I'm not referring to myself here. I'm talking about really, really motivated people who code all day for money, then write code at night and on weekends for fun. I'm talking about this kind of person.)

In an effort to hire very good people (and keep them), smart companies post a job like this:

Are you looking for the opportunity to.... Are you less interested in low-level coding and more excited by the thought of taking over the development of a system requiring ......? If yes, talk to us. We are looking for a ..... to get in on the ground floor of a fast-growing, venture-backed start-up that deals with some of the largest.... 

The Sr. Software Engineer is a key position on a small team and is responsible for continued development of our systems.... In the position, you will join an early-stage company and work directly with the founders to continue to develop ..... The company is located in .....

Our Culture - Tightly-knit team environment - Willingness to roll up our sleeves and get it done - Rely on intelligence instead of large budgets, staff, and infrastructure - Thrive on the excitement and chaos of a fast-based startup...

Your Responsibilities - Take over a vast codebase - Write software for.... Continue to integrate our systems with those of our partners for seamless data flows...  Hire (over time) and manage a team of engineers....

Your Qualifications - BS in Computer Science from top-tier school - 3+ years of whateverlanguage experience.... Expertise in statistical analysis of.... Experience in designing and implementing complex, integrated systems.... Ability to work efficiently with minimal supervision with strong prioritization skills - Excellent verbal and written communication skills - The ability to work well in a team environment.

For more on our culture and what we do, check out our website at www.some.forward.thinking.company.com.

See the difference?
The second posting describes the job, the person they are looking for, and also sells the culture and the company. Heck, it almost makes me want to apply, even though I'm not looking for a job. It sounds fun! plus, I'd be an important part of a team and work directly with the founders. If I had some person or process blocking my way, I can talk to someone that can actually change something, instead of my "suggestion" going into a black hole somewhere with managers wishing the employees would stop making their job harder. I wouldn't be known as employee id #0075496 (my employee id from my first large corporate job).

Well, enough of this. Let's get to the point that I started out to make. As I started checking the job descriptions and noticed the trend, I started keeping a list of perks that companies have been offering lately, in addition to the "normal" benefits like health and dental insurance, 401k, etc. These companies are trying to attract not just "resources", but very smart people who are willing to be a part of the solution. I thought it was interesting, and thought you might think so too. I wonder how many of these perks they offer at Google?

• Daily interaction with smart people who are passionate about creating great software (but manage to keep a sense of humor about it)
• A quarterly bonus based on company revenues
• If you ask yourself just one question today, we here at ****** would humbly suggest the following: "Am I influential?" Because you deserve to be. And here, you can expect to hit the ground running with unlimited potential to be influential. You'll work with intelligent, self-policing team members who will expect the best from you and deliver their best in return.
• A true 40-hour work week
• An energized yet casual working environment
• A flat organization where your opinion is heard
• An annual personal budget and paid time off for professional development (conferences, workshops, etc)
• Weekly knowledge-sharing brown bag sessions
• A great office environment, with views, high-end chairs, and an espresso machine.
• We develop on high-powered Windows, Linux, and Mac workstations with dual monitors
• Agile. We're drinking the Kool-Aid here. We've worked in a waterfall approach before but we're not interested in taking that approach anymore. We believe in failing often to succeed sooner and throwing away code that sucks. Our technical leader taught Agile at Object Mentor so we're not just saying Agile. We mean it.
• Exploration budget - to keep you creative
• Tell us the tools you need: Mac or PC & software
• Fuel: Breakfast, snacks, drinks and unlimited caffeinated beverages
• Massages- yes we have a massage chair
• Young, fast-paced work environment
• Unlimited chocolate
• Nintendo Wii
• 20 vacation days, 10 holidays, 2 personal days 12 sick days
• There's no "work time". You decide when you work. In weekends or from 10am to 6pm, just get the job done. But if you're gonna abuse that, then this is not the job for you.
• Stock Options
• Complimentary $100/month food credit
• Dry cleaning and laundry service onsite
• Employee shuttle to and from various locations
• Onsite full service Gym
• After 6 months on the job, we give our employees a new iphone. This is all our way of saying thanks for a job well done.

This list is a summary, and there are some pretty good ideas here. The underlying theme for many places is the culture. Good people want a good work culture. Without that, you have nothing left to entice people except money, and that's a losing game that won't keep the best people for long.