Replacing Waterfall with Agile

“We cannot change anything until we accept it. Condemnation does not liberate, it oppresses.” - Carl Gustav Jung

The Waterfall model is rigid and doesn't deal well with new parameters, especially when they're introduced late in the game. It also doesn't empower our team members to self organize. Run a few projects with it and you'll certainly agree. Agile methodologies, on the other hand, were designed to iterate and adapt to change efficiently. They also obliterate micromanagement.

I've been asked about best practices in transitioning to agile project management a few times in the last two weeks so I figured I'd drop a few ideas out for general consumption. Agile methodology utilizes the most powerful tools that I've come across for getting my projects out the door on time and underbudget. And, it's easy to implement once you get the basics down. Of course, you must be open minded for this new system because it is drastically different from the sequential model. I started off with that Jung quote because it's important to be positive while trying something new and it's equally important to, at least while testing, set aside what you currently hold to be self evident in order to have the best chance for success. In this article, I'm going to give you some pointers on how to get the agile ball rolling in your company. I'm going to assume that you're currently using the Waterfall model and I want you to remember that...

“There is nothing wrong with change, if it is in the right direction.” - Winston Churchill

First off, you should have a cursory knowledge of agile before you read this. I'm going to go out on a limb and assume that you're already familiar. If not, no problem! Try this post to get the basics.

A company that has a long history of sequential development will, most likely, have a hard time transitioning away from the rigors of upfront documentation and copious Gantt chart updating. Companies steeped in these traditions need to be gracefully guided into agile production. Anything less than a slow merge will end in failure or, worse yet, misgivings about agile itself.

You can always tell when a team has had agile forced down their throats without an experienced coach to see them through. These folks don't want to touch anything new with a ten foot pole but can you blame them? It's not rewarding to modify your workflow only to have to go back to what you were doing previously. This is wasted time, annoying, and can be demoralizing.

There are many reasons that an agile transition may not work. Mike Cohn is one of the best agile coaches in the business and has a great insight to share regarding a major stumbling block that many new agile teams will face.

"I've personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an "Agile Office" to which new Scrum teams could turn for advice. The company's failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating the supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started."- Mike Cohn, Succeeding with Agile

We all need to be on board to make a new style of management work. This includes our stakeholders. My first suggestion to those that want to attempt agile is to get a coach and have that person start by educating your stakeholders on how they can best play their part. Change comes fastest when it starts at the top.

A coach may not be financially viable for your situation. There are plenty of fantastic books out there. If you go the book route, then read it cover to cover twice and feverishly take notes. Once you feel that you're ready to teach the concepts in the book, then you're ready to implement them.

You may even try banding together a community of practice (CoP) with others interested in crossing over to agile before you go full bore. With a CoP you would share ideas on how to effectively integrate new ideas as well as come to a consensus on what a good kick off project may be. I'll talk more about picking that project in a bit.

Here are a few recommendations on books that I really enjoyed. First, you've got to read Cohn's Succeeding With Agile of which I already quoted once above. This is a great book because it deals with introducing agile into an environment that has preexisting frameworks.



The Art of Agile Development

This book is equal parts about Extreme Programming and Scrum. It's very different from Mike's book in that it sometimes gets its point across by telling fictional tales of possible situations.



Agile Game Development with Scrum

Finally, this is the holy grail of Scrum books for Game Development. Clinton Keith was mentored by Mike Cohn who wrote the first book that I mentioned. Clinton was originally from High Moon Studios and could sort of be credited with popularizing agile for the industry.



Now that you have a coach or are armed with the knowhow, pick a project that isn't in the limelight. Yes, a low priority project that isn't going to have the eye of Mordor on it. The reason being is that a limelight project already has enough pressure as it is. And, heaven forbid, you don't have a clean execution your first time out, then you'll be joining the misgiving crew mentioned above.

