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.

SCRUM 101

Here's a quick presentation that I put together that discusses the history of SCRUM and its mechanics. It's ment as an overview and not the definitive explanation.

Whether you're a software engineer, a QA tester, a producer, or an executive that manages development you would benefit greatly by implementing some sort of Agile project management.

I hope you find it useful.

Met Jeff Sutherland

I got the chance to sit down with Dr. Jeff Sutherland last week. What an honor! It was at an event put on by Digital LA.

At the event, Jeff went over the basics of Scrum and some general insights.

Among his many pearls of wisdom - I enjoyed that he reminded us of the MIT slogan "Demo or Die". It's so important to show progress. Although apparently MIT changed that mantra to imagine and realise in the 90s.

It was perfect timing, as I gave my first lecture on Scrum that very weekend.

My lecture btw, went off without a hitch. I entitled it Scrum 101. Here's a look at the syllabus:

- A brief history of Scrum and its significance

- A functional understanding of the framework

- Basic instruction on implementing Scrum in your next small team project

I was able to cover my material in an hour and 15 minutes. However, I think I'll plan on a two hour timebox in the future. After the material was covered, we had a Q&A session that lasted for an additional hour.

Hyperproductive Distributed Scrum Teams W/ Jeff Sutherland

Distributed teams can be a nightmare with Scrum, if you don't know how to tackle the challenges that they present.



Here's a link to a PDF that shares some of the slides in the presentation:

PDF

One interesting tidbit, Jeff asked...

Are you properly doing Scrum? He then referenced the Nokia Test as the benchmark.

Here's the Nokia Test by Bas Vodde

• Are you doing iterative development?
– Sprints must be time boxed to four weeks or less
– Software features must be tested and working at
the end of an iteration
– Sprints must start with an Agile specification
• Only 50% of Scrum teams worldwide meet these
criteria
• Do you know who the product owner is?
• Is there a product backlog prioritized by business value that has
estimates created by the team?
• Does the team generate burndown charts and know their
velocity?
• Is the team’s work free from disruption by project managers (or
anyone else)?

Jeff Sutherland on Scrum

Jeff is one of the founders of scrum. Watch this to get the story for the horses mouth.




Here one of the cool slides that he goes over.



It explains really well how companies function. I know that I've worked for more than one autocratic organization!

Scrum et al by Ken Schwaber

Ken Schwaber is a remarkable individual.



Bio:

Ken Schwaber is a software developer, product manager and industry consultant. Ken worked with Jeff Sutherland to formulate the initial versions of Scrum development process.

What are User Stories?

A definition of User Stories

A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software. - Wikipedia

In Succeeding with Agile, Cohn defines User Stories as such:

A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. (p238)

How to write a User Story

Here's a great blog from Cohn on his primary User Story template and here's the template that I use care of Cohn's suggestion:

As a <type of user>, I want <some goal> so that <some reason>.

In this template, we select and cater to three important pieces which are user role (type of user), the feature (some goal), and the value statement (some reason).

The user role helps ground the User Story by giving it relevance. The feature is obviously important because it is what we're building and, finally, the value statement justifies why we're bothering with the development in the first place.

Are there alternatives to using the As/a template or User Stories in general?

There's never one single way to solve a problem. Personally, I enjoy the As/a template because of its simplicity. Regardless, here are some other techniques that I've run across. Research as you like...

Feature-Driven Development (FDD) - Features

A feature is a small, client-valued function expressed in the form <action><result><object>. As the name implies, features are an important aspect of Feature-Driven Development (FDD) (Palmer and Felsing 2002).

Unified Modeling Language (UML) - Use Case Modeling

A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements. - Wikipedia

What does a scrum floor plan look like?

In addition to the roles (Scrum master, product owner, tester, etc), a scrum office layout is particular. Prepare for commonsense:

First of all, here's a quick video primer on scrum...

Now then, a lot of folks advocate for desks on wheels. This allows for dynamic configurations. Scrum is all about communication and team problem solving. Each Sprint will require that different team members work together.

Open Space - There are no tall cubical walls. The traditional cubic-caves defeat the purpose of the open space concept. Scrum floor plans can be described as war rooms. Important, avoid separating disciplines. We are cross functional teams and need to be able to communicate on the fly. The Scrum framework suggests that team members of all disciplines sit together.

Active wall utilization - As developers, we spend so much time in front of illuminated screens. Here's a shot of what Mike Cohn recommends as a typical Scrum board layout:



The layout of your board is up to you. Add what you need, as there are no rules. The image above is one configuration. You can experiment around to find what information is more useful to you. Post up the product backlog, issue backlog, your burndown chart, you get the picture. The goal is to own the space. Of interest, the scrum board concept comes from Kanban so read up on that for more background.

We're all equal in Scrum... You should avoid having coveted locations. You succeed in office configuration if there isn't a bad seat in the house.

Sanctuary - when at all possible, have someplace to retreat for quite time. This could be a space to clear your head, take a private call or meeting.

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.

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