Gamification: Turning regular activities at work into games.
Gamification stands in contrast to what people call serious games.
Serious games are activities or games that are outside of normal work. These games can help you with estimation (Planning Poker), road maps (Prune The Product Tree), and team dynamics (Speedboat). Serious games often incorporate crowdsourcing, sometimes to scale efforts that might otherwise be difficult for teams to do alone, and other times to elicit information that people might otherwise be unable or unwilling to provide.
Jane McGonigal’s book, Reality Is Brokenstarts with the following proposition about gamification:
Since the launch of World of Warcraft, players have clocked more than 50 billion hours of time playing this online game.
People play World of Warcraft because, for whatever reason, they find it rewarding, despite the lack of tangible, real-world benefits of playing it. (Unless, of course, you count the people working in the underground economy of “gold farming” for massively multiplayer online games.)
Therefore, if you could somehow recreate the experience of playing World of Warcraft at work, you’d increase their motivation on the job. In other words, if businesses could capture even a fraction of those 50 billion hours playing World of Warcraft, they’d be very happy with the increased productivity.
Bottom line? Gamification turns daily work life into a game with hopes to reap the benefits that games usually bring to extra-curricular life, to the work environment.
Who knows, maybe we’ll all be doing game-like activities at work in the near future. On application development and delivery teams, we’ll get power-ups when we check in code without issues. We’ll earn merit badges when people give high marks to an application’s user experience. When we double the number of automated tests, we’ll “level up” enough to qualify for membership in the Guild of Puissant Quality Professionals. – Tom Grant
So… does this sound too futuristic? Or is it possible?
[The following is an interview format that I created for a client of mine for interviewing potential ScrumMaster candidates. The interview includes basic Agile questions, Agile experience, and 3 core exercises to see facilitation techniques and ability.]
The outline isn’t perfect, and many questions come up ad hoc through the conversations with the candidate. Some of the questions are hard, but not unreasonable. I would believe that a well versed, seasoned ScrumMaster would intuitively know the answer to most of the questions. I may be wrong, feedback is welcome!
Scrum Master Interview Questions
Experience – General
Start with a standup. Introduction!
Current experience, etc. etc.
What is Agile? What would be your 30 second Agile elevator pitch?
What is the difference between Agile and Scrum? / What are some other Agile methods/frameworks?
What is missing from Scrum? What other developmental practices would you suggest helps with providing deployment value to a software development team?
Why is the daily standup/Scrum valuable for the team? – How do you make an ineffective standup more effective?
Your team is ready to plan (sprint plan) for work on Wednesday, but the requirements (stories) aren’t ready yet. – What type of planning would you do? / How would you lead your team to be ready to start developing on Wednesday?
[Guest Post by Tommy Ball, Agile BA, ScrumMaster and CRM Specialist]
Can SCRUM be applied to CRM?
I find it difficult to work in an Agile way with the typical teams involved in a CRM deployment. However… I have developed a highly effective way of making it work.
One challenge is wasting time treating each little sequential task (e.g. in Salesforce setting up validation rules, roles, field level security) as a separate story, requiring MORE time documenting things in a tool like Pivotal Tracker, then actually performing the tasks themselves. Because there are many sequential tasks with CRM. So many that documenting as individual stories takes an excessive amount of time, thus hindering rather than helping progress. What happens is when you apply true Agile, I’m finding, is that organizations STILL get hung up in too much PROCESS and DOCUMENTATION especially with new Agile teams, which almost all Salesforce CRM teams are. And what does the Manifesto say about a little concept about less documenting, more deliverables, less process, more collaboration, don’t get hung up on tools??? Right??? It’s important to stick to the principles we all live by, but with CRM, allow for flexibility in order to keep things moving effectively.
I’ve been addressing this on-going issue of applying Agile to CRM for years now. Running a Salesforce project is drastically different from a Rails project. And both need its own approach. Alistair Cockburn and people in his realm have many Agile offshoot methodologies specific to software dev, but no one has tackled using Agile for CRM. Ironically, Salesforce themselves us Agile and have a very successful internal adoption model. Continue reading “[Guest Post] – Agile and CRM”
There are times when Agile coaching pays off big time. There is something to be said about consulting and helping a company become “more Agile.” It is something completely different to be part of the transformation and see all the hard work come together.
That is what I enjoy most about my job: Being part of a full Agile transformation and see the on-site full-time employees and executives not only take it seriously, but execute on it and let all the Agile workshops, training, and theory become reality.
It is one of the toughest yet rewarding roles in an Agile environment.
How do you neuter a Product Owner? How do you make a Product Owner unsuccessful? By not empowering and giving them the authority to make critical decisions with your Product. Micro-management has no place here. Command and control has no place here.
If you are a micro-managing command and control executive, stop it. Seriously. Trust your Product Owners, whom you’ve hired, to make the best decisions they can on your product. Trust them to course correct when they are wrong, but trust them and empower them to do their job.
During one of my client engagements I literally told the CEO of the company to have a transfer-of-power ceremony of his responsibilities to the Product Owners. Have a coronation, a formal event, in front of the entire company to show that he has officially transfered power.
Need I beat this drum any more?
Make it Official:
Empower, equip, enable your Product Owners to do the job in which you’ve hired them for. Trust them and encourage them, and they’ll produce the best darn product imaginable.
[Guest Post: Paul Boos serves as the software maintenance lead for the Environmental Protection Agency’s Office of Pesticide Programs (OPP). His team currently uses Kanban and Scrum to maintain the OPP legacy code base. Prior to that he implemented Scrum as the Branch Chief for the National Development Branch within USDA/Rural Development. Follow him on twitter: @paul_boos]
I am quite fortunate to have a friend like Siraj Sirrajuddin; he and I founded the Agile Influencers of DC (AID) a couple of months after the 2010 US Agile Coach Camp. For simple explanation, AID is an Agile experience sharing group that utilizes an open space like discussion forum around a central theme. But he also invited me to join him at the local DC Society for Organizational Learning. This has more to do with Systems Thinking and organizational culture than your typical Agile discussion. At my first meeting, Eva Schiffer ran us through an exercise of of Net-Mapping (see http://netmap.wordpress.com/about/).
A Summary of the Net-Map Technique
To briefly explain, a Net-Map allows you to diagram (and thus understand) the relationships, formal and informal, between people. You pick a subject, goal, or question and use it as the context for mapping the relationships between people. During this exercise or game, you also identify where in these folks reside in terms of the following:
Categories that matter in the context (e.g. management, technical, etc.)
Political clout (again in terms of the particular context at hand)
And where they reside as far as being in your camp or not.
Conceptually this exercise is not difficult, but it is a bit time consuming as you are exploring in detail the relationships and power structures in the network of people that impact the particular issue that you are using as the context.
So why am I telling you this dear Agilistas? Because often we have to understand who we need to influence to ensure an Agile transition goes successfully or perhaps we need to take the next step in improvement and it is beyond the control of the team at hand and thus we need to assess and gain approval from others.
This powerful technique can save you a lot of time and agony… And believe it or not, understanding this network can not only identify who to focus on, but also how to access them. In my first use of this exercise with a colleague, we identified 8 steps to take and a serious issue if we didn’t take those steps. Without this, we could have stepped onto a political mine. I’m now going to tell you what we did as a case study of this technique and hopefully this will help you understand why it should be in your tool box.
“The real company values, as opposed to the nice-sounding values, are shown by who gets rewarded, promoted, or let go. Real company values are the behaviors and skills that we particularly value in fellow employees.”
The 7 Aspects of Netflix Culture:
Values are what we value
Freedom and Responsibility
Context, not Control
Highly Aligned, Loosely Coupled
Pay Top of Market
Promotions and Development
Read more in the deck. Very inspiring for a Friday!
“Delta and Northwest announced their merger in April 2008. They immediately began planning for what turned out to be an 18-month sprint to integrate 1,200 systems across the two airlines — everything from customer loyalty programs to aircraft operations, all without interrupting service. Managers built this master guide to break down when these systems would need to start working together. Each note represents a project that could involve thousands of tasks.”
18-Month Sprint – Really? Is that Agile? – I know that Delta/Northwest and the people working on this project wanted this project to be “Agile.” I’m seeing now… that it may be a different flavor of Agile…
Managers built this – Need I say more?
“Ms. Wise, who has a doctorate in applied mathematics, devised a low-tech solution: she set up a timeline of the steps that had to be performed by pinning colored Post-it notes on the wall of a conference room.”
So… maybe it wasn’t an Agilist who built it. Would love to have anyone who knows how this is going comment. What a giant undertaking!!!
With all the hubbub going on about the new PMI Agile certification, I’ve been doing some searches around the interwebs for information about testing, exam prep, and the like. Well wouldn’t you know it, the Project Management Association of Canada has a player in the game: The Certified Agile Project Manager designation, and it’s been out for a while now.
I wonder how much value it holds here in the USA…
The Project Management Association of Canada offers an entry-level certification in agile project management called the “Certified Agile Project Manager.” Those who are awarded this certificate have the right to use the postnomial “Cert.APM” for as long as their certification remains current.
This unique specialty project management certification is aimed at primarily IT project managers who are looking for additional credentials beyond basic project management credentials such as the PMP designation from PMI. Having specialty certifications such as PMAC’s Cert.APM offers project managers a number of benefits:
Differentiation – Basic project management certification has spread throughout the world, with over 336,000 project managers (as of June 2009) having PMI’s PMP designation alone. Having one’s PMP used to be a differentiator in the marketplace; now, they are so common that project managers need something more to stand out.
Development – A project management specialty certification from PMAC is evidence that a project manager is actively engaged in skills growth and career development — a sign of a true professional.
Advanced Skills – Having PMAC’s Certified Agile Project Manager shows that a candidate has taken specialty training and has passed a rigorous examination on agile project management theory and techniques.
Is there any doubt out there in the business world that meetings are often terrible and useless? Some would go as far as to say that we need to stop the madness and get rid of meetings, all meetings, period.
Tobias Mayer, a friend of Agile Scout, recently posted about the fact that we need to have conversations, not necessarily meetings:
“Meeting culture has penetrated Scrum, as it must. Something so heavy and oppressive, so entrenched in our way of being will crush anything that tries to challenge its power…Let’s stop talking about meetings, and let’s stop having meetings. Nothing good ever came out of a business meeting. People in collaborative dialog though, now that’s exciting — that’s meaningful.”
It may just be time for you and your organization to look into the “value” of the meetings you are having. Whether it is the daily standup, management meetings, Scrum of Scrums, or any other meetings, it may be time to ax some of them.
“I am happy to report that the meeting in question has been cancelled indefinitely. In one year alone, the cost savings is $214,848…Though the cancellation was months in the making, I commend those who finally made the difficult (but necessary) choice. It’s easy to complain about things but accept the status quo. It’s hard to ask why and then act on it appropriately.”
I believe that [some] meetings are very important to have. It’s just the nature of the beast. Regardless, I would take serious look at the real value of meetings. Maybe having a 15-minute time-boxed conversation is more valuable…
People love the iPad. I certainly do. Wasn’t it time that a robust iPad app came out that supports Scrum in a beautiful UI and easy-to-use interface? Well, let not your hearts be troubled. The time has come.
We here at Agile Scout were lucky enough to get our hands on it first. Lucky us right? Yep, we popped in the redemption code and downloaded that sucker. Truth be told, it was kind of exciting to be an early adopter!
Agile Project Manager (Scrum Sprint Manager) uses all the advantages of Scrum – flexibility and adaptiveness to changing project requirements. Agile Project Manager allows you to plan and track the progress of your development cycle. You can quickly create a detailed plan of the sprint, manage sprint tasks, and view sprint progress in a burn down chart.
What you get at the start is the planning page. What we liked best were the color options, the sprint duration and the planning poker aspect of setting time allocation to tasks or stories:
A quick look see below shows the Sprint page after all is said and done:
Don’t forget your burn down chart:
Simple enough? Options on this baby are limited as of now, but we’ve been told by Dar-Soft that they have big plans for later releases as well as more Pro features.
What’s New In Version 1.5.0
– multiple projects support
– minor bug fix
So what are you waiting for? For $9.99 could this be used for your personal Scrum management?
“The government should be wary of agile development, the much-lauded IT development method, for fear of it resulting in a “never-ending change programme.” – Speaker at the Parliament UK
The Committee of Good Governance: The Effective Use of IT, talked at length about Agile this past month and Janet Grossman, chairwoman of the public sector council and director of strategy and execution at CSC, explained that the “constant change seen during agile development programmes means projects are never finished.”
Agile development was being discussed as an alternative to the widely criticised mammoth government IT deals of the past decade. These Goliath IT deals were pilloried as much for their static inability to respond to needs as for their high costs and tendency to overrun.
So are technology vendors and providers a cartel?
Martin Rice, chief executive of Agile software development at service provider Erudine, who was also speaking at the committee, said some very successful private companies use constant change programmes, citing Facebook an example.
Rice added that although he realised “cartel” was a dangerous word, he believed that the current situation was close to that.
“These suppliers talk to each other and know that if they don’t get one deal, another will come up,” he said.
In the end, it sounds like there needs to be better oversight and program managers who can monitor IT programs in the government. Education would be one of the first things I would think about: Educating program managers on what Agile really is and create better oversight of Agile contracts.
Sounds to me like another opportunity right there… A vendor to provide Agile project oversight for the government.
So… just a day ago I got back from the RallyON 2011 conference out in Boulder, CO. If I were to sum up my experiences in one sentence it would be: “An awesome-sauce of a time.” – Need help translating?
I believe this was probably one of the best Agile conferences I’ve been to ever. Ryan Martens (@rallyon) and his incredible team put together one of the most interactive and fun conferences that simply gave back to the community of practice what is desperately needed: An opportunity to talk about what they wanted to talk about.
Would you pay to go to a conference, hotels, rental car fees, etc and find out that Day 2 of the conference was… open to whatever people wanted to talk about with no agenda??? Well, that’s exactly what happened, and it worked. The Open Space during day 2 was fantastic. There was so much information and learning going on you could almost cut it with a knife.
So instead of just ranting about how #epic it was, I’m going to just put together some bullet points of highlights that were just dandy:
Getting to hear Ryan Martens speak about “living the dream.” – You had to be there!
Getting to see how passionate the Rally Software people are about their work in the Agile space.
Day 1 – Tons of great speakers talking about everything from Kanban to building great Agile teams – [[Get all the notes of Day 1 here]]***
Beautiful downtown Boulder – I think the happiest people in the world all live in Boulder, seriously.
A beautiful hotel – St. Juliens – Highly recommend going there.
A social experiment with a kick-butt crew from StackExchange (@aalear and @mpmobile) – Bringing community building to a conference worked! Taking questions from the conference and crowd-sourcing online communities to answer them. #winning
Networking with some of the most passionate and helpful Agile coaches around!
Day 2 – Open Space – What more can I say? This was really neat! [[Get all the notes of Day 2 here]]***
My open space talk on Agile and Social Media
Continual Agile-conversation, from the conference to talking over good Boulder, CO local food joints.
Again, and I cannot stress this enough for me: Meeting some of the most passionate, helpful, and happy people in the Agile community. Thumbs up!
All in all the conference was top notch. The only downside was that I got stuck in Denver because of a sudden blizzard. :)~
Thanks again Ryan Marten and your Rally crew, you guys did an amazing job. I’m already looking forward to the next one!
This is Part 2/2 of Building Software Like Ford and Toyota – See Part 1 [HERE]
When you think of Ford, what comes to mind? I immediately think of the F-150. Just because it’s probably the best darn pickup truck on the road today. But other than that, do you think about their manufacturing processes? Do you wonder how they build such great cars?
Let’s take a walk through the past through the eyes of a contemporary of Ford’s, Herbert Casson a journalist at the time, and consider what the founder of Ford thought about car manufacturing, or rather, capitalism and treating your employees with respect. [Quotes taken from the book: Fifty Key Figures in Management (Routledge Key Guides)]
On Capitalism and Getting Rich:
Judging by results, Henry Ford is the most successful manufacturer in the world. He pays the highest wages. He makes the highest profits. He sells the cheapest goods…
On Scoffing at Ford:
We may scoff at him if we like—if we are foolish enough; but it seems to me that he is the one who has the joke on the rest of us.
Henry Ford knows how. He has solved his business problems. He has shown us the one right way to handle men and produce goods and make profits without making enemies.
Ford and His Employees:
The fact is, that Henry Ford seems to regard himself as a LABOR LEADER rather than an employer.
He gives his men MORE than they ask.
He gives them better working conditions than they had ever thought of.
He watches over them and protects them.
He has made his men the best-paid and most contented workers the world has ever seen.
So how do we build great software like Ford build good cars? It seems to me that taking a prioritized interest in your PEOPLE is the best place to start. Care for your people, value their work and input, and maybe… just maybe… it won’t matter what processes you use.
Toyota pumps products rapidly through its pipeline thanks to a development process unencumbered by wheel spinning and administrative hurdles. At Toyota product development isn’t so much about developing products as it is about developing knowledge about the product. Do this right and quality products emerge naturally.
“A lot of companies put in numerous administrative tasks which supposedly get you quality, but they don’t have a process which generates quality from the start… It’s not uncommon to see Six Sigma procedures embedded in a huge product-development process. Product development just doesn’t work that way. At Toyota, quality is simply ingrained in the way they think and the way they work.” – Michael N. Kennedy, an authority on the redesign of organizational processes
Developing the manufacturing process plans at the same time you do the design often results in a lot of expensive tooling that just gets thrown away,” Michael explains. That’s because the design isn’t stable yet. Instead, you need manufacturing and engineering jointly deciding on trade-offs in the early stages. It is only once you’ve finished the resulting sets of trade-off curves that it is OK to do process planning and detailed design simultaneously.
The set-based philosophy includes producing redundant systems as backups. Durward Sobek from Montana State University says Toyota tends to stay as flexible as possible until relatively late in the development stage.
“Test first, then design.” – Michael Kennedy
How do they manage documentation of workload? They use what is called an A3 – A lightweight tool (size of A3 paper) to document what simply needs to be done. An A3 template has the outline:
Background of issue
Root Cause Analysis
Bottom line to develop software like Toyota?
Lay off the heavy administrative tasks and processes. They are waste.
Have your design and development work together to sift through priorities early.
Use lightweight documentation methods. Prioritize!
With books like this (by a rockstar in his own right – Andy has the #1 selling PMP Exam book out there), and sites like [agileexams.com] popping up, it seems that the race is on to be first to market with:
Test Preparation Materials
Consulting and Course Training
Agile-specific PDU training
So what? Sharks smelling blood? Opportunists on the horizon? Or just good old capitalism? What’s your thoughts?
By the way. I’d love for anyone to comment on this and add any sites they’ve found out there on the interwebs that are catering to the new PMI Agile Certification.
The Project Management Institute is a big organization with many members, mostly with a “PMP” designation behind their name. Now that the PMI Agile certification is out and there are plenty of people with eyes on the new market opportunities, it was just a matter of time till courses were offered for it.
“Bangalore, India, 02 May 2011 RippleRock, announced today the creation and scheduled delivery of the first training course dedicated to the Agile Certification Program offered by the Project Management Institute (PMI). The course will take place June 3-5 in New Delhi, India in cooperation with the PMI North India Chapter, and will be delivered by Jesse Fewell, Managing Director, RippleRock India.”
Bam. Let the Agile PMI Certification market open up and may the best company win!
A growing Agile methodology is the use of kanban, a process-framework that we borrowed from Japan and Toyota. It’s a simple system coming from the automotive industry. What is interesting to read is that it isn’t perfect. Duh. So much hype and chatter is going on in the Agile community about kanban that if you spent any small amount of time in the Agile twitterverse you’ll most likely come upon more and more people praising the awesome-sauce benefits from kanban. But like Nokia failing the “Nokia Test,” it seems that Toyota might be failing the kanban test:
“Toyota adopted the “kanban” method to promote efficiency and reduce inventory. Under the method, Toyota procures the same parts from several companies, which increases competition among them and reduces the risks of relying on only a few makers…After the magnitude-9.0 quake and tsunami, which swept away one of Iwaki’s four factories in Yamamoto, Saito made a frantic effort to continue supplying parts to clients and maintaining the fragile supply structure that is so crucial in auto manufacturing.” – Asahi News
What has essentially happened is that the kanban system for Toyota has put them in a position of having just-in-time inventory, or rather, very little inventory. They just call on their manufacturing partners to send parts just as they need it.
“Takahiro Tomino, associate professor of production management at Meiji University, said the important thing in this supply system is to quickly recover production after disasters… If companies take measures, such as increasing inventory to prepare for once-in-a-century disasters, they will have to do so endlessly,” he said. “Using the March 11 earthquake as a lesson, they should grasp the entire picture of their procurement networks.“
In software development, we’ve all run into software disasters. Taking into account the whole picture of things for your development flow of work will help you when big issues happen. Don’t let a lack of inventory (stories/work) become a bottleneck for your development. Keep the flow going!
The real question is… would creating a big inventory have saved the day? Waste? What would that look like in software development?
[This article is a guest post by Rajesh Raheja, who is a senior director of development in the Oracle Fusion Middleware SOA group. He is a Certified ScrumMaster and a Stanford Certified Project Manager. You can visit his blog or connect on Twitter @RahejaRajesh.Note: The views expressed on this blog are his personal views and do not necessarily reflect the views of his employer.]
A few months back I wrote about the challenges facing agile adoption in the enterprise. It stressed on the three areas: complex interdependencies across projects, effective utilization of specialized, shared resources across projects, and finally, the “sprint overhead” for complex, architectural tasks.
In this post, I would like to outline a few tips to overcome some of these challenges.
1. Get management buy-in. Program Managers should be aware of the agile approach, usage and expectations. If they are not on board, any additional work to convert reporting from agile to waterfall style adds no value.
2. Plan for entire releases, not just one sprint. Use story points to estimate and extrapolate velocity from one sprint to future sprints. A lot of project planning is based on the project manager and team’s experience in estimating work; and this does not reduce with agile planning. Note that the future sprints don’t need to be fully nailed down at the start itself (that would defeat the agile purpose), hence the use of extrapolation. Some agile tools support this concept by allowing the placement of backlog items on specific releases.
3. Plan sprints with specialized/shared resources in mind. For example, plan on effective usage of an architect or a performance expert’s time. Don’t expect these resources to be part of your sprint / daily stand ups.
4. Complex inter-dependencies are a reality – deal with it! Identify dependencies across project modules/components upfront during release planning. In some cases, we called this a special sprint called “Sprint Zero.” Use this sprint to also get commitments from dependent teams so that you can use this to plan future sprints. Use this sprint to also design the overall architectural requirements, so that these are not limited by the “sprint overhead.” Continue reading “10 Tips for Agile Adoption in the Enterprise”
Seriously. When I came across this job posting by SEOmoz I was astounded. Not just astounded at the perks of the job, but the transparent and honesty behind it! This job posting is straight up Agile.
The best job description ever:
Transparency – Showing us why they are hiring and showing the $ numbers
Honesty – They want top talent, and are willing to pay for it. You can even get $12,000 for yourself if you ‘recommend’ yourself!
Rewarding – The job is rewarding. The outcomes are rewarding. The work is rewarding.
Why are these things “Agile?”
Because these are some of the core foundational tenants of the Agile Manifesto, implicit through the ideology. Agile brings transparency, accountability, and honesty to the work that you do as a software developer. People who work in an Agile environment are rewarded with a great place to work, building good software quickly (with quality) and have monthly (or more) wins in terms of successful builds and deployments to production. Agile environments should be fun, they should be fast-paced and exciting. Am I dreaming here?
Things to think about for your next employer (from SEOmoz):
Will I be working on fun, interesting problems that will challenge me professionally and grow my skills?
Will I learn from my co-workers and influence them positively?
Does the company compensate generously and appropriately?
Does my work make a recognizable impact on the company and the world?
Am I contributing to a mission I believe in and a company whose core values I respect?
We owe it to our customers and our mission to build amazing software and that means recruiting remarkable engineers. It’s great to be a profitable startup, but money sitting in the bank won’t do us, or our community any good. We want to put these dollars to work and build something revolutionary – we’re aiming to be the future of organic web/inbound marketing software.
Uh, heck yah! Sign me up (if I wasn’t loving what I do already)!
Communication, transparency, and collaboration are huge for successful teams. The better a team communicates, the better they can work through issues, and move towards deployment of products. Simply put, communication should be easy. If your environment isn’t communication-friendly, that may be the first issue you need to look into.
Sometimes we can’t change our environment. Sometimes, our tech-lead is out in China. What communication platform will you be using?
[Enter]: Sazneo – Smarter Group Communication that looks pretty while doing it
When people often think about inter-office communication, a couple of big players come to mind: Yammer, Campfire, Yahoo, and even some old school clients like AIM. While these are great tools, sometimes you may just need a little more oomph for your team.
A beautiful dashboard to start. Channels to go to and 1-on-1 chat makes Sazneo cover all your bases immediately.
“Slayer is an American thrash metal band formed in Huntington Park, California, in 1981 by guitarists Jeff Hanneman and Kerry King.Slayer rose to fame with their 1986 release, Reign in Blood,and is credited as one of the “Big Four” thrash metal acts, along with Metallica, Megadeth and Anthrax.” – Wikipedia