LA Agile Cafe: All Your Agile Questions Answered!

2011 Agile Cafe

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.


Test Driven Development = Good, Acceptance Test Drive Development = Bad

For the most part, that was the message at the “Acceptance Testing: Just Say No” by James Shore Meetup tonight at the offices in Santa Monica, CA. James structured the talk as though it was a “fill in the blanks” Anonymous meeting (you know, Alcohol Anonymous, Sexaholics Anonymous, etc). The concept of Acceptance Test Driven Development (ATDD) Anonymous was actually pretty clever and came across pretty well, at least to me.

As for my general notes on the talk, he started with some background on the ATDD area focused on Ward Cunningham and his creation of Fit (aka, Framework for Integrated Test) as an original unit test tool that was co-opted as an ATDD tool. Fit spawned Fitness which is a wiki-based table tool, again, co-opted as an ATDD tool; another TDD tool mentioned was Cucumber.

James noted that it’s unfortunate that its easier to quantify the costs of co-locating teams than quantifying the hidden costs of not co-locating teams, but that in the end it’s better to co-located teams for success. For anyone who’s worked on remotely located teams (me being one of those folks), this doesn’t come as a surprise. I’ve found that my more successful projects, products, and roles were ones where I was co-located with customers and developers.

James mentioned four types of bugs and how to work to eliminate each. Requirements errors can be eliminated (or shall I say reduced) by having customers co-located with the product/development team. Programmer errors can be reduced by using Test Driven Development (TDD). Design errors can be reduced by continuous incremental design, by doing constant code refactoring, and by building in slack each week to do so. Systemic errors can be reduced by performing an RCA on all errors identified. More on these types of errors in a bit.

Now, how would a team work to reduce these four types of bugs? In serial or parallel fashion? Good question, so I asked James. His response was to take a large chunk and just do it, failing that go with TDD first. Outside of his own book and Michael Feathers’ referenced below, a good resource for guidance on adopting TDD are his Let’s Play TDD webcasts that go through real world examples as well as his chapter on TDD in his book. His experience seems to point to the Kaizen approach not working for TDD.

James stressed the importance of cultivating an attitude of “bugs happen to other people” which is an attitude that makes me drool. Having a team that thinks & acts like that? Now that’s sexy. (I know, I know, I’m a nerd.)

The best way to solve co-location issues (i.e., having remotely located teams) without co-locating is via expensive video conferencing equipment or better by plane flights to meet in person. Reading between the lines here is that you can spend all the time & money to get close to a co-located feeling, but until you’re actually co-located you won’t get all the benefits of such a work environment.

In terms of helping solve the issue of eliminating or reducing bugs on legacy software, James recommended Working Affectively with Legacy Code by Michael Feathers. And to read more in-depth on James thoughts on reducing the four types of bugs, check out his blog post on Alternatives to Acceptance Testing.

In short, combine TDD with great customer collaboration and co-located teams.


Agile Journal Seminar: Agile Comes to LA

The following are my notes from the Agile Comes to LA seminar on Thursday, December 17th 2009. The event was sponsored by AccuRev, Coverity, Electric Cloud, Rally Software, and BigVisible. The event saw leaders from each sponsor talk about how Agile software development techniques and the tools that support them can help you reduce risk, boost the productivity of your existing organization, and cut development costs.

George Schlitz (BigVisible): Agile Hits Ground in the Organization
+ Required, if humorous, reading: You Might Be a CrAgilist If…
+ Educate PMO on new ways to report progress (e.g., Burndown Charts)
+ Educate Compliance/Audit on difference/changes w/Agile
+ Ensure measurements reward the behavior that you want (How do we reward the new behavior?)
+ What does career development now look like?
+ Combine benefits of diverse methods: theory of constraints, lean & agile
+ Don’t measure individuals, measure teams and their success
+ You can’t really create an Agile standard for all teams to follow, just get started w/the basics and let the team determine for themselves what will work for them

Cliff Utstein (AccuRev): Automating Agile Software Development Processes
+ AccuRev – process driven SCM software
+ Product quality is fixed, business requirements persist (increase?), resources may be cut, little/no schedule relief
+ increase throughput by improving software development processes: automating & optimizing

Behrooz Zahiri (Coverity): Managing Software Quality in Agile Environments
+ The earlier you find a defect, the cheaper it is to fix
+ Cheapest to fix: in development; more expensive to fix: during integration; even more expensive to fix: during test; most expensive to fix: during production
+ Static Analysis – like a spell checker that finds your most difficult bugs
+ Coverity helps identify bugs for open source projects at, 11,303 defects have been fixed since March 2003
+ Coverity supports C, C#, C++ and Java

Martin Van Ryswyk (Electric Cloud): Making Agile Work
+ Continuous Integration = Agile; checkin & get instant feedback on integration problems
+ Fast builds (“espresso” builds), automated builds & test on-demand
+ Access for developers/QA/etc. to schedule builds, on-demand builds or stimulus builds
+ Auto build after code checkin to get fast feedback on build integrity/code quality
+ Include pre-flight tests to help reduce build failures

Alex Pukinskis (Rally): Case Study: Customizing Agile Tools for Project Success
+ Current fave book: The Principles of Product Development Flow: Second Generation Lean Product Development by Donald Reinertsen
+ Three meetings: daily scrum, scrum of scrums & regular retrospectives
+ New Rally build due out 12/19 will allow for setup of different types of dashboards built on roles (developer, manager & executive)
+ Remove obstacles for team members ASAP to limit overall delays
+ 100 day delay starts with multiple 8 hour delays

Additional notes from discussions:
+ Look into Bamboo to help with Continuous Integration/automated builds

UPDATE (7 Jan 2010 @ 12:32pm PST): I’ve added links to the presentation files.


Transitioning to Agile Product Development

Last week I attended a PDMA LA roundtable discussion on “Transitioning to Agile Product Development“. The discussion was moderated by a PDMA LA board member and featured the following panelists:

I was hoping to come away with some lessons learned and best practices on transitioning an organization to an Agile one, but the discussion ended up being more of an overview of Agile as many in attendance were unfamiliar with some of the basic concepts. I did manage to meet some interesting people and continue building my local Agile network, but not quite specifically what I was hoping to achieve, silver lining I suppose.

Regardless, the following are my notes from the event. Note that I’ve tried to note the panelists initials where I can attribute my note to them:

  • S.D. – continuous feedback from customers on demos; requirements flexible, time & resources/costs are fixed
  • Basic tenets outlined in Agile Manifesto
  • S.D. – 8hr workday creates a certain # of defects, 10hr workday creates 11x more defects than an 8hr one
  • Comment that Scrum helped elect recent governors of VA & NJ
  • The Standish Group found that 7% of features affect a customers buy/build decision, 13% will affect you vs. competitor decision, 64% no one cares about
  • S.G. – Contracts can be written w/Agile adjustments instead of hardcoding features/cost/date, Mary Poppendieck has some resources on this
    [Jeff Paul – here are some references I found: Agile Contracts by Mary & Tom Poppendieck, Agile Contracts pitch by Mary in 2005, Lean Contracts essay by Mary in 2002]
  • Should be constantly improving processes
  • Understand # hrs/resource & # hrs/sprint and estimate user stories better
  • Check out Reed Hasting’s presentation on Slideshare
  • Check out the Business Agility whitepaper on the site
  • Assume a single project team to get to Agile process & show benefits to help transition larger org
  • Get good coaching & training

I hope to attend more events in 2010 and will do my best to summarize them here… cheers!