Date: 10/6/2009
Time: 6:00pm - 9:00pm
Location: Microsoft Technology Center; Stonebridge Plaza One; 9606 North Mopac, Suite 200, Austin TX, 78759
Speaker: Borland Panel
Title: Borland’s 2 Years in Austin: A Story of an Agile Journey
Description: In April 2007, Borland moved its headquarters from Cupertino, CA to Austin, TX. More than just changing its address, Borland was transforming its own engineering. Borland consolidated engineering locations, changed product focus, and adopted Agile. Two years later, Micro Focusacquired Borland and all but closed the Austin offices. In a rare opportunity to tell a start-to-finish story about Agile adoption, a panel of ex-Borland employees will present an experience report and share some of the lessons learned.
Panel Bios:
· Ian Buchanan - formerly Borland Director of Product Management
· Michael Maham - formerly Borland ScrumMaster and Product Manager (including CMMI assessments)
· Marilyn Rogers - formerly Borland Principal Information Developer
· Dale Schumacher - formerly Borland Agile Evangelist, VP of Agile Austin
· Stan Taylor - formerly Borland QA Architect
Cost: Free
More Info: www.AgileAustin.orgor info@AgileAustin.org
This group from Borland had been working on a suite of Agile tools under the heading ALM – Application Lifecycle Methodology/Management.
While Borland blended all functional disciplines into their Agile team almost identical to how ASI has done, they kept enterprise-level software testing (testing for performance, localization, etc.) centralized to a group in Singapore. This approach already had a variety of problems, not the least of which was the 12 hour time difference. It did not improve under Agile. It was unclear if this group was an outside vendor or an independent group within Borland. The manager of this group was the sole point of interaction with the teams sending work to be tested. Occasional face to face meetings had a strong impact on improving this relationship.
Borland’s Quattro Pro team was doing daily stand-ups decades ago. They were Ken Schwaber’s inspiration for adding this to scrum practices.
Michael Maham, who was a dedicated ScrumMaster in Borland was also in charge of their CMMI efforts. His belief is that an organization can be Agile and disciplined (a la CMMI) at the same time. He points to the work of Hillel Galzer on this. Glazer’s blog on this is located here: http://www.Agilecmmi.com/
Borland created what they called a “mini-spec” on day one of the Sprint or sometimes at the end of the previous Sprint. The “mini-spec” was based on the user story. It included the documentation and acceptance criteria for the story. The “mini-spec” was an elaboration of the user story based on a record of conversation about the story. It often started with just the names of the test cases or acceptance criteria as the outline.
Borland had a sole UI architect who supported 2-3 teams.
Their typical ratio on teams was 4-7 DEV : 2 QA : 1 ID.
ID people did testing too.
Story’s were functionally complete at the end of Sprint N and enterprise tested by Sprint N+1.
Borland used “light house customers” to do preproduction testing of the output of each enterprise tested Sprint. They had strict agreement that this work could only be in test environments and not production.
Borland accounted for rework (Bugs and SMRs) by each team with a time-boxed constant 10-20% of capacity per Sprint.
Release to production always involved a “hardening “Sprint with enterprise testing and localization lagging by 1 Sprint. Borland used 6-month release cycles with a 1-Sprint iteration of “release activity” for finalization of all the docs, etc. from the previous Sprint for that release.
Borland did not track quality metrics and they did not have a productivity measure to offer. These were based on “feel” more than quantitative numbers.
PM/PO groomed the defect Product Backlog along with recognition and honest admission to customers that some bugs would simply never be fixed. The example given, though possibly exaggerated, was if we have 4000 bugs on the Product Backlog and yours is # 3000 in priority, face it – it will never get fixed therefore we are going to close it. They saw this as being honest with their customers and themselves. However, they did not distinguish issues that were close this way from those that were fixed, so their fix count was skewed.
Defects on stories still in development vs. those from release work were tracked separately.
Borland did maintenance on the released branch simultaneously with a branch for new development.
They felt that Agile explains the importance of improving knowledge, but that it relies too much on tribal knowledge at the expense of training. The mini-specs were the main source of tribal education for those rotating onto a different team.
Borland found it was necessary to treat “fixes” identified from retrospectives as user stories in the next Sprint or they usually didn’t get addressed. This only works if the PO buys into it too.
Borland did struggle with how to continue to train and learn, even about Agile, in face of the drive to create product value. They tried allocating weekly time and let the teams pick and chose for themselves, but it didn’t work.
Big name Agile consultants including the Poppendiecks (Tom & Mary), Mountain Goat Software, David Anderson, etc. were brought in to coach executive management and other non-practicing areas of the company, i.e. marketing, after the fact. They were brought in by marketing to push the idea that Borland was an Agile “victory”. The problem this created was that they thought there was nothing more to learn or improve on about Agile, i.e. the destination had been reached.
Borland recommended reading Alistair Cockburn’s work on communication vs. proximity.
· Agile Software Development: The Cooperative Game
· Writing Effective Use Cases
· Crystal Clear: A Human-Powered Methodology for Small Teams
· Agile Software Development
· Surviving Object-Oriented Projects
Borland’s original office in Austin had cubes and meeting rooms. Their new space had dedicated team rooms. This improved communication with the teams, but caused a reduction of communication between teams. However, they pointed out that in the original cube space, they started off more or less close to their teammates but as people left or rotated and new hires came in, teams got scrambled. I talked with them afterwards and they had no idea about most of the communications tools we already use.
Borland found it important to acculturate new hires through continuous learning and integration. New hires documented their on-boarding experience for the next new hire.
After the point of declared Agile-victory, executive management decided to reassign the dedicated ScrumMasters and make the development managers the ScrumMasters. This turned out to be a big mistake.
Borland management did not see Agile as the continuous journey of improvement that it is.
The panel reiterated that emphasis on story delivery cannot be allowed to crowd out training and process improvement.
Borland’s dedicated SM’s covered multiple teams each. They stressed that the role of SM is informational and not authoritative. They experienced that SMs who are not supervisors of team members worked much better and that managers as ScrumMasters is a conflict of interest.
Borland didn’t use the Agile and ALM tools they built enough to experience the issues their customer did. Their interests were not the same as their customers.
Non-Agile customers (or at least ones who didn’t understand the concepts behind Agile) pulled the team into non-virtuous cycles of narrow, self-serving changes that added minimal value to the product overall, rather it address only their own needs. Also, some customers wanted zero patches and only annual releases.
Borland like ASI had Product Management and Product (Marketing) Management as separate roles. The PO’s that were with the teams were PM’s no BA’s. Each PM was the owner of a full product. Borland apparently didn’t operate PM as a Product Owner Team because they mentioned several times about how uncoordinated the efforts across the various products were. This was especially bad since several of the products were sold and/or packaged together as an interoperable suite.
When Borland reorganized for Agile teams, some PM functions feel into black holes, but have been filled or reassigned. Eventually, they things were improved in PM when Product Managers were explicitly paired with Product Marketing Managers.
As for whether or not they considered Agile a success or failure, the Borland panel said that as Agile adoption increased, everyone was happier. Therefore, it was successful as an improvement effort up to the point that Agile-victory was declared after which there was no more effort to improve process.
Borland never had a quantitative measure for productivity. They said it was measured only by “feel” of management and the Agile teams.
Several excellent recommendations came from Borland folks after the main meeting during open space breakout sessions:
1. Have customers send their acceptance test cases to you. These would be what the customer verifies on the typical update or new release on their production machines before the move it to their production machines. Then create stories to add these as automated tests for continuous integration.
2. ScrumMasters had regular meetings to share what they were doing with each of their teams that did and didn’t work.
3. Have occasional cross-over meetings between pairs of teams to share information on what they are doing and what is and isn’t working. These were cross functional meetings as opposed to functional meetings that can be used for similar purposes with a more narrow focus.
Next meeting: November 3rd – Topic: Exploring the nuts and bolts of Domain Drive Design.