AdrianCarr.com ^1.0

Several months ago, I wrote a post about hiring and retaining good people, and that post has gotten a bit of traffic. Some of those ideas were from companies that had some money to burn. Well, things were a little better then, as far as the economy was concerned, so here's an updated version that assumes you're on some sort of budget. Obviously, I don't know your budget, and the application will vary from company to company, but a lot of these will fit no matter what your company looks like. This is coming from the perspective of technology workers, but a lot of this applies elsewhere as well.

Imagine you're an IT manager at a company that doesn't have a lot of extra cash. Let's assume you aren't giving away free food all the time, you aren't giving away free iPhones, and you don't have a 410k match either, but you need to hire someone, or make sure you keep the people you have.

What do you do? At this point, you probably can't outright buy the people because you're constrained by money. Well, believe it or not, it's not all about money when it comes to hiring and retaining good people. Actually, in the original post, where I captured different perks that companies were using, most of them were directly related to the culture of the company. Money and benefits are a piece of the pie when people look for jobs (or look for a different job), but two other big factors are the workplace culture and the nature of the work that people do every day. This is a partial list, and I don't have the time to extend it as much as I would like, but here it is.

• Educate developers on the business side of things. We understand technology. Let us help you by teaching us the business. Let us help solve this company's problems, and at a minimum, you'll get better software out of us if we understand your job and the company better.
• Let people work in other areas of the business sometimes. This exposes them to other parts of the company that they may know nothing about.
• Teach employees about the history of the company, and help people understand their part in continuing that history.
• Buy big popcorn makers. This is a really cheap way to give snacks to the employees. You may have to fight your facilities people on this one, because the first time I tried to get one, I was told "it's a fire hazard" or something like that.
• Loosen the vacation and sick time (from Motley Fool) -The Fool's vacation/sick policy is pretty straightforward: take what you need. That's right, as long as you get your work done and consult with your supervisor in advance (if you're going to be sick, we'd like to know in advance, but we understand it doesn't always work that way...unfortunately...), you may take any reasonable amount of time off. With pay, of course. Huh? Unlimited paid time off? What's the catch? Well... nothing, actually. Fools treat themselves, their company and their co-workers with fairness and respect, so you will not abuse such a wonderfully Foolish benefit.
• Monthly peanut butter and jelly sandwich days, with 25 to 30 varieties each of peanut butter and jelly and a dozen breads to choose from; (from Motley Fool)
• Office Rock-Paper-Scissors tourney (from Motley Fool)
• Make your software release process simple, fast, and sane.
• Take a look at everything you do and think from a lean perspective.
• Minimize the time from "concept to cash", or idea to fruition.
• Abolish rules that you don't really need.
• Does your company sell things? Have good, fun employee sales. Give some great deals on some stuff the company doesn't need anymore.
• Allow employees to buy old computers or laptops when they get outdated.
• Allow people to reconfigure the work areas, even if they have to do it on their own time.
• Loosen your technology choice limitations.

I was a full-time Scrum Master for a team for over a year, and I loved it. During that time, I made some notes on things that helped me and our team. Maybe these will help someone else out there.

1. Learn as much as you can, as fast as you can. Subscribe to the Scrum Alliance discussion board, and learn from other people. When you come across a real nugget or gem, keep it. Over time, you will compile a very helpful list. Over time, you will become the "go-to" person for Scrum advice, and a trusted source of information.
2. Get the Product Owner integrated with the team. Despite what some people say, it works better if the PO is part of the team and sits with the team. This way, the feedback loop is shortened tremendously, both from developers and QA with questions, and from the PO to the team.
3. Encourage the team to understand the business needs. The team should know why they are doing this work, and have a sense of urgency about it.
4. Question needless processes and rules.
5. Meetings: Minimize them. Those present make the decisions. If the meeting isn't important enough for you to come, you don't have a say in the outcome.
6. Do the most important things first. Encourage team members to question each other when someone is working on something that is less important.
7. Get into a rhythm early and stick with it- have fixed sprint lengths, recurring reviews. reviews should be like clockwork- same time every two weeks or so. We had our reviews at 9:00 every other Wednesday. After a while, people expected them at this time.
8. Have retrospectives that work and be sure to implement needed changes.
9. Keep the team small. "Small" will vary according to the needs of the project. If in doubt, go with a fewer number of people.
10. Relentlessly expose things that slow you down. Do this in reviews, by posting things where they are very visible, by asking those who can fix them how long this waste will be tolerated.
11. Coach team members. Help them make choices that help the overall agility of the team.
12. Create team culture of simplicity.
13. Be purposeful about cross training. If there is anything the team does that only one person knows how to do, this is a problem, and you should encourage them to train someone else to do it.
14. Empower and encourage team members to resolve blockages on their own.
15. Have others step in as Scrum Master as needed for vacation days. This helps spread the knowledge around.
16. Create team culture of continuous improvement. Like Lexus: The The Relentless Pursuit of Perfection.

I've often thought about what I would like to do if I ever have the opportunity to own or run a company. I don't know if I ever will, but if I do, here are some things that I would like to try:

Business Ideas

Since profitable businesses typically work better than unprofitable businesses, I want my employees to be business-savvy. All of them, including the people who clean the office. To help my employees have a better understanding of business in general, and how they can have a direct impact on making the business successful, I'd send everyone that I could to business conferences, like the Inc. 500 Conference, or the Business of Software conference. This would be expensive, but I think the cost would pay for itself. Additionally, this would be a great recruiting tool for attracting and retaining good people.

I'd also give books to my employees. I would help them build their own personal library of business and technical books that would help them build their careers and my company. The books would be a gift, that they can take home and keep, or leave at the office. I know many of them wouldn't be read, but how many ideas or concepts would need to be implemented to get my money back? My bet is that they would pay for themselves. If there are things that I think we, as a company need to do better, rather than mandating the change, I can influence the people in the company to do those things on their own by giving them books that fit that specific area. For example, if I want better customer service, I would give everyone a copy of I Love You More Than My Dog, which is all about how to treat customers.

Some books would be required reading. For example, every software developer would get a copy of Getting Real, from 37 Signals, and be required to read the book and understand the concepts.

The book giveaways would help build the culture that I want to create, because I could give away books like Maverick, by Ricardo Semler, which is about Semco, commonly referred to as "The World's Most Unusual Workplace".

Culture Ideas

A primary component of my company would be the culture. To steal a phrase from Ford Motor Company: "Culture eats strategy for breakfast". I would work hard to make the company a place that people never want to leave. I'd do my best to make it fun, and a great balance between work and family life. I'd sponsor cookouts, ice cream days in summer, and every once in a while I'd make everyone spontaneously go home early on a Friday. I'd create a sense that everyone has a say in how things are done, because I know that my employees are going to know better than I am how best to do their job. Everyone would know and understand a culture of continuous improvement.

The company's management structure would be as flat as possible, and managers would be regularly reviewed by their employees. These reviews would go on the wall for all to see. Yes, this sounds strange, but I guarantee that managers would do their jobs well.

I'd allow "Workation" time for software developers. This is the concept of giving one week per year to every employee to spend learning a new technology or creating something that may even be unrelated to their job. They could do it on their own, or as a team. It would be just like they are on vacation, where they don't have to answer emails, or sit with their team. I'd require that they be in the office somewhere, and they'd have to give a demo at the end of the week, but that's about all I would require. I'll bet some really good ideas would come out of this, and would often pay for the time spent on it.

I'd make the offices a fun-feeling place, with quiet, comfortable places for people to relax or talk. I'd also do things like this: Near the entrance of our office is a game of group chess. Take a look at the board, make a move, and flip the sign over. What's funny is that the game almost seems to be a metaphor for programming. Often an obvious solution is found by someone, only to be completely missed by whomever follows them, and the game degenerates. Equally often, someone thinks they've found the right solution, only to realize that the other side is not playing in a predictable fashion. Simple solid moves that everyone can understand seem to be the right solution, but such moves are hard to find.- http://fairlygoodpractices.com/toys.htm

The People

To guard the culture, I would be extremely careful about who was hired, and would only hire people who fit the culture that I want to create. There is an old saying that you can teach someone technical skills, but it is very difficult to overcome personality problems. A key ingredient at my company would be humble people. Zappos does this. See http://www.inc.com/magazine/20090501/the-zappos-way-of-managing_pagen_4.html for example. They even have interview questions that help a manager discern if a person is humble.

Why humble people? Because a humble person is willing to learn new things, willing to learn from mistakes, willing to help others, and more willing to listen to others. I've worked with smart prideful people, and let me tell you, it stinks. I don't care how smart you are (or think you are), if you aren't willing to listen to other people's ideas, I don't want you at my company.

I would give each person a yearly budget (with time off) to spend on training and conferences. I want the best, and I want them to spend time to keep being the best. Time to "sharpen the saw", if you will. Out of this, I'd expect some blog posts, a report, or a demo when they get back because knowledge should be shared.

Software Development Perspectives

I'd hire smart people that can get things done. To help them get things done, I'd buy good equipment, and give them the tools they need to get the job done well, and efficiently. I would only use open source software where it made sense to do so. Too much open source software is only "free" if your time is worthless. How "free" is an open source IDE if your $80,000 per year software developer spends two days fighting to make it work?

I would have very few rules, but one guideline would be "Don't invent frameworks, unless you absolutely have to, and if you think you absolutely have to, rethink what you need". Why? Because creating a framework is usually a waste of time, and a huge drain on valuable resources. There is a saying that "you should only write the software that only you can write", meaning your time is limited, so focus on the most important things. There are other people out there that have created frameworks for you.

Every ninth week, I'd let my software teams do skunkworks projects. This would be stuff for the company, but the team would drive it. It might be as simple as fixing some old bugs that have been out there forever, or it could be a cool new thing that no one else has ever thought of to make someone's job easier. If we worked as a service organization within a company, I'd encourage projects that serve the people we are building stuff for. If we sold software as a product or a service, I'd encourage the teams to focus on things that we could sell.

Some key tenets of software development would be:

1. It's easier to extend simplicity than to change complexity. -(A great quote from my friend, Joel Pierce)
2. Do the simplest thing that can possibly work (well). "Just recall that the cheapest, easiest to maintain, easiest to change code is the code you don't write. We need lots more of that." -Joe Little
3. Test early and often.
4. Deploy to production as soon as possible.

I'd have small teams. We would probably use a mix of Scrum and Lean, but we wouldn't have a Scrum Master or a Product Owner on each team. Instead, I would imbed the teams with the people who use their software. The teams would know their customers, how they do their jobs, and how they use the software that the team creates. I'd make the teams small and cross-functional. This would encourage simple solutions and maintainability. The people on the team would have technical skills, people skills, and business skills.

I agree with this quote from Mary Poppendieck:
Seems to me that if we didn’t have a SM or PO, but instead spent the time and effort developing really competent leaders who knew how to do the technical work, focused on continuous improvement, connected the team with their customers, and acted as a mentor and teacher, life would be much better. Seems like we are just creating new leadership roles which are becoming dysfunctional, instead of taking our leaders-in-place and helping them discover the best way to lead. - 02/11/2009, on the Lean-Agile Yahoo Group.

There's so much more than this that I have in mind, but I think this makes the point. I don't know if I'll ever have the chance or not, but it would be different kind of company, and one that would hopefully, get results. Thanks for reading.

Since starting the Knoxville Agile Practitioner's Group, I've received a couple inquiries about how to start a user group, and I've seen others ask this question on different message boards. Over time, I wrote down some things that worked for me, and thought I'd share them here in the hopes that they help someone else.
*Note: This is what seems to have worked for me. You will likely have to do things slightly differently based on your location and situation. You'll probably have better ideas than mine too, and I hope you share them.

Here's what I did:

1. Create a website. This one is kinda obvious, and really is a must-have. You can use something as simple as Blogger, or a fancy custom site. It's a great way to get the word out, and makes your group seem more legitimate.
2. Keep it simple. When I started, I didn't know what it was going to take. Some people suggested starting a committee, others said to start a non-profit. Both of those sounded like a hassle. I decided to do the simplest thing that could possibly work, so I didn't do either one, and found that I didn't need them. Just like life and software, simple is better and takes less effort and energy to maintain. If you have a need to make things more complicated later, you can always do that. As a great product owner friend once said: "It's easier to extend simplicity than to change complexity.
   One reason that you may want to get more organized or start a non-profit is if you want to host a conference, or if you end up needing a bank account because sponsors give you money directly. I would not want group money in an account that was only in my name.
3. Get the word out. Somehow, you have to let people know that you have started the group. In the case of Agile Knoxville, I realized the need for a user group during a certified Scrum Master class that was being taught locally. So, I decided right then to start the group, and passed around a sheet of paper for people to put their email address on if they wanted me to let them know about the first meeting. I emailed them not long after to announce the first meeting, and asked them to pass on the information to anyone else that they thought may be interested. (I think it's a good idea to always ask people to pass the meeting announcement on to others.)
   Another way to get the word out about your group is to answer questions or get involved in discussions on different agile message boards, and when you do, add in the group website in the signature line.
4. Put the info on the user group page for the Agile Alliance. If a member of your group is also a member of the Agile Alliance, the Agile Alliance has a program that will help pay expenses for speakers to come and present at your group. I've never used this program because we don't have any Agile Alliance members.
5. Put the info on the Scrum Alliance user group page. There is info there that explains how to do it. There is also information about how to get support from the Scrum Alliance on that page. I've received several emails from people that found us via the Agile Alliance or Scrum Alliance websites.
6. Register for goodies with O'Reilly, InformIT, Apress, JetBrains, etc. All of these companies have user group programs, and they have been very, very generous with us. I often have books just show up at my door from all three of these companies that I never asked for. I can then give these away (after I check them out of course). We also get great discounts (like 35%) on books, and I can order any book they publish for a group member that wants to do a review. Not long ago, I asked for and received a $60 Oracle book for a group member to review. I didn't even have to pay for shipping.
   JetBrains allows me to give away one of their great software products every meeting to a speaker, and one to an audience member. This is $500 of free software that I can give away every meeting.
7. Start a mailing list and require membership for people to join or post messages. If you require people to sign up, you can often find out where they are from. Take a look at the domain in the email address. If they are from a company that is agile, or may have something to contribute, ask them about it. Check where every person comes from and screen them to see if they are potential speakers. Finding speakers month after month is sometimes hard to do, and quite frankly, what takes the most time.
8. Recruit a couple key people to help. Sometimes, you'll need some help. If you find any good volunteers, take them, and see what their strengths are, and figure out how they can contribute.
9. Figure out where to have the meeting. Don't make assumptions. This was a mistake that I made. When I started our group, I talked to the VP of our group, and he assured me that we could meet in the large meeting room we had at our office. Well, then he talked to the people that run our facilities, and they must have talked to our staff lawyers or something, because after this I kept hearing a lot of "what if's", and the next thing I knew, we couldn't meet there, even though we explained to them that there are user groups meeting all around the world without problem. Fortunately for us, we have great meeting space at EdFinancial. If you have a local computer training facility, that may be a good option.
10. See if anyone is teaching a CSM or CSPO class nearby and ask them to spread the word. A couple times per year, Certified Scrum Trainers come to town and teach a class. If you know they are coming to town, contact them and ask them to let their class attendees know about your group. In exchange, you can let your group members know about their class. You can also ask the trainer to come and speak at your meeting. Our best attended meetings have been when experienced trainers are presenting. You will probably have to be flexible with your meeting dates, but it's worth it if you can work your meeting dates to coincide with a great speaker being in town.
11. If you have a college nearby, you can put up flyers advertising your meetings. I've not done this yet, but have always thought it would be a good idea.
12. This may seem obvious, but you should ask your friends and coworkers to help spread the word.
13. Get to know leaders of other user groups; both local, and the next city or state over. Very often, people will recommend speakers that are willing to come and present. I've had lots of help and advice from the leaders of The East Tennessee .NET User Group, and they also let me know when potential speakers from Microsoft are in town.
14. Get to know people from other local companies, and have them let you know when people are coming in town, or when events are happening. You can often coincide your meeting with these events and get a great speaker.
15. Talk to local recruiters and get a good key recruiter to sponsor your group. Our sponsorship is very simple. Recruitwise, a great local recruiting company, brings pizza and drinks to our meetings, and I have them give an update on any interesting news or positions they are trying to fill. It's a great relationship.

It can be hard work to start and run a user group, but I think it's worth it. You will meet some neat people, learn some new skills, make some great relationships, and help other people in their journey.

I hope this helps. Keep in mind, this is what worked for me so far. One problem that we are currently having is that many members have left our area as jobs have dwindled and they have taken positions elsewhere. As a friend pointed out recently, the more user groups and better technical base we have, the more attractive our area will be for potential employers.

Let me know if you have any questions. adriancarr AT gmail.com

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.

Slide Content

1. Agile: What's in it for me? CodeStock 2009
2. Adrian Carr
     -Software Developer for 10 years
     -Currently work for mid-size company in Knoxville, TN
     -Worked for Fidelity Information Systems in Atlanta
     -Worked for Alltel Information Systems in Atlanta
     -Worked for a large non-profit in Boone, NC
     -Founder and Organizer of Knoxville Agile Practitioner's Group (http://agileknoxville.com)
3. Disclaimer
     - Be skeptical, but open minded.
     - This is how I develop software. Take the parts that make sense to you. Ignore the rest. Ron Jeffries
     - If you currently have a high rate of success on your projects, then this may not be the best thing for you.
4. What Agile is Not Supposed to Be
5. Some Agile Myths
     - No documentation
     - Cowboy coding
     - No up-front design
     - Agile is a silver bullet.
6. What is Agile Software Development?
     -project management process that encourages frequent inspection and adaptation,
     -a leadership philosophy that encourages teamwork, self-organization and accountability,
     -a set of engineering best practices that allow for rapid delivery of high-quality software,
     -a business approach that aligns development with customer needs and company goals http://en.wikipedia.org/wiki/Agile_software_development
7. Agile Practices
     - Scrum- Small, self-organizing, cross-functional teams Defined roles within a team. Defined rules, based on project management. Work in short iterations, or "sprints" Demo progress at the end of every iteration. Re-plan for the next iteration, always doing the highest value things first.
8. Agile Methodologies
     - XP Very disciplined. Onsite customer Pair programming Unit testing Refactoring Frequent delivery Continuous integration Test-Driven Development Simplicity
9. The Agile Manifesto 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.
10. Traditional Projects http://www.total-quality-management-software.com/gantt-chart-examples.asp
11. Traditional Projects: http://www.projectcartoon.com
12. http://www.projectcartoon.com
13. http://www.projectcartoon.com
14. IT has an Image Problem
      - Typically, we're seen as a roadblock. When we do succeed, we're viewed as too slow, too expensive, or delivering poor quality.
15. What's in it for Me?
16. I Own or Run This Business- What's in it for Me?
      - What is the #1 killer of projects? Answer: Time
      - In traditional projects, we often run out of time and something has to go. What is it?
      - Quality, documentation, testing.
      - In agile projects, testing and quality is a part of every iteration. What get cut is features, and that's not necessarily a bad thing.
17. I Own or Run This Business- What's in it for Me?
      - ROI
      - There's a reason why you're paying these expensive people to do this work for you. You want your stuff. You want it as soon as possible. You'd rather not pay more for it than you have to.
      - Or, since you're going to have to pay for it, you at least want to get the most for your money. A team of 8 -10 people costs about a million dollars a year.
18. I Own or Run This Business- What's in it for Me?
      - Traditional Projects and the Cost of Change Feature bloat. You're paying for unused or rarely used features.
      - Idea> Analysis> Development> Testing> Deployment> Return on Investment
    Most of the costs are in the Analysis, Development, and Testing.
      - Reduced time to market. Agile teams will do the most important things first, and deploy them in production as soon as possible.
19. I Own or Run This Business- What's in it for Me?
      - Reduced risk. You get to assess it and decide on it every few weeks. If you want to stop, you can.
      - Changes after deployment: Agile teams can respond more quickly, assuming they have unit tests and quality code.
20. I Own or Run This Business- What's in it for Me?
      - Everything is just fine... http://cargolaw.com/2007nightmare_ital.florida.html
21. I Own or Run This Business- What's in it for Me?
      - Reality always wins in the end, so get there sooner. http://cargolaw.com/2007nightmare_ital.florida.html
22. I Own or Run This Business- What's in it for Me?
      - What if the project is doomed to fail? If you are going to fail, do it fast. http://www.cargolaw.com/2007nightmare_msc.napoli.html
23. I'm a Project Manager- What's in it for Me?
      - Project Manager's job is to create a schedule, monitor progress, control the risks, and keep people informed.
      - This is very difficult to do. Especially when people are afraid to tell the truth.
      - How does a project get to be a year behind schedule? Answer: One day at a time.
24. I'm a Project Manager- What's in it for Me?
      - You can have people get started earlier. Typically, you don't give the green light for developers to actually get started developing anything until we know all the requirements. With Agile, you don't assume that you ever know all the requirements until you are done. You do need to know enough to get started, but you don't need the entire picture in detail. When you don't know enough about a project, you may want to go ahead and get started. Have very short sprints and get feedback early and often.
25. I'm a Project Manager- What's in it for Me?
      - Instead of managing risk with lots of documents and contracts that create an "us vs. them" environment, you manage risk with real, working software, and contracts that encourage collaboration between different parties.
26. Typical Scrum Team Board Transparency is more evident.
27. Multi-Team Project Board Big, Visible Charts
28. I'm a Project Manager- What's in it for Me?
      - The culture of transparency makes it easier for you to provide visibility and a more realistic status up the chain.
      - Unknowns should be known much earlier in the process.
29. I'm a Project Manager- What's in it for Me?
      - Managing Risk: There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. -Donald Rumsfeld
      - When problems pop up early, we have lots of options. When problems pop up at the end of a project, our options are very limited; work more, cut quality, etc.
30. I'm a Tester- What's in it for Me?
      - How is QA viewed today on most traditional projects? Often viewed as a roadblock, or second class citizen. If bugs get into production, who gets the blame? Are you ever told "Don't talk to the developers while they are working. They are too busy, and I don't want you to waste their time." ?
31. I'm a Tester- What's in it for Me?
      - Agile teams elevate the role of testing.
      - Quality becomes essential when teams are repeatedly deploying software.
      - You will be working on a close-knit team.
32. I'm a Tester- What's in it for Me?
      - Inspection to find defects is waste. Inspection to prevent defects is essential.
      - A quality process builds quality into the product. If you routinely find defects during verification, your process is defective.
      - If you have test and fix cycles, you are testing too late. This is churn, and wasteful.
    Move QA people from end of process to beginning and middle of process. Find defects as soon as they are created. http://www.poppendieck.com/
33. I'm a Developer- What's in it for Me?
      - ROI Developers often don't think about ROI. They view this as a business term, and often don't care. Well, here's a revelation: Your salary is calculated as ROI. You, your benefits, your computer, are all calculated as ROI. You are being paid to do something. The people paying you want a return on their investment. The better investment you provide, the better you will be viewed.
      - A better way of working. Support vs. control. Imagine a work situation where your manager says "What can I do to help you?", instead of saying "do this, now do that, and do it this way."
      - Trust vs. micromanagement The team decides the best way to reach the goals put forth in front of them.
34. I'm a Developer- What's in it for Me?
      - You will be working on a close-knit team.
      - Can get more done together than you can separately.
      - Collaboration, support system.
35. I'm a Developer- What's in it for Me?
      - Increased communication.
      - Everyone on the team is working toward the same goals.
      - Laughing.
      - Sense of community.
      - Sense of ownership.
36. I'm a Developer- What's in it for Me?
      - You should gain skills you didn't have before.
      - Less useless documentation.
      - Those obstacles that you tolerate now? They should become more obvious, and some of them will go away if your management is doing their job.
37. I'm a Developer- What's in it for Me?
      - Freedom to pick tasks. No one assigns tasks, and you have ownership over your tasks.
      - Great feeling of accomplishment.
      - Food is often involved.
      - Almost always results in higher morale.
38. From: "The Principles Behind the Agile Manifesto"
      - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
39. Principles behind the Agile Manifesto
      - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
      - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
      - Working software is the primary measure of progress.
40. Principles behind the Agile Manifesto
      - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
      - Business people and developers must work together daily throughout the project.
41. Principles behind the Agile Manifesto
      - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
      - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
42. Principles behind the Agile Manifesto
      - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
43. Principles behind the Agile Manifesto
      - Continuous attention to technical excellence and good design enhances agility.
      - Simplicity--the art of maximizing the amount of work not done--is essential.
44. Principles behind the Agile Manifesto
      - The best architectures, requirements, and designs emerge from self-organizing teams.
      - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
45. How Do I Start?
      - Ideally, get support from the top, and jump in with both feet. Hire a good consultant. Get your people trained. Make sure they understand the principles as well as the practices.
      - Do it "by the book" for a year, and then change parts of it only if it really makes sense.
46. How Do I Start?
    1. Start with Scrum.
       -Fairly easy to implement.
       -Quick wins
       -Improved Morale
    2. Add XP development practices
       -Continuous integration
       -Unit testing
    3. Transition to Lean (After a year of successful Scrum)
       -One piece flow
       -Optimizing the whole
47. How Do I Start If I can't get support from on top?
      - Stealth agile. Don't mention the words "agile", "scrum", or anything else that would make people nervous. The last thing you want is for people to freak out. Talk to end users and stakeholders yourself. Establish a relationship with your customers. Ask people what they intend to do with all that documentation.
48. How Do I Start If I can't get support from on top?
      - Stealth Agile Continued.. Get your team to have short daily meetings. Talk your team into working together for one hour or more every day in a conference room. Invite people to a demo every few weeks. Prove the results and earn respect. Be patient. Change takes time. Don't get frustrated.
49. Either Way..
      - Work towards a culture of continuous improvement. Work to improve your skills, your company, your delivery of software.
      - Reduce complexity whenever possible. No one ever goes to bed thinking "Gosh, I hope my work gets a lot more complicated tomorrow."
      - Try to make it fun. Be a part of the solution.
      - "Don't let your doubts tell you what you can't do. This works against change. If you really can't do that, you can probably do something similar. Figure it out and do it."- Bob Schatz
      - Or, as Brian Prince said not long ago. "You can change your company or you can change your company."
50. Random Thoughts for Managers:
      - Create a culture of trust and transparency.
      - Good leadership will establish and communicate common goals.
      - At the beginning of any project, and when new team members come on board, the vision should be set. They should know why they are doing the work they are doing.
      - Be a coach, not a policeman.
51. More Random Thoughts for Managers
      - The time to negotiate is before you say "yes" to a project. What? Scope, cost, and time are not negotiable? They will be later when the project is failing.
      - Ask your teams what you can do to help them deliver software better, faster, more efficiently, then do it.
      - Be relentless about eliminating waste in the process. Tools, technologies, people that stand in the way, arcane rules, bureaucracy, etc.
      - Do more of what works and less of what doesn't, but get these from your people.
52. Acknowledgments
      - Many of the ideas presented here are from: Bob Schatz of Agile Infusion Jean Tabaka of Rally Software
53. Questions? adriancarr@gmail.com 865-924-6319
    -http://adriancarr.com
    -http://agileknoxville.com