Gamasutra: The Art & Business of Making Gamesspacer
Agile Development Hell: 3 warning signs
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 20, 2014
arrowPress Releases
April 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Agile Development Hell: 3 warning signs
by Oliver Teckert on 10/08/13 11:22:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Agile Development Hell: 3 warning signs

Let’s let a look at some specific warning signs that tell us when a project is heading for significant problems…or is already there.

 

Thomas is already in it.

1.  Unchecked growth in the Backlog

Unchecked growth can refer to estimates wildly outside of the scope project, endless new and incomplete additions in the backlog or just sheer volume of entries. The backlog is intended to be the vision of the project, generally in user story format with a focus on goals that relate back to the key features that define the project. The backlog is also where initial estimates appear to start sizing out features and development work which help bring clarity to the scope and capacity necessary to complete a given feature. Once the project begins the purpose of the backlog is to track development work and to flush out unexpected work that must be added to the backlog to complete the project successfully. Typically there are scope and capacity limits that have been carefully determined for the project in relation to its original scope. If the scope of the project grows in the backlog without regular grooming you have a traditional scope creep problem.

Without intervention in the form of direct action to redlining your backlog you will lose the ability to meaningfully track your project in the backlog. It will become a mismatched listing of half-finished features, new ideas and work that will never be complete. Without the ability to track progress in your backlog, you will turn to extreme reporting.

 

After going over the reports the Bob’s would like a word…

2.  Extreme reporting

Reporting is an important part of the feedback loop for the managers and team members. It serves to help monitor and track progress in a number of ways and can help you gain valuable insight into different aspects of your project, especially when you need to determine if corrective actions are required when things start to derail. When you can’t track your backlog proactively, you often turn to reactive reporting. And the worse things get, the more the project gets behind and confusion mounts on priorities and dependencies, the more reports you begin to run. Reports can help show you where structural deficiencies are in your process, which can help you prioritize getting your backlog back in order, re-evaluating your sprint commitments or looking at the skillset composition of your teams. 

The big danger here is that you use reports to start running your project through a triage workflow that resembles the way you work with bugs during an alpha/beta process. Instead of looking at the big picture and planning your development strategically, you are now concentrating on the very immediate short-term priorities in an effort to get the project back on track. But with short term planning and triage-like workflows the problems will keep piling up. The thing to remember here is to use the reports to target structural and procedural problems in your production management process and to make them your highest priority to resolve. Take a look at the basic execution of your project and reinforce the areas that are failing to get the job done. You need to know exactly why you measure what you measure and what decisions you are going to make based on the issues you track. In fact, everyone involved in the metrics-gathering should be very clear of this so that people are: 

  • Motivated to provide the metrics 
  • Report the right thing without misunderstanding

Remember that reporting can be a huge hindrance to a project if you are constantly measuring metrics that do not address your core development problems.

Of course you will fit. What could possibly go wrong!

3.  Consistent sprint failures

Sounds fairly obvious right? If you are encountering consistent sprint failures, you are most likely not progressing well with your project. The issue here is that many development teams do not recognize sprint failure as problem. They define failure so completely and utterly that significant alterations to the sprint are considered acceptable, even when they completely move the goalposts for the sprint or make the sprint planning session redundant due to constant change.

Warning signs for concern include:

  • Changing estimates significantly and redefining scope within the sprint (Moving goalposts)
  • Removing items and adding items aggressively from the backlog (Sprint thrashing)
  • Shaping the burndown signature into a nice 45 degree downward slope (Renders velocity meaningless)

The purpose of the sprint planning meeting is to recognize sprint goals, commit stories and do some more detailed estimates within the sprint before work begins. This process is as much to guide the team through the next sprint iteration as it is to gain insight into the features you are building out. Significant failures can result when:

  • Requirements are inadequate and must be reviewed
  • New priority items must be expedited for immediate work 
  • Interruptions from meetings, illness or other unexpected distractions affect your velocity 

Recognize the root issues and address them directly, do not wait to clean up the sprint once it’s started. Proactively address the changes sprint to sprint and get the requirements nailed down. Accept that velocity is designed as a measure of organic team progress that is invaluable. If used properly it gives you a realistic understanding of your team’s capacity based on actual effort. If abused it can be used against the team to ungratefully load them with more and more work, until agility is lost and sprint failure is inevitable.

Though there are certainly many signs your project could be headed for trouble, these are three of the top issues encountered working with developers.  If any of these issues describe your project or sound very familiar, you should probably sit down and re-evaluate what you are trying to accomplish on your project and how to plan to get there.

 


Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.19.14]

