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.