A good first project should not be time sensitive or you'll surely default to your old system at the first sign of trouble. I prefer a first project to be a new feature, ideally something void of legacy code. Also, try not to pick a project that has a lot of dependencies or that relies on shared resources/talent.

Make sure that everyone shares a common lexical structure for what you're trying to achieve. For instance if you're going with Scrum, then be sure that all of the stakeholders understand what it means to be a stakeholder. If they don't get what Pigs and Chickens is all about, then you're not going to be happy with the outcome. So, get the definitions for all roles and responsibilities defined up front and be sure that there is mutual buy-in from all parties.

Buy-in, Mike Cohn talks a bit about this in Succeeding with Agile. I believe Shane Warden, of The Art of Agile, does as well so rest assured that I'm not the only one who abides by this stuff. Find someone in each camp to champion agile for their respective discipline. The more open minds, bonus points if they're respected influencers, you have will only result in a smoother adoption. Respected colleagues that support the effort are more valuable than gold. They help people that are on the fence about agile to give it a shot.

Be sure to give the whole metamorphosis some time to play out too. Rome wasn't built in a day and neither was effective project management. Agile enables you to fail fast which implies that you may fail at some point. This is a good thing because we're getting the data on what isn't working while we still have time and resources to do something about it. And as you know, the retrospective process is there to help us evaluate and modify accordingly. Allow for a few blunders when you schedule your test run. How to schedule is a much longer conversation and out of the scope of this article. However, all of the books above have solid advice on the subject.

Quantitative data is important and it goes a long way in convincing the nonbelievers. You'll want to record your results and compare them to what you were doing previously. Sure, you'll want to start tracking velocity; but, if you're new to an agile process like Scrum, then you won't have anything to benchmark against. So pick a few basic stats. Try tracking number of meetings, duration of those meetings, number of bugs found/fixed, etc. You'll know what is most important to your company. Select five or six pain-points and get ready to optimize. Done correctly, agile will blow the doors off of sequential for reliable release planning, stable tested code, steady customer feedback, and time efficiency in general. Dr. Jeff Sutherland, a co-creator of Scrum, has even gone on record in saying that:

“If you look at most corporate meetings you will see 50-80% excess overhead. These are the meetings that Scrum eliminates on day 1 if done properly.” – Dr. Jeff Sutherland

My last tip is to avoid using any fancy agile software solutions to start with. There are wonderful tools out there but why increase your learning curve? You can add those tools into the mix later. Remember the first declaration from the Agile Manifesto:

Individuals and interactions over processes and tools - Agile Manifesto

Scrum can be run effectively with nothing more than a stack of index cards and cork board. Do yourself a favor and only add solutions that truly save you time.

That's it. So to recap:

• Understand the rules before you play
• Allocate enough time for a proper test
• Get everyone on the same page
• Seek out influencers in each discipline to champion
• Pick a project that isn't in the limelight to start
• Prove your point with quantitative analysis
• Individuals and interactions over processes and tools

Hopefully these suggestions will aid you on your way to making game development fun and efficient!

Scrum: Retrospective Questions

Clinton Keith, in Agile Game Development with Scrum (pg 79), lists the three questions that should be asked in every retrospective as:

1) What things should we stop doing?

2) What should we start doing?

3) What is working well that we should continue doing?

These are solid questions that are straight to the point and that match the simplicity of the Daily Scrum questions. However, what do you do if there aren't any contributions? After reading this article on Gamasutra, I got to thinking about just that. I've been in meetings that aren't active and they're a drag. Therefore, I believe that having a few canned questions to get things going isn't a bad idea. This is especially true for teams that are new to scrum.

Before I dive too deep, I recommend the above article to anyone that is looking for some good advice on how to run an interview. I'll explain how this ties into sprint reviews in a second. In the article, Jeremy Gaffney offers some ideas that will help folks being interviewed as well as those that conduct them.

Here were my takeaways:

-First, the quality of the interview is in the quality of the questions that you ask.

