- Posted by Ian Suttle on August 9, 2008
- Filed under Agile | Process
Welcome to part three in our ongoing quest to bring an effective agile development process to IGN Entertainment.
Early on I recognized one piece of criteria critical to us succeeding in bringing Scrum to IGN - everyone had to buy in. This is a change for us and as has been drilled into our noggins for years, most people don't like change. The idea isn't to change for the sake of change of course, but to continually improve our team, processes, communication, and company. I'm sure most people can buy in to that one so we had to show how the change being proposed would accomplish these goals. We're still in adoption phase (it's been about three weeks) but feel it's going really well. Here's how we got to today:
Early Warning
We notified the product and engineering (us) groups we were looking to make some changes to improve how our groups worked together. We committed to introducing the process and let them know we were going to need their help. It wasn't the intent but this got their mouths drooling a bit for new ways to improve. I received numerous emails asking when we were going to "discuss the new process." Slow down people we're workin' on it!
Introduction to Scrum
We held Scrum introduction meetings with multiple product groups to discuss Scrum including key terms, roles, and the flow. We also thought it'd be good to run through a mock sprint but in hindsight that was a bit redundant with the rest of the introduction. We also created a Scrum cheat sheet to hand out so people could leave with some reference material. Lastly we opened the floor for questions. We certainly didn't have all of the answers but expressed our commitment to work through them together.
Working Together
Scrum has distinct roles and criteria to fulfill each piece of its process. The product owner must populate a product backlog and prioritize their items. A sprint planning meeting is held to review the product backlog and assign sprint backlog items with estimates. A daily scrum is held to ask the famous three questions of "what did you do yesterday," "what will you do today," and "is anything blocking you". It goes on and can seem like a lot to rookies like us.
The fact is in the beginning nobody knows how to actually execute on these things so we dove in head first. We were committed to giving this a real go and working together to answer questions and solve problems. We helped create the product backlog, provided access to tools for reviewing and prioritizing, ran the sprint planning meetings, and took the role of getting the answers to whatever needed to be answered. Learning, team building, and communicating at their best.
Delivering the Goods
A new process with magical results and innovative ways of getting things done doesn't mean squat if you don't deliver on your commitments. At the end of our first sprint we did what we promised in a variety of ways. The product group knew exactly what to expect from us, communication was improved through sprint planning and daily scrum meetings, and the work got done. In fact the work got done earlier than expected and we started taking more items before the sprint was over! I guess our estimates were too conservative but better that than too aggressive.
Delivering on your commitments builds trust in both the process and the people.
Marching Ahead
Formally holding a sprint retrospective meeting is another piece of the Scrum process. We did this after our first sprint which revealed a number of things, the most important being to account for everything you have to do using sprint backlog items: coding, code reviews, documentation, deployments, unit testing, meetings, testing, documentation, etc. If it needs to be done, add it!
I'm looking forward to continuing our rollout of Scrum and other agile-esque methods. Each day we invest reveals more clarity and benefits of the processes which is great because day one it didn't all make complete sense :).
Have you worked with Scrum and came across pros or cons you hadn't even considered?
- Posted by ian suttle on June 14, 2008
- Filed under Agile | Process | Unit Testing
Here Ye! Here Ye!
Welcome to post number two in our ongoing journey to bring an effective agile development process to IGN Entertainment.
There are a few staple tools and practices I feel are essential to an effective agile development process. Some may argue the direct correlation of these to agile development is incorrect... it's perspective.
Source Control
Love it or hate it source control is a biggie. There are a variety of source control systems available to meet the needs of most organizations. A few popular choices include Subversion, Visual SourceSafe, CVS, Team Foundation Server, and Perforce.
I recommend figuring out your source control feature requirements before choosing your flavor. Try a few before committing. Not all of them do branching, merging, changesets, etc, in the same fashion, and once you implement one it's likely not convenient to migrate to another.
Define your source control structure and processes for the team. Should code be organized by library type such as web apps, windows service, class libraries... or should it be organized by subject such as Direct2Drive, Fileplanet, etc? When should you branch vs. label? How do you version your software? If you forgo being organized up front you will pay the price later. For those of you who choose the hard way, it provides you the unique opportunity to write about lessons you've learned later on ;).
Unit Testing
I've been a part of the development community for about ten years now and if there's anything I've picked up on over the past couple of years unit testing is a contender for the most valuable. For those of you who are rookies on the topic or still haven't quite figured out what the hype's about, listen up. Unit testing provides you a certain level of confidence in your code both when you write the code and when you change your code.
Consider a monitor watching a website. Some monitors will watch the site and ensure expected behavior occurs given specific criteria. In this way a unit test is a lot like that monitor. You set up a very specific well-controlled scenario for a unit of your code (see method) and fail the check if the result isn't as expected. Each time you change your code you can rerun your ever-growing library of unit tests and be assured your tests continue to succeed. If a test is busted ya screwed something up. Oh, and as an added benefit, your class design changes to be more modular. That's just a little something extra.
Unit tests frameworks come in a variety of shiny colors. For .NET development NUnit is probably the most used. You can also check out XUnit and MbUnit. Lastly, Microsoft has developed their own framework which they've integrated in to VS2008. Feel free to argue your points but I'm not a fan of the MS Unit Test framework... there's too much auto-generated code for me. The point of unit testing is to know and control your environment. Code generation tastes bad.
TestDriven.Net is a cool add-on to Visual Studio so you can run your NUnit tests (I've not tried with another framework) and get your results in the Output window. It also comes bundled with NCover for code coverage analysis. Really useful.
Drink the kool-aid... it's yummy.
Continuous Integration
Continuous Integration in its most basic form is having your code built often on a scheduled or triggered basis. This is cool because you can know earlier than later if someone's changes are breaking the build (don't be that guy!). The alternative is having a broken build and when you have more than one person working on the code all participants are effected once they have the latest version. That's a waste of time for everyone and is frustrating to say the least. Continuous Integration doesn't prevent this problem but instead is an early warning system. Now add on automated deployments to an environment such as user acceptance testing and there's constantly a fresh view of the application without an engineering making it happen. That's cool.
My team is not using a Continuous Integration solution yet so more to come on this, but if interested, we're checking out Team Foundation Build and JetBrain's TeamCity.
How's This Related to Agile Development?
Admittedly you can run an agile development shop without any of these tools. These things I've discussed are just that... tools, not process. So how are these tools related to agile development? Everything I've discussed works really well with the iterative, always changing nature of agile practices. I'd hate to take on this process unprepared. Give me my armor, sword, and a horse before sending me off in to battle.
- Posted by ian suttle on June 13, 2008
- Filed under Process | Agile
Here at IGN Entertainment we're making an effort to follow an agile software development path. It's a bit of a new world for us. I'll admit we've described our development process to date as "agile/waterfall" or "quasi agile", neither of which are ultimately efficient. We've been digging into agile techniques for a couple of years and simply hadn't made the commitment. The longer we wait the more clear it is we need to make the move.
Our agile flavor of choice is the all-popular Scrum technique. I'm digging the predictability of feature delivery by defining the sprint backlog up front, having a known schedule for a sprint, open communication and transparency through sprint planning meetings and daily scrums, etc.
I'll continue to post info on our experience as we progress.
- Posted by Ian Suttle on September 7, 2007
- Filed under General | Process
Surely you've received this question from a business stakeholder: "When will my project be completed?" What you'd like to say is "I'm not sure, but I'm working on it" which of course doesn't fly. Software estimations are notoriously difficult to accurately predict. Book after book has been written to explain how to develop an accurate time estimate for software development. Most books are wrought with theories, complex mathematical formulas, and a lot more resource requirements than you've got at your disposal.
Personally, I don't find this a realistic approach in such a dynamic environment as the web. Most engineers I've seen revert to a review of the requirements and simply tag each section with a quick estimate. "Okay, that's an easy form and will take me three hours. This function will be about two days..." In the end you have a tally of wild estimates. Odds are you're going to be held to your timeline so go ahead and tell your life "be back later." If you can look at a single requirement and know it's going to take more than a few hours, you don't have enough details on the task or you haven't broken it down far enough.
So what approach is realistic? Let's start with project scope. Do your homework. Understand what you're building. Often you'll have
to know what you're starting with as well. If that's the case and
you're modifying an existing application be well versed in refactoring
patterns. If you determine the project will require more than a couple of weeks break it in to phases if feasible (see Sprint used in Scrum). The idea is it's far more realistic to accomplish shorter term goals (days, weeks) than longer terms goals (months, years). Think about it. Would you feel more confident in completing a single module or a group of modules within a single timeline? Also keep in mind, change happens. Requirements change, technologies change, resources change, and priorities change; all items likely to be out of your control. By taking on a short term goal you reduce the chances of change affecting your goal and efforts.
Once you've etched out a short term goal, it's time to design your solution. I don't mean create a web site diagram and a flow chart. I mean that and more. Design your database schemas including tables, stored procedures, functions, and relationships. Design your class libraries including methods, enums, types. Design your pages including controls, third party libraries, UI. You're designing how these elements all work together, but remember, just for your short term goal. If you can't design your solution at this level of detail, you don't know what you're building and need to go back to step one - do your homework. However, realize the inverse. You can probably predict with good accuracy how long a stored procedure will take to write. Not only can you estimate a stored procedure but you can estimate a method, class, user control, table, etc. Don't allow any less than an hour or any more than four hours per task. If more than four hours you need to break the task out into more detail. As you generate your estimates document them and track your progress. Don't forget to account for code reviews and project documentation. TFS work items are great, but Excel worksheets can do the trick.
I also recommend having the design and estimations reviewed by a senior engineer with a proven track record of achieving their timelines. This is your check and balance. If you estimate a stored procedure will require one hour of development but it really requires two, you were 100% off. Apply this boo boo to multiple estimates and your two week project can quickly turn in to a three week project. That's a 50% increase in time. Expect you'll have at least some items underestimated. Your reviewer should be able to help you adjust and pad your estimates to account for these inaccuracies. In the end, you'll have a good estimate to work from.
Let me also say I'm a realist. I know engineers cringe at the thought of documentation. However, my money says engineers dislike providing estimates they aren't confident in and missing their deadlines more than their disdain for documentation. When you can provide accurate estimates you gain a lot: confidence, trust, more normal business hours, and a rockstar rep.
