Last week I attended a half-day Agile Cafe event sponsored by Shopzilla and Rally. Paul Wynia from Irdeto and Rony Sawdayi from Shopzilla both provided some insights to their Agile deployments. Paul, Rony and Mik Quinlan from Shopzilla then had an open panel discussion covering topics from the crowd. Finally, John Martin from Rally wrapped with a keynote presentation on Agile teams.
I’ve spent the past few years learning about, testing out, and running Agile in various aspects. One area that was always tough to get a handle on was how to actually get started and what things should be done to “be Agile.” The problem with asking that at any Agile gathering is that the usual answer is “let the teams self-organize” and “learn by doing.” That’s great and all, but if I toss a couple of developers, UI designers, QA testers and a PM into a room they’re more likely to follow some craptastic waterfall method than randomly luck into following an Agile process. So, I’ve always wanted to find some simple framework or documentation to give teams to start following and *then* let them self-organize and do what works best for them. So, my comments and thoughts that follow are fueled by my notes from this Agile Cafe as well as some experience from the past few years.
Why Implement Agile?
Some of the benefits that teams have seen after implementing Agile are continuous feedback, flexibility, improved morale, and transparency. The continuous feedback from business champion, product owner, testers and all others in the team help make sure that what’s being worked on is getting the focus of the entire team to make sure that what gets released is actually what’s needed. Given the nature of Agile and that you always make a release date, just sometimes with a smaller or different set of scope, helps to make sure that your team ca adjust up or down the level of scope based on the amount of work they can deliver. Someone gets sick? Drop a user story from the iteration. Someone can’t sleep at night and want’s to work on a nagging bug? Great, more items in the release. Did the Sales team rope in a new client who needs a new feature? Drop some user stories in priority and get those new ones added to the top of the release. It’s that flexibility to add and remove scope that eliminates those 18 hour days that cause stress for teams trying to make a release with a set-in-stone set of requirements. Of course, this takes flexibility on the business side but ideally they’re seeing benefits from being able to change their minds and quickly get results from the team anyway.
The ability for the team to self-select the items from the release priority list allows them to create some quick wins in delivering code that the business needs and thus helps boost morale that they’re not stuck working on a useless feature that no one needs. Stakeholders are as involved as they want to be and get full transparency into what’s being worked on, what will likely make the release, and what won’t likely make the release. The good & the bad of the transparency will hopefully overshadow the black box that usually goes with waterfall development. The best quote I’ve heard so far on this came from the Shopzilla team that with Agile “you go from a black box to a glass box.” Pretty illustrative of the significant differences that people see between waterfall and Agile methodologies.
How Best To Get Started With Agile?
The best way to get started with Agile and make sure a high probability of success is to start with Executive Sponsorship, an Agile Coach, a Pilot Team, and Offsite Training. The executive sponsorship helps make sure that you have the support to try Agile without any other competing goals or requirements. Ideally you’ll have a pilot team consisting of a couple of developers, designers, testers to go with a product owner and a business champion who are all co-located and even more ideally working in the same area or room together. The Agile coach will help make sure that as you get started that you’re following the proper aspects of Agile, will help answer questions along the way, and help make sure that after the first few months that the group doesn’t regress into a waterfall method or a Scrum-But process (“it’s Scrum, but we don’t do retrospectives”, etc.). The offsite training helps bring the pilot team together to understand how Agile works, to decide how they want to adopt and self-organize under Agile, and provides a comfortable and safe setting to start out with the Release & Iteration planning before heading back to the office to get started with daily standups.
As part of the offsite training, you’ll want to make sure that everyone agrees to their role and responsibilities on the team as well as the general processes to be followed on a daily/weekly/etc. basis (e.g., “I’m a developer and I’ll attend the daily standup at 9am every day and make sure my Rally tasks are updated at the end of every day.”). Some teams handle their standups by developer and others by user story; the obvious answer here is to let the team choose. If you can’t decide, I’d recommend the story-based approach as this generally keeps all team members focused throughout the standup instead of potentially drifting off when it’s not “their turn” to talk about “their stories.” This also ensures that what’s covered in the standup are the most important stories (assuming you start at the top of the priority list). Also, standups don’t have to be at 9am; sometimes folks don’t operate conversationally that well early in the day, so let the team decide what time works for them. The standup isn’t a status report either, it’s a conversation within the team and the best and easiest way to get help with issues team members are facing.
You’ll find that instead of pushing work to developers that you let the team pull work from the prioritized release backlog allows for a feeling of ownership in the release. Developers can pull their work on a daily basis based on their progress instead of sweating it out at the end of a release to get everything done that was committed by someone other than them self.
Another important, and often overlooked, aspect of “going Agile” is the retrospectives at the end of a release cycle. You need to remember to demo what was completed, go over what went well, what could be done better (and fix these issues), and then celebrate the release (margarita Fridays!). Some teams have found that combining the demo, retrospective and release planning into one meeting on a Friday helps kill several birds with one stone.
Change isn’t usually something that people seek out. So, to get your organization to change from waterfall to Agile you’ll generally need to prove that Agile works with a pilot team and show that you’re able to provide business value. As you get a pilot team started on Agile, you’ll want to make sure you’re measuring the success of the implementation to help evangelize Agile later on and prove its usefulness in your organization and (ideally) expand the implementation to other teams. Before Agile were you missing release dates and are now having on-time, consistent releases? Have you gone from constantly fighting fires due to several bugs appearing in releases to a dwindling list of defects? Are your team members happier now that their days & weeks are more predictable and are able to maintain a better work/life balance since they’re signing up for user stories instead of having work pushed to them? Did you have confusion in your team on competing priorities before and now that everything is prioritized by the product owner & business champion in Rally your team actually knows what to work on?
If you decide to have an Agile coach for just the first iteration or release, then make sure you at least bring them back a few months later to help analyze your progress in the Agile implementation and help you make any process tweaks to make sure the long-term viability of your deployment.
Some people see Agile as a way to avoid the documentation that goes along with waterfall, but you’ll still want to document the code as you go along and certainly the same with creating artifacts based on features and bug fixes in releases. With that in mind, you may want to keep a wiki that tracks this information as this is a good way to make sure you can easily knowledge transition as your team naturally changes or others approach with product questions.
How Best To Get Started With Rally?
Besides the obvious answer of working with your Agile coach, you’ll want to have Rally come onsite and help set up your instance of Rally based on how your team has chosen to self-organize and operate Agile. You’ll likely want to set up some of the customizable dashboards for the various types of people in your pilot team and others tracking your team (e.g., VP, PM, Developer, Tester).
You’ll want to work with your Agile and Rally coaches to decide how you handle maintenance/support of your product as well as how you best go about keeping Rally updated. Some organizations may decide to have engineers start in their Maintenance/Support organizations before moving onto the Product team as a way to learn the product. Ideally the Maintenance/Support team can get the details they need from your product wiki and anything missing should be detailed back into the wiki once issues are resolved. As mentioned before, ensuring that team members make a daily effort to update their Rally tasks will go a long way in keeping your Agile implementation healthy.
How Can You Expand Your Agile Implementation?
Some of the best ways to increase your team’s productivity and increase your organizations Agile adoption are test automation and continuous integration practices. Test automation will help make sure that your testers aren’t spending time on regression testing and instead are focused on scripting tests for the new stories or defects. Then these tests become part of the test automation that helps regression test. Companies like Electric Cloud offer solutions to help in the continuous integration space (e.g., Electric Commander). This allows developers to quickly test their changes and only create builds with workable code and eventually deploy based on clean builds from all developers. You’ll need a fairly advanced operation to get to this point, but if your organization or product are large enough then test automation and continuous integration and absolutes necessities to “get to the next level.” Assuming that you run UI tests nightly, you’ll want to make sure that any issues found get addressed immediately the next day or, at worst, get added to the top of your defect priority list; you don’t want to be adding technical debt in releases.
Other areas to expand your Agile implementation are when you have multiple Agile teams, you may want to have a top leads review / a meta scrum / a scrum of scrums that is essentially a meeting outside of the Agile team that allows for a daily review of issues across the organization. This would typically be attended by the various product owners and those in management interested in issues and/or capable of helping resolve any blocks that are keeping the teams from proceeding. This can also serve as a good view into the status across the organization, but should be limited from including those actively working on a team so they can instead focus on their user story development and defect resolution.
Once you start expanding from a co-located pilot team you’ll almost always find yourself running into an issue where your team is located across various time zones. While this is certainly not ideal, Agile organizations have made this work. You’ll want to have local Agile coaches and local managers helping the teams stay in contact. You generally won’t want different locations working on the same user story or defect as you lose too much of the day in time zone changes; thus it’s better to have collaboration on user stories and defects done at a local level. With that in mind, you’ll also want to have estimation done at a local level as different teams will likely operate at a different velocity and thus need different levels of estimation. If at all possible you’ll want to have autonomous teams by location meaning each location will have its set of developers, designers and testers instead of having developers in one location, designers in another and testers in yet another location. This helps make sure that daily interaction within the team on the shared user stories & defects. Web cams and video conferencing technology can also help aid in teamwork and reduce the friction caused by geo-location issues within teams.
Finally, the easiest way to notice that you’ve made progress in your Agile adoption is hearing “we” instead of “I” on your team.
Leave a Reply