-Second, the value of a candidate is found in what they find valuable.

From the article...

“Ask questions for which there are no uninteresting answers,” Gaffney said. For example, a producer may ask, “Who’s the last person you fired?” He explained, “What you care about is digging out an interesting [aspect] of their past.”

Asking someone who they've fired is an interesting approach to reach the core of a candidate. However, my vote would be to keep things slightly more positive. You could try something like:

- What was your biggest success and how would you go about replicating it?

- Can you give me an example of a situation where you were certain that you were going to miss a deadline and what you did to dampen the impact?

- What are the most useful habits that a team member can exhibit?

Now then, this all parallels into a retrospective because the same rules apply. Let's think about what we're trying to get out of the retrospective in the first place. Well, this ceremony is the closure of the feedback loop. It's only logical that we'd want to inspect what occurred during the iteration to see if there were any lessons learned.

- What did we learn?

That question by itself isn't going to make the conversation flood in. How about...

- While building the onboarding tutorial, were there any aspects that you would like to revisit in the next iteration?

or

- While building the onboarding tutorial, what optimizations did you make to your workflow that helped you along the way?

Use the Sprint Backlog as the springboard to target meaningful data points. The goal being to key in on specifics with an eye on finding value that the project or team will benefit from. Asking quality questions can surface improvement issues/technical debt, new useful techniques, bottlenecks, and product insights. A good retrospective will have each and every team member walk away with a new technique to try or insights on how to improve efficiency. To create a culture of sharing is essential in building a successful team.

RE: canned retrospective questions, here are some to get you going!

While doing Sprint Backlog Item (SBI), what aspect was most challenging and why? What would make it less?

If you had to rebuild SBI, what approach would you take next time around?

What beneficial optimization to workflow did you make during this sprint?

What new resources would have improved our production cycle?

Were there any heavy refactors necessary this time around? If so, why?

Did you read any informative articles that inspired some change which directly effected this sprint?

Analyzing the problems and impediments from last sprint, have any similar issues resurfaced this time around?

I think you get the point. The goal is to get the conversation moving and to see what we can learn from one another and, thus, help us all make life that much easier.

Overview of Test-Driven Development

What is Test-Driven Development?

"Test-driven design (TDD) is a development technique where you must first write a test that fails before you write new functional code.[...]TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. - Ambler"

Scott Ambler has a thorough article on Test-Driven Development that explains the methodology. If you're curious on the subject, I recommend reading it:

http://www.agiledata.org/essays/tdd.html

SCRUM of SCRUMs meeting questions

While reading Succeeding with Agile, I rather enjoyed Chapter 17 which was on scaling SCRUM. Here's a brief explanation of what was covered.

When coordinating work among several SCRUM teams, it is beneficial to hold SCRUM of SCRUMs meetings. These meetings differ from standard daily SCRUMs in that they are not timeblocked to 15 minutes. They allow groups of teams to discuss issues that pertain and focus on areas of overlap and integration. Such issues can, if not regularly settled, compound and critically hamper production.

When selecting who should attend from each team, it's best to choose a technical contributor (programmer, tester, designer) rather than the Product Owner or ScrumMaster. Your attendee can vary from meeting to meeting. Select the attending member based on who is best suited and knowledgeable about the state of the current sprint. The goal of the meeting is, as was previously mentioned, to remove barriers and efficiently sooth issues that arise from cross-team-dependencies.

Mike Cohn describes the differences of SCRUM of SCRUMs and daily SCRUMs as:

- They do not need to be held daily
- The do not need to be timeboxed to 15 minutes
- The are problem-solving meetings

Hosting a SCRUM of SCRUMs meeting

First off, you should only host 2 to 3 meetings a week. If you find that you need more, then you should analyze your sprint planning process.

Meetings should allow for each attending member to have 15 minutes to go over the following three questions:

