AdrianCarr.com^1.0

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

Aaaahh, yes. 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. 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.

I went through this list, and thought about how many of these items we have where I work. OK, not many, but we have most of the ones that matter. -We're pretty agile, have smart people, great management, a 40 hour work week (most of the time), dual monitors, flexible schedules, casual environment, and awesome people. Did I mention the people? I don't believe you'd find better people anywhere. We really have a lot to be grateful for.

First, I don't think I am smarter than you are. I admit, I do have some pretty strong opinions sometimes, and may come across as thinking that I am smarter than you are, but I really don't think I am. I may not agree with you, and I may think that some belief you hold to, or thing you do is stupid, but that doesn't make me smarter than you. I don't expect everyone to agree with me all the time, and I'm willing to at least consider your position.

I'm sure there are lots of things that you could teach me. I may not even agree with you after you try to teach me, but I will have learned in the process, and chances are that you probably know waaaay more about something than I do. I encourage you to write these things down, even if you don't think anyone cares about them. You would be amazed what people find interesting. If you're passionate about it, and it shows, people will find it even more interesting than they would otherwise.

I don't speak for my employer. In fact, if you are my employer, you might want to go and read somewhere else, since there is much better content out there than this website. It will probably be better for both of us.
Actually, I'm kidding. One of the things I like best about my job is that I work with very smart people. In fact, I think they are probably all smarter than I am. We don't always agree, and we are allowed to disagree and voice our opinions at work. We have very passionate debates at work about different technologies, tools, policies, and solutions, and sometimes just agree to disagree and that's ok. If we all agreed all the time, there would be a sure sign that something is wrong.

Today, I received notice from the Scrum Alliance that my application for Certified Scrum Practitioner (CSP) was approved. I've been a Scrum Master since April 2007, and became Certified in early 2008. According to the Scrum Alliance training plan, the next step after that is to become a CSP, and I am glad to say that I am now a Certified Scrum Practitioner.

What does this really mean? Probably not a whole lot right now, but it does mean that someone from the Scrum Alliance has reviewed my application and said "Yeah, he actually does know what he is talking about when he says he is practicing Scrum." The application consists of a series of questions or statements where you have to describe in detail a project where you have been actively involved in Scrum. You have to demonstrate that you not only understand Scrum, but you know how to put it into practice. You have to discuss the principles and processes of Scrum, and also some real-world intangibles that you couldn't learn simply by reading Agile Project Management with Scrum , or even learn in a Certified Scrum Master course.

I think this last point is important. I see some value in the Certified Scrum Master certification because it at least assures that a CSM has undergone the basic Scrum training. It sets the bar at a certain level, where a person should at least know the terminology and general guidelines that make up the Scrum process and be able to talk intelligently about it. However, during my CSM class, our trainer described the usual attributes of a good Scrum Master. A guy from another company turned to me and said "I have no idea why I am here. I don't fit any of the criteria, and I would never be a Scrum Master." Well, not long after that, I got to wondering why they sent some people to the CSM class. Was it because they wanted to offer training benefits to their employees, and this class allowed them to provide this benefit while saving a lot of money? It cost them a lot less because the class was held locally, which is a lot cheaper than sending someone to a conference out of town. No travel expenses, no airfare, hotel, meals, and the CSM class at around $1000 is a lot less expensive than many conferences. I don't know if this is really the case or not. I hope not, because then it's not about actual training, it's about saving money. The CSP application is different, in that it requires a person to describe in detail how real-world projects have been implemented with Scrum.

The last question asks you to describe how you have advanced the use of Scrum in your organization and the community. This one was fairly simple, since I started the Knoxville Agile Practitioner's Group.

I'm excited about achieving this certification, because if I ever want to become a Certified Scrum Coach or Certified Scrum Trainer, the Scrum Alliance requires that I be a CSP for at least one year. At this point, I have no idea if I will ever actually become a Certified Scrum Coach or Trainer, but if I do, I'm at least heading in the direction of making that option a reality. It would sure be fun to help other people experience the freedom and results that agile software development can bring.