Agile Software Engineering by Orit Hazzan and Yael Dubinsky works largely as an undergraduate textbook, dealing a lot with how to teach and educate Agile methodologies in a learning environment. The book is broken up into progressively more involved steps with each chapter ending with a summary and reflective questions. There are also breakdowns of running an agile workshop and dealing with planning, time estimation, reflection. As a whole, the book is quite useful as a beginner-intermediate approach to agile, and would likely work well for teachers & students, as a lot of the structure of the book is related to setting up and teaching agile in a classroom.
One of the more unique parts of the book is how the book references different aspects of agile using the HOT (Human, Organizational and Technological) perspectives. I found that looking at different agile concepts through these filters a useful way to see how agile works on many different levels. The book is also good at giving examples regarding globalization and how organizational culture can be dealt with in projects that deal with outsourced or contracted work, and how agile attempts to address these issues by providing additional transparency and interactions. The HOT perspectives I found were especially pertinent in those areas.
My favorite example, however, was on the the chapter on Trust using elements of game theory, and where the Prisoners Dilemma is applied to a work environment. This was applied specifically to where developers choose to cooperate or compete with one another and results in three possible scenarios:
1. If both developers cooperate they will be more likely to succeed.
2. If only one developer attempts to cooperate (by learning the others code, helping the other etc.) there may be a success of the project, but potentially the one developer that choose to cooperate may not receive as much recognition (since time was spent cooperating instead of competing).
3. If both developers compete (do not help each other, do not learn each others code) there will be no integration of efforts and the project will likely fail.
Obviously the ideal scenario is where both developers cooperate with one another and are awarded equally. As a lead or manager it is important to recognize when and where this type of scenario presents itself, and attempt to foster cooperation over competition.
The book also points to a link to code of ethics at the ACM (Association for Computing Machinery) and while I was not able to find the original link provided in the book at http://info.acm.org/server/se/code.htm I was able to find a similar document on the same site at http://www.acm.org/about/code-of-ethics
Please allow me to delve into a small tangent here: while I personally prefer to not have to mention ethics directly to my team (in hopes that everyone plays nice), there is often a significant amount of emotion that developers have for their work, and some developers can be very defensive about there work, to the point of being difficult to deal with. This attitude is unfortunate as every piece of code can be improved, every single piece of code! There is no such thing as perfect code, just as there is no such thing as a perfect poem, or a perfect painting or anything else that requires design. Things like structure, patterns, organization of the code, variable names, comments, formatting, optimization and more, are all subject to interpretation of what is good and thus can vary greatly from developer to developer. As a team lead, I need the developers to cooperate on the coding standards, but even then there can be a significant amount of hubris in some developers which can cause internal clashes. I have been lucky in my attempts to be like "lukewarm water" between "fire" and "ice", but through my experience feel like a code of ethics may also be a necessity, especially in larger teams.
Overall, the book definitely fits the niche well of being a good learning tool for those interested in Agile methodologies, and is probably best suited in a group environment as many of the reflective questions would likely garner some very interesting responses.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Saturday, October 16, 2010
Thursday, September 16, 2010
Book Review: Agile Game Development With Scrum
Staying on this Agile game development interest, I was at the local book store the other day and ran across the book Agile Game Development With Scrum by Clinton Keith and thought, "how appropriate". Needless to say I was intrigued about the aspects of applying Agile directly to game development and immediately started reading it.
One of the elements that Keith keeps repeating throughout the book is that there are "no silver bullets" and adopting Agile won't save a team already on a death march schedule, nor will it allow a team to handle an impossible schedule. What Keith proposes instead, is that Agile will give a team a framework to learn about scheduling issues, current velocity and burn down charts as well as processes to detect potential issues with the schedule or design, far earlier in the project.
The main point that I found crucial to success, was the idea of cross domain teams. A couple artists, level designers, game programmers, server programmers etc. would form a single team responsible for part of the game, and would handle all aspects of that feature, while iterating over the different stages every two week sprint. Adopting this team structure, I feel, would be a huge boon to any game dev work place as the slowest part of any game is always (always!) cross team integration. Here are two examples of what could happen in a non-cross domain team:
1. An artist creates an asset and has no developer support to test it. Without integration they go on to make multiple assets the same way spending weeks (or months) of effort, only to find out later they need to modify all their assets now that dev has begun testing them.
2. Server team creates APIs for client, but no client team is available to test them. Server developers go off and create new APIs. Once the client begins testing the APIs they find they need to add additional parameters and/or bug fixes. This requires days of rewrites from a different developer, since the original author is working on another critical section and is not available to update the code.
I see these kinds of issues happening over and over again in large scale isolated teams, where individuals begin to make decisions that should require cross domain knowledge, but instead move forward without that knowledge, and often wastes significant time when having to fix their mistakes. This amount of rework can also result in a crunch time later to try and catch up on the previous wasted effort.
One of the other important things that Keith mentions is the issue of burnout during a crunch, and estimates that only two to three weeks actually show any improved velocity. Once a month (or more) of crunch has been put into effect the overall velocity is actually worse than that of a non-crunch velocity! People will get tired, frustrated and upset with extended overtime, and Keith points to the http://www.igda.org/quality-life-white-paper-info that measures the quality of life of game developers across multiple industries, which is a good read I will probably comment more on in a later post.
The book also goes on to describe a number of key aspects regarding Agile practices (running a scrum, user stories, minimizing up front documentation, continuous integration and working builds every sprint) but also concepts for implementing and introducing Agile and scrum to the workplace, shifting emphasis to a team responsibilities for setting schedules and working with Agile for Art, QA and Producers.
Overall the book offered some valuable insights and interesting experiences. I would love try and implement more Agile processes at my current workplace, but we shall see how strong the culture is resistant to change. There are a number of jokes about trying to change culture like Angry Monkeys if you are not familiar with the story (the link points to RTP Scrolls which gives a good example). It is a shame really, since I do feel that Agile is the way to go for any game, and that all management styles eventually move closer to Agile anyway, since it allows the most flexibility and creative changes to make the game more fun. I guess it is like that saying, that the only thing harder than learning something new, is forgetting something old.
But when it all comes down to it, game development should be fun too...
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
One of the elements that Keith keeps repeating throughout the book is that there are "no silver bullets" and adopting Agile won't save a team already on a death march schedule, nor will it allow a team to handle an impossible schedule. What Keith proposes instead, is that Agile will give a team a framework to learn about scheduling issues, current velocity and burn down charts as well as processes to detect potential issues with the schedule or design, far earlier in the project.
The main point that I found crucial to success, was the idea of cross domain teams. A couple artists, level designers, game programmers, server programmers etc. would form a single team responsible for part of the game, and would handle all aspects of that feature, while iterating over the different stages every two week sprint. Adopting this team structure, I feel, would be a huge boon to any game dev work place as the slowest part of any game is always (always!) cross team integration. Here are two examples of what could happen in a non-cross domain team:
1. An artist creates an asset and has no developer support to test it. Without integration they go on to make multiple assets the same way spending weeks (or months) of effort, only to find out later they need to modify all their assets now that dev has begun testing them.
2. Server team creates APIs for client, but no client team is available to test them. Server developers go off and create new APIs. Once the client begins testing the APIs they find they need to add additional parameters and/or bug fixes. This requires days of rewrites from a different developer, since the original author is working on another critical section and is not available to update the code.
I see these kinds of issues happening over and over again in large scale isolated teams, where individuals begin to make decisions that should require cross domain knowledge, but instead move forward without that knowledge, and often wastes significant time when having to fix their mistakes. This amount of rework can also result in a crunch time later to try and catch up on the previous wasted effort.
One of the other important things that Keith mentions is the issue of burnout during a crunch, and estimates that only two to three weeks actually show any improved velocity. Once a month (or more) of crunch has been put into effect the overall velocity is actually worse than that of a non-crunch velocity! People will get tired, frustrated and upset with extended overtime, and Keith points to the http://www.igda.org/quality-life-white-paper-info that measures the quality of life of game developers across multiple industries, which is a good read I will probably comment more on in a later post.
The book also goes on to describe a number of key aspects regarding Agile practices (running a scrum, user stories, minimizing up front documentation, continuous integration and working builds every sprint) but also concepts for implementing and introducing Agile and scrum to the workplace, shifting emphasis to a team responsibilities for setting schedules and working with Agile for Art, QA and Producers.
Overall the book offered some valuable insights and interesting experiences. I would love try and implement more Agile processes at my current workplace, but we shall see how strong the culture is resistant to change. There are a number of jokes about trying to change culture like Angry Monkeys if you are not familiar with the story (the link points to RTP Scrolls which gives a good example). It is a shame really, since I do feel that Agile is the way to go for any game, and that all management styles eventually move closer to Agile anyway, since it allows the most flexibility and creative changes to make the game more fun. I guess it is like that saying, that the only thing harder than learning something new, is forgetting something old.
But when it all comes down to it, game development should be fun too...
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Saturday, September 11, 2010
Extreme Programming
For those of you following, I have been delving into more & more practices and thought I would look into Extreme Programming (XP), created by Kent Beck (one of the original authors of the agile manifesto). Some of you (like me) may feel that the term "extreme" may be a bit overused (do our developers have to do barrel-rolls while coding at their desks?) All kidding aside, my interest in Agile development (especially Agile game development) is currently peaked and I will continue to delve into more an more aspects of it.
I decided to pick up Sams Teach Yourself Extreme Programming in 24 Hours by Stewart Baird as I had never really picked up a book that mentioned learning something so quickly (I remember the old programming post Teach Yourself Programming in 10 years by Peter Norvig :P). Nevertheless, I always feel it is important to start somewhere, and a book like Baird's gives a distilled view and framework to graft a suitable framework for extreme programming in a very concise and organized manner.
Baird's book, breaks down the XP aspects into twenty-four, "one-hour" chapters, each dealing with a different aspect of XP. There were a few chapters that were either Java or .NET based (especially related to Unit testing), so the relevance on those may vary depending on your interest, but the underlying principles are still important. But, of course the question "what makes it "EXTREME" Programming"? XP like many Agile methodologies focuses on "simplicity, communication, feedback and courage" (I feel like "planning" would also be important to add in the list, but XP focuses more on the developer than the leader/manager). XP has a lot of similarities to other agile requirements, but handles them in a slightly different manner, the most obvious being the focus on pair-programming.
The argument for pair-programming is the focus on quality, by having two sets of eyes on code as it is being written, the developers will end up with constant feedback, improved code quality and less bugs and design flaws. In Hour 11, Baird mentions the time lost upfront will be improved later as less bugs will be found and have to be fixed, thus actually saving development/bug fixing time. The trade-off being 15% slower dev times (to use pairs), but 15% less defects. Baird gives an example of how this will save time:
50,000 lines of code takes 1 individual 1000 hours (at 50 lines per hour).
50,000 lines of code takes a pair 1150 hours (at 50 lines per hour). 15% more time.
Baird uses Watts Humphrey's A Discipline for Software Engineering that 100 defects occur for every 1000 lines of code, but estimates that 30% could still remain after some software development "rigor" has been put forward, meaning 1500 defects in 50,000 lines of code. Baird mentions the total time could be 10 hours per defect to find and fix each one of them.
15,000 hours spent finding the 1500 defects from an individual developer.
12,750 hours spent finding the 1275 defects from a pair of developers. (15% less defects)
= A saving of 2,250 hours.
While I encourage the devs on my team to work together as much as possible, I am not as sure about implementing pair-programming. In my opinion, the most useful situations for pair programming would be when there is a lack of design, research is required in solving the problem, a lack of motivation from one of more developers or a real need for information sharing on a certain section of code. If the design is already in place and knows the path to take I would be less inclined to use pair-programming in those cases.
I will keep some of the extreme programming ideas in my back pocket and will think about them. I prefer the scrum approach for organizing, but do like some aspects of the book (including some benefits of pair-programming). For me simplicity is one of the best focuses, and in a professional work environment it is important to focus on YAGNI (You Ain't Gonna Need It) to prevent over-engineering (although I would encourage those interested in this type of engineering to experiment on their own home projects). I also like the idea of collective ownership of the code and of course the 40 hour work week (which is especially hard in games, as there are a lot more iterations than there are in other requirements (like instrumentation logic, or security systems, and I imagine some applications and systems too)).
I will continue investigating Agile methodologies as well as mention some of the "extreme" ideas to see if any of the other leads are interested in exploring these ideas. I would be curious to see how they work with the company, but think I may shelf them for the immediate future.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
P.S. I am following up on the Extreme Programming RoadMap and will see if I can find much in the way of Extreme Game Dev (although I still think it may be hard to top Keith's Agile Game Development with Scrum (previous post)).
I decided to pick up Sams Teach Yourself Extreme Programming in 24 Hours by Stewart Baird as I had never really picked up a book that mentioned learning something so quickly (I remember the old programming post Teach Yourself Programming in 10 years by Peter Norvig :P). Nevertheless, I always feel it is important to start somewhere, and a book like Baird's gives a distilled view and framework to graft a suitable framework for extreme programming in a very concise and organized manner.
Baird's book, breaks down the XP aspects into twenty-four, "one-hour" chapters, each dealing with a different aspect of XP. There were a few chapters that were either Java or .NET based (especially related to Unit testing), so the relevance on those may vary depending on your interest, but the underlying principles are still important. But, of course the question "what makes it "EXTREME" Programming"? XP like many Agile methodologies focuses on "simplicity, communication, feedback and courage" (I feel like "planning" would also be important to add in the list, but XP focuses more on the developer than the leader/manager). XP has a lot of similarities to other agile requirements, but handles them in a slightly different manner, the most obvious being the focus on pair-programming.
The argument for pair-programming is the focus on quality, by having two sets of eyes on code as it is being written, the developers will end up with constant feedback, improved code quality and less bugs and design flaws. In Hour 11, Baird mentions the time lost upfront will be improved later as less bugs will be found and have to be fixed, thus actually saving development/bug fixing time. The trade-off being 15% slower dev times (to use pairs), but 15% less defects. Baird gives an example of how this will save time:
50,000 lines of code takes 1 individual 1000 hours (at 50 lines per hour).
50,000 lines of code takes a pair 1150 hours (at 50 lines per hour). 15% more time.
Baird uses Watts Humphrey's A Discipline for Software Engineering that 100 defects occur for every 1000 lines of code, but estimates that 30% could still remain after some software development "rigor" has been put forward, meaning 1500 defects in 50,000 lines of code. Baird mentions the total time could be 10 hours per defect to find and fix each one of them.
15,000 hours spent finding the 1500 defects from an individual developer.
12,750 hours spent finding the 1275 defects from a pair of developers. (15% less defects)
= A saving of 2,250 hours.
While I encourage the devs on my team to work together as much as possible, I am not as sure about implementing pair-programming. In my opinion, the most useful situations for pair programming would be when there is a lack of design, research is required in solving the problem, a lack of motivation from one of more developers or a real need for information sharing on a certain section of code. If the design is already in place and knows the path to take I would be less inclined to use pair-programming in those cases.
I will keep some of the extreme programming ideas in my back pocket and will think about them. I prefer the scrum approach for organizing, but do like some aspects of the book (including some benefits of pair-programming). For me simplicity is one of the best focuses, and in a professional work environment it is important to focus on YAGNI (You Ain't Gonna Need It) to prevent over-engineering (although I would encourage those interested in this type of engineering to experiment on their own home projects). I also like the idea of collective ownership of the code and of course the 40 hour work week (which is especially hard in games, as there are a lot more iterations than there are in other requirements (like instrumentation logic, or security systems, and I imagine some applications and systems too)).
I will continue investigating Agile methodologies as well as mention some of the "extreme" ideas to see if any of the other leads are interested in exploring these ideas. I would be curious to see how they work with the company, but think I may shelf them for the immediate future.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
P.S. I am following up on the Extreme Programming RoadMap and will see if I can find much in the way of Extreme Game Dev (although I still think it may be hard to top Keith's Agile Game Development with Scrum (previous post)).
Agile Retrospectives (inspect and adapt)
Well, I said I would try and minimize the leadership aspects of this blog, but have been focusing on trying to help my team more with deadlines looming. One thing I will be doing with the team is trying to get them to help me help them :P Also, I suspect that I will be focusing on more and more Agile workflow models as I feel there are still a lot of hints of waterfall in the current system. Thus, my venture into trying to understand and apply these new ideas. I have some understanding of agile from my previous work at Leap In Entertainment where management there did a good job of applying Agile methodologies (without having to label everyone pigs or chickens).
I, however need a bit more information about agile as a whole (and will delve into other books on managing extreme programming etc.) and have begun absorbing the knowledge from online resources and library books. One that caught my attention was Ester Derby and Diana Larsen book Agile Retrospectives: Making Good Teams Great after I stumbled upon their video presentation Agile Retrospectives Talk. Of course "making good teams great" is exactly what I want to accomplish...
The need for retrospectives is to "inspect and adapt" the project and processes before the project is finished (i.e. while there is still time to improve the processes). Derby and Larsen recommend a commitment to doing retrospectives every iteration (in my case every two weeks) so that we can fix things before waiting until the end (and it being too late). Some of the things to investigate are the patterns that show how we work together, and determining what works and what doesn't, bringing up problems to solve and finding and reinforcing team strengths.
With this is mind I will try and focus on both the productivity and satisfaction of the team, and experiment, experiment, experiment. With each iteration hopefully we can see what worked from the previous retrospective and what did not. By finding out what does not work and recording it we will at least be less likely to keep repeating the same mistakes.
The breakdown that the book (and video suggest) are in five stages (page 19):
Set the stage
Gather Data
Generate insight
Decide what to do
Close the retrospective
The book also recommends allocating some shuffle time as well for very long iterations.
My focus for our next sprint/retrospective will be for trying to examine and explain what works and what does not, how well are we applying coding standards, how well are we refactoring, how well are working as a team and meeting our deadlines.
Wish me luck,
Michael
http://michaelhubbard.ca
P.S. The book is also on Scribd: Agile Retrospectives on Scribd
I, however need a bit more information about agile as a whole (and will delve into other books on managing extreme programming etc.) and have begun absorbing the knowledge from online resources and library books. One that caught my attention was Ester Derby and Diana Larsen book Agile Retrospectives: Making Good Teams Great after I stumbled upon their video presentation Agile Retrospectives Talk. Of course "making good teams great" is exactly what I want to accomplish...
The need for retrospectives is to "inspect and adapt" the project and processes before the project is finished (i.e. while there is still time to improve the processes). Derby and Larsen recommend a commitment to doing retrospectives every iteration (in my case every two weeks) so that we can fix things before waiting until the end (and it being too late). Some of the things to investigate are the patterns that show how we work together, and determining what works and what doesn't, bringing up problems to solve and finding and reinforcing team strengths.
With this is mind I will try and focus on both the productivity and satisfaction of the team, and experiment, experiment, experiment. With each iteration hopefully we can see what worked from the previous retrospective and what did not. By finding out what does not work and recording it we will at least be less likely to keep repeating the same mistakes.
The breakdown that the book (and video suggest) are in five stages (page 19):
Set the stage
Gather Data
Generate insight
Decide what to do
Close the retrospective
The book also recommends allocating some shuffle time as well for very long iterations.
My focus for our next sprint/retrospective will be for trying to examine and explain what works and what does not, how well are we applying coding standards, how well are we refactoring, how well are working as a team and meeting our deadlines.
Wish me luck,
Michael
http://michaelhubbard.ca
P.S. The book is also on Scribd: Agile Retrospectives on Scribd
Subscribe to:
Posts (Atom)