1) What has my team done since we last met that could affect other teams?
2) What will my team do before we meet again that could affect other teams?
3) What problems is my team having with which it could use help from other teams?

After each member has had the floor, the focus should switch to any pending issues on the issues backlog.

The Two Pizza Paradigm

What is your ideal team size? I'm going to side with Jeff Bezos...

"two-pizza team": If you can't feed a team with two pizzas, it's too large. That limits a task force to five to seven people, depending on their appetites.

My new agile mentor Mike Cohn explains why this works:


- There is less social loafing

Psychologist Max Ringelmann coined the concept of Social Loafing, aka the Ringelmann Effect, in 1913.

[wikipedia on Ringelmann Effect] "...the lack of simultaneity of effort in groups, which interferes with efficiently combining individual inputs."

In other words - this concept explains the tendency that individuals have in larger groups to exert less effort because they believe that the mass will overcompensate for their minimal exertion.

- Constructive interaction is more likely to occur on a small team

Mike cites Stephen Robbins here:

[Stephen] has concluded that teams of more than 10 to 13 people have a difficult time establishing feelings of trust, mutual accountability, and cohesiveness. Without these, constructive interaction is difficult (2005, Essentials of Organizational Behavior)

- Less time is spent coordinating effort

This is a no-brainer... More bodies = More logistics. Trying to herd 10 people is exponentially more challenging than half that.


- No one can fade into the background

Yes, yes, and Yes. I don't know if you believe that humans are innately evil or good... but I believe that they're innately lazy. Let me ask you a question. What would you do with $1,000,000.00 lotto winning? Most folks that have taken my informal poll answer something to the effect of... "move to an island." God love them but most humans are lazy or at least exhibit laziness when given the chance.

- Small teams are more satisfying to their members

I concur. You get to feel like you're moving the needle. When you're just one of many, the joy and accolades of your accomplishments can get lost in the clutter.


- Harmful over-specialization is less likely to occur

I'm a fan of the generalist. Why not know as much as you can about numerous subjects?

Story Points

What are Story Points?

Story Points are units of relative size used in estimating software requirements. This is an alternative measurement to time based analysis. Points are estimated by assessing complexity rather than duration. Story points work in conjunction with User Stories.

What are they good for?

Story points are a fantastic way to estimate how long it will take to finish a product. They replace the standard time-based estimate with a more detached concept. Story Point is not the only vernacular around to describe this measurement. Some XP teams also call them cheezits or acorns.

We use story points when estimating for the long term, for instance against the entire product backlog. It's not a good idea to use them in planning for a particular sprint, as sprint velocity will vary.

Good quote from Mike Cohn on Velocity,

"This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning."

How to Prioritize Your Product Backlog

After watching Mike Cohn of Mountain Goat Software speak on the subject, I thought it would be useful to jot down my takeaway as well as some screen caps of the presentation:

(If you're new to scrum, here's a quick video primer on the topic of the history of scrum and its components...)

User Stories - Short to epic statements told from the perspective of the user.



The Iceberg - A pyramid of backlog items which appear in groups of small Items at the top and larger scope items in the middle and bottom.



Kano Analysis - The process of using exciters/delighters, linear, and mandatory features to adjust the priority of features in the product backlog.



Kano Analysis Process - Here's a glimpse of what the process looks like in action...



Theme Screening - Identify the selection criteria for what is important and evaluate against the baseline (mandatory) features.




Baseline Theme - The baseline theme is one that is likely but not guaranteed to be included in the upcoming release.

Theme Scoring - Similar to Theme Screening but avoids category compression by adding a weighting system. Doesn't have a single baseline theme but instead offers reference themes per attribute.




Relative Weighing - a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence.



Other Neat Recommendations that popped out:

- spend 10% of each iteration (sprint) working on the next iteration

- avoid including backlog features in the sprint that can not be encapsulated

- groom the product backlog often

- survey of 20-30 users is large enough to qualify as a quick representative sample