Through AgileAtlanta (stewarded by Andrew Fuqua) I got another opportunity to visit a company using Agile. This time it was VersionOne, makers of a popular Agile project management tool. (Disclaimer – I’m not recommending or suggesting anyone should use an Agile project management tool. I currently use VersionOne, but I’ve also used Rally, PivotalTracker, VSTS Scrum template, Scrum for Team System, a spreadsheet, a whiteboard, and index cards over the years. All work great in given contexts.)
When you first walk into the building you see a conference room and a couple of offices. Our guide, Steve Paro, was quick to point out that there are few offices (in fact I only saw 3) and almost everyone works in team areas. Marketing and Sales are off to the left in a rather cramped series of rooms with shared “open-plan” style workstations with large visible charts on various boards, walls and dividers that appeared to split the groups in somewhat meaningful ways. Steve let us know that while all groups use some form of agile to do their work Marketing’s is closest to “pure” Scrum.
The rumpus room is the main recreational area and doubles as the location for company meetings.
A backtrack and another left turn takes us to a walkway overlooking an unexpected large open area on the ground floor. We took the stairs down to the “rumpus room” (pictured at left) which is the main recreational area and also doubles as location for company meetings. (In my time there the pool and ping-pong tables saw heavy use, which led to a key takeaway about organization culture, but more on that later.) You can’t see it in the picture, but off to the left in a little corner is a working, full kegerator.
Just past this area is where the development work is done. The group is broken up into several teams, each focusing on an aspect of the product, like Core, Analytics, and APIs. Each team has an open style work area with pairing stations. All coding is done pair-programming style and each team has at least one pair with the largest having three pairs. As people are added or switched between teams it’s always two at a time. Which leads to the question of stable teams, which is a good agile practice that the company has been adamant about maintaining.
The development area features open-style work benches with pair programming stations.
But they’ve discovered over time that not having structure around how people move between teams was causing problems. Some people felt stuck on teams and it was hurting morale. In the current model, everyone moves to another team and everyone switches pairs on a set schedule. In this way, nobody feels stuck, but at the same time there’s not large upheaval that would hurt the ability of each team to keep its established cadence. The policy isn’t interesting so much as the process in this case. The key is they had an existing policy, they observed problems related to it, so they changed the policy, adapting it over time until they found something that worked. And that in turn may change as conditions change. Here’s a question to ask about your own organization – do employees have to adjust the way they want to work to adhere to policies or are policies created to help employees work the way they want?
Another relatively recent change at VersionOne (both in the company and in the product) is their adoption of the three-tiered scaled agile model that is becoming more and more popular for enterprise adoptions. There’s a Business team that is focused on new business goals and market strategies. There’s a Product, or Feature team that focuses on defining features that will meet those goals, and then there’s the development or Delivery team that does the work. In this case, the product owners of each team work together (in fact, in the picture to the right above, the prominent work area on the right is the Product Owner team), with input from the teams, on creating features and stories for the various project teams. And this collaboration appeared to be important – the term “three amigos” was used several times. Another way they enforce collaboration is through collective code ownership – anyone can edit anyone else’s code. Shared documentation is managed using a Confluence wiki and HipChat is the tool of choice for distributed chat communications.
A view of the status of stories being worked on.
Walking through the development area and to the left is an area dominated by a giant whiteboard that doubles as a touchscreen. This is where the teams have their standups and where stories and features are managed throughout the release cycles. VersionOne has quarterly release cycles, not because that’s the only time they have product ready to release, but rather because over time based on customer feedback, they’ve come to realize that enterprises can’t consume changes very quickly (which suggests an interesting question for another day). Steve described their development methodology as ‘Frankenagile.” It’s a sort of Scrumban with elements of eXtreme Programming and their own wrinkles. Their process is managed, in true dogfooding fashion, by the VersionOne tool (it turns out they use the same release as their customers, only updating shortly before actual release). Iterations are one week, but the work flow is much more Kanban-style in that the concern isn’t that all work is done in a given iteration but rather that a sustainable pace of completed work is maintained. The key metric here is stories completed. Based on this metric they can predict with reasonable certainty how much work they can complete within a given release cycle and thus what features should be slated for a given release.
This view shows the status of builds for each project team.
The teams have three sizes for stories – 1/2, 1 and 2 with the vast majority being 1 point stories. I asked, since there is great importance on uniform-sized stories in this model, how do the teams manage to create them independently? The answer is that they’ve just naturally come to that over time. They’ve been doing it for so long that they just seem to create right-sized stories organically without any specific rules or process (planning poker cards were abandoned long ago). They do have dedicated iterations for burning down technical debt which roughly works out to about 20% of the time for a given release. Additionally, some developers are assigned to handling support calls should they arise, this duty is also rotated over time.
Continuous integration is an important part of the process. They use Jenkins to manage the builds for each team, tracking both checkin and nightly test runs which comprise both unit, and acceptance tests. They are currently iterating through the use of cucumber to create scenario tests. Steve reports that they haven’t had much success at using the tests as “living documentation” but they have seen value in the collaboration it fosters in helping refine stories.
A screen showing the high-level features planned for the next release.
I asked about UI automation, and they do have some, but mostly used for high level scenario and process flow checks. After a recent STPCon, the lone dedicated tester of the group discovered the glories of Session-Based Testing. This method of managing Exploratory Testing is quickly being adopted by the teams.
Back in the rumpus room, Ian Culling took over and gave a short presentation describing the importance of culture in the organization. When they hire, they look for craftsmen, people that care deeply about the work they produce and are intrinsically motivated to “do the right thing.” He made comment here that resonated with me about Minimally Marketable Features (MMFs). He said they don’t equate to “just getting the job done,” they have to be right; these are features upon which your software is judged by users. It’s a key point about how sometimes commonly used terms can take the focus away from what really needs to be done.
Ian Culling talks about the importance of culture at VersionOne.
They also look for anti-establishment types that won’t be readily cowed by corporate edict. He told a great story about guerrilla coffee makers that I won’t repeat here, but suffice to say employees are empowered to change their environment, even if it involves company money, to make their work more effective. To judge whether an individual will fit well in the organization, a candidate actually works with the team for up to a day, and anyone on the team can veto the hire. Earlier I commented about the recreational equipment — if you have these things does anyone/everyone use them? If not, why not? Is it because they fear to use them because of judgement from management, or even other coworkers? If these questions make you the least bit defensive, you might have a culture issue.
Overall they strive to create a culture of reflection and experimentation. They of course encourage regular retrospectives on the teams, but also foster experimentation in other ways. One is by sponsoring a “hack week” where employees work on whatever they want. Some of the features in the product, including the new “Team Room” feature, are a direct result of this initiative. They also have a Makerbot.
Manage to Test 