Scrum & Gaming Addiction: How Scrum is like online gaming in creating engagement (and even addiction) in your organization

By Pete Behrens

There are few people in our Scrum Community who know personally the power of video games to engage people, and even create addictions to them. There are even some who have applied Scrum to creating those addictive online video games.

This article is not about applying Scrum to gaming applications; rather, it is about the similarities Scrum has to the gaming world in what makes them so addicting. Video gaming is one of the largest growing markets in the world at $50B this year and is on target to be three times the music industry by 2014. This year alone, there was $8B spent on virtual goods in online gaming systems - a true market indeed.

We can learn a tremendous amount from the viral and exponential growth of the video gaming industry. What makes these video games so interesting, engaging and addicting; and what can we learn about them in making our organizations more interesting, engaging, and even addicting?

Continue reading this article.

An Example ScrumMaster's Checklist

By Michael James

An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn't previously consider possible, within a transformed organization -- consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.

If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's engineering practices, and the organization outside your team. While there's no single prescription, I've outlined some things I've seen ScrumMasters overlook.

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Why Your Boss's Boss Should Also Go Agile

By Christine Crandell

Incremental software development methodologies can be traced all the way back to the 1950s, but it wasn’t until 2001 that “The Agile Manifesto” created a comprehensive and landmark account of agile development and why it’s a better, lighter approach to creating software faster.

Ever since then, developers have been using agile methodologies to improve the speed and flexibility of software development through operational improvements, but most other groups within the same company have not adopted a similar philosophy.

Conceptually we’ve bottled up agile as being for software developers, as if speed, flexibility, and complexity weren’t also issues held within every other departments of fast-paced software companies. When software developers are using agile methodologies, but nobody else is, developers become like the clique group of school kids who share a foreign language nobody else understands.

This has caused us to limit the potential for agile frameworks, because they're only implemented operationally, but not strategically. It’s like a wooden boat full of rowers. They might have seamless coordination and full visibility into the work of their colleagues, but they can’t see the captain’s orders up on deck.

Continue reading this article.

Getting Dirty with Scrum

By Pat Guariglia

I have been the Scrum Master for this one team for several years. The other day I arrived a few minutes early to the room we use for our daily Scrum and sat down to gather my thoughts before the meeting. I was in the room by myself when I noticed all of the scuffing and marks on the walls.  When we started using this room for our daily Scrum meetings, it was freshly painted and hardly used. Two years later, I am looking at the walls of a well-used room, a room that hosts our daily stand-up meetings… a room that gets dirty.

Seeing the dirt on the walls reminded me of how tactile the whole Scrum process really is. In Scrum, you cannot be afraid to get dirty. You work with your hands, body and mind. When Scrum is done well, the team becomes a well-oiled machine that takes on a personality of its own. The seasoned Scrum team reacts organically to change and knows how to process it.

Good Scrum involves taking yourself out of the virtual world and into the real world. Unlike other software methodologies (waterfall), Scrum is the framework that thrives on continuous hands-on experiences, plus tactile and verbal feedback. It works best when people are engaged and physically involved. Collocation, physical task boards, daily Scrum meetings, and customer collaboration all require the team to be there physically.

Continue reading this article.

Negotiating Scrum Through a Waterfall: How One CSP Navigates the Difficult Waters of Implementing Scrum

By Phil Southward

Negotiating a Scrum team through the often laborious processes required in a waterfall-based organisation without getting stuck between departmental snags or ensnared in the inexorable documentation eddies along the way is an arduous and, if I may be excused the pun, agile undertaking. Sitting out the umpteenth interdepartmental project sign-off meeting, a Scrum practitioner could be forgiven for thinking that the waterfall manifesto, if there was such a thing, would value:

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

In this clash of cultures, conflicts inevitably arise, yet if my experience in a couple of large (over 4,000 employees) waterfall-based companies is anything to go by, the two can be made to fit together. Somehow.

First up. Work around the keepers of the waterfall manifesto by negotiating a change to the contents of the waterfall deliverables to make them more Scrum-like. Second. Alter the Scrum artefacts and definitions to fit with the waterfall world negotiated above. Finally, as a last resort when nothing else is possible, create all the required waterfall process documentation and deliverables, while running projects internally using Scrum. Successfully negotiating the waterfall will involve some combination of all three.

Continue reading this article.

Have an Initial Conversation to Start an Agile Project: A CSP and CSM share how teams at Baker Hughes choose the solution delivery methodology that best suits the project.

By Rahul Sawhney and Prashant Patel

The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.

The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.

The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.

Continue reading this article.

The Scrum Team: A Puzzle of People: How one CSP builds teams by inspecting and adapting

By Knut Kvarme

By definition a team comprises a group of people linked in a common purpose.

It is my experience when I get involved in discussions regarding a new project, it soon becomes a conversation about the team and who you want to group together in order to deliver within the scope defined in the project assignment.

After several years with the cross-functional team mantra at mind, I no longer think about my new team in terms of who (people). I rather think of a range of skills that I need in my team. After staffing my team I usally find that not all the skills on my list have been covered. And that’s perfectly fine!
Getting the team started and having an inspect and adapt approach in regards to the team coalition is my preferred approach. Sometimes the team steps up and gains the required skills. In those cases no further staffing is necessary.

Other times my initial list of required skills might have been wrong, and we complete the team with adding people with other skills that I thought was needed. The big advantage of this inspect and adapt staffing approach is that the gained knowledge about the tasks in hand and the observation and understanding of the team, provides the answers on how to complete the staffing of the scrum team.
So, we have a complete team with the required skills. What now?

Continue reading this article.