Associate Art Director - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.19.14]

Associate Animator (temporary) - Treyarch
Activision Publishing
Activision Publishing — Santa Monica, California, United States
[04.19.14]

Executive Producer-Skylanders
Activision Publishing
Activision Publishing — Santa Monica, California, United States
[04.19.14]

Director, Central User Testing






Comments


Michael DeFazio
profile image
I'm a firm believer in "people over process" part of agile that is often overlooked:
...and during a previous experience with scrum I realized that although communication and collaboration is one of the core tenets of agile... the "mechanics" of scrum (i.e. the meetings, planning the reports, etc.) can be at odds with this goal, and this is specifically true when people figure out that (they can save themselves alot of "work") by becoming an "isolationist" (I do MY tasks with blinders on, and dont tell anyone "salient" things about HOW I'm doing it and don't meddle in anyone else's business.)

All of these tasks and artifacts of scrum assume that people are communicating the salient things, (but if the "Spirit" of collaboration doesn't exist then it's all for naught). So I'd add one of the greatest signs of a project entering development hell is that people start becoming a scrum "ritualist" or "isolationalist".

http://www.infoq.com/presentations/agile-lessons

Oliver Teckert
profile image
You are absolutely right about collaboration and communication being core development principles, regardless of development practices. Ironically the problem you describe often exists before Scrum has even been adopted. Most developers these days started their careers with traditional Gantt style scheduling with everyone broken up into their functional departments. Then when Scrum is implemented and fails, management has a hard time understanding why and Scrum gets the blame. Not to mention that pure scrum can be inadequate in addressing the demands of the gaming industry and often needs some customization to fit the studio style and project goals.

Cultural problems can't be solved by implementing mechanical processes. You have to work on mentoring people through a different development mentality. Changing the meetings and mechanics is the simple part!

Trying to change a persons mentality is extremely challenging and ultimately can fail pretty badly.

Arnold Hendrick
profile image
Scrum and agile are weak tools for long-range planning and feature estimation. An undeclared by very obvious core philosophy in agile is that the further out you look, your plans become more ambiguous. In point #1 above, it seems that author advocates using the backlog as some kind of "perfect project plan" that accurately maintains a list of correctly defined and properly sized project features that match available time and resources.

The critical thing about backlogs is that you must prioritize them. In every project where I've dealt with backlogs they always got bigger. We were constantly subdividing and resorting the backlog into various general priorities as the project evolved, such as "backlog for this release" plus "backlog for next release" plus "backlog of other stuff needed for launch" and more. Having big priority buckets was handy for dealing with lots of stuff. This also allowed us to devote more attention to stories of immediate importance.

Sadly, I haven't found a scrum software tool that provides flexible methods for handling story heirarchy (epics-themes-stories) alongside the problem of sorting stories between sprints, releases and various backlogs. Perhaps the most frustrating thing is when a scrum tool presents backlogs in one fashion, and sprints in a different fashion, and the heirarhy in yet a third fashion, all on different screens, and each taking 2-5 seconds to load. ARRGGH!!! If the visual paradigm for a story changes as it changes states within the tracking system (be it gantt, pert, scrum or kanban), managers lose the ability to perform a "bird's eye, at a glance" review. When that ability is lost, managers may to fall back on old-fashioned firefighting crisis management full of non-negotiable immediate demands. That way they can concentrate on a small number of key goals and avoid that impenetrable thicket of crappy software.

Oliver Teckert
profile image
Hi Arnold! Backlog estimates are only intended to be a rough estimate to gauge the size or amount of work that needs to be done. The idea is to get a rough idea of the project scope, since as your mention the further out you look in the project the more ambiguous it gets. Continually grooming the backlog is critical to keeping growth manageable and adapting as the project moves through implementation. Without grooming the backlog becomes a bloated wasteland that does not provide any meaningful information. The idea is to keep up to date with the state of the project in relation to the vision of the project. Certainly there is no perfect project plan however, there can be a flexible vision of the project that is adapted with ongoing efforts and unforeseen difficulties.

Tagging your backlog into smaller sub-sections is essential for large projects, be it in terms of releases for live projects, milestones for ongoing development or to flag special items for reference in a later phase of the project (TCR/TRC critical issues or DLC potential).

Your last comment about handling story hierarchy for epics/themes/stories is very true. It is difficult to handle since dependencies can be modeled in so many ways (Hierarchy, priority, procedural, etc) it becomes necessary to privet your view of the project depending on your needs. I would suggest that the visualization issues (regardless of project methodology) are representative of the challenges the industry faces with complex game development projects.


none
 
Comment: