Last night a new user group, AgileAustin kicked off its meeting schedule with a presentation by Jim Van Riper from Troux Technologies.  

Background on AgileAustin:  AgileAustin was formed by an idea from Kert Peterson and manifested by many others.  The mission of AgileAustin is:

. . . to promote agile software development concepts such as those set forth in the Agile Manifesto (agilemanifesto.org), to create a public forum for the exchange of practice information, and to create opportunities for the professional development of members.

The group meets on the 2nd Tuesday of every month at 6pm at the Microsoft office. 

Mr. Van Riper related how in 9 months Troux restructured its product department to turn a failing product into a wildly successful one.  he relates how Troux adopted Agile as a means to transform the product group.  They overlaid another level over the Agile Manifesto:

Culture encompassing (Individuals and interactions over processes and tools)
Vision encompassing (Working software over comprehensive documentation)
Customer commitment encompassing (Customer collaboration over contract negotiation)
Embracing failure encompassing (Responding to change over following a plan)

Mr. Van Riper’s goal is to work himself out of a job.  he contends that when there is a healthy culture, people can come and go, and the culture remains.  The culture at Troux had to change from top to bottom.  their Agile transformation affected the CEO all the way down to individual contributors. 

At Troux, Mr. Van Riper owns the backlog, owns the vision and owns the budget.  By that structure, the process is very streamlined.  The development team owns the software.  They own every aspect of it, and they focus on fast delivery of it.  It’s interesting to note that the company only has 14 developers, but they release every 3 months. 

Mr. Van Riper emphasized “knowing when to stop”.  Instead of adding every possible feature, Troux uses market judgement to know when enough is enough to put out a release. 

As part of the culture change that occurred at Troux, Jim aimed to “Squash passive aggressive behavior and bitching.”  Troux has a disciplined chain of command, and they realize that not everyone needs to be involved in every decision.  If someone doesn’t like the decision, they can escalate, but the buck stops at the CEO, where the chain of command stops.  No design by committee, but a clear chain of command.

The next section of the presentation really impressed me:  “Hire the best, fire the rest.”  All management was replaced in the process.  Mr. Van Riper contends that some aren’t good enough, and some choose not to adopt Agile, so others self-select to move on.  Some might interpret this to mean that to adopt Agile, all current people have to leave, but I contend that if the organization isn’t getting the job done, then a lot needs to change, including some of the people responsible for the failures.

Jim also touched on team workload.  he doesn’t want folks working more than 45 hours per week because if they are tired, he doesn’t want that code checked in.  The code likely won’t be good if written while the programmer is fatigued.  I have to reiterate that Jim is relating things that have turned Troux around into a success.  These things worked for his organization.  Jim enjoys the churn in the organization because it constantly brings a fresh perspective. 

As far as product strategy, Troux does NOT copy the market.  They focus on their users’ boss, not the user directly.  By doing this, they make the users more successful in the eyes of the bosses, not just themselves.

Troux breaks up work into “Must”, “Hope”, and “Wish”. 

• Must – will not ship without.
• Hope – might ship without.
• Wish – will ship without, but this needs to be kept in mind for future releases.

Jim recognizes that support and maintenance can sabotage projects.  Developers are routinely pulled off for support without adjusting the schedule for the project.  That just doesn’t make sense.  Bugs coming back from the fields are escalated up to the product owner so one person can assess each on relative to other potential work.  If bugs go into a release, other features must come out.  The plan has to be based on reality. 

Kill the product manager

It sounds crazy, but this is what Mr. Van Riper means:  In waterfall, Ghant charts are sacred, and Agile causes all practices to be rethought.  To some, throwing away the Ghant chart is heresy.  Jim relates that Ghant charts are produced along with Market requirements documents (MRDs) and that MRDs assume perfect knowledge, which is a fallacy.  MRDs are never always correct.  Rather, Troux makes product managers part of the Team, not separate from the team producing MRDs to be consumed by the team.  For those familiar with the Pigs and Chickens analogy, Troux makes product managers pigs instead of chickens.  This makes product managers completely committed and not just merely involved. 

“We need Product Management separate from Product Development for checks & balances.”  Mr. Van Riper scoffs at that notion and considers it dysfunctional.  Jim is the VP of Product, and everyone involved in a product release reports to him, product managers, software developers, and testers (with the help of line managers).

Jim equates lots of documentation as fear of failure.  “Henry Ford called failure an opportunity to begin again more intelligently.”  Troux prefers to get something working, share it, then fix it.

Gary, the Director of Development, capped off the presentation with an explanation of how development is organized to get stuff done.  Scott Bellware was more than happy to ask questions which enhanced the presentation and challenged the speaker.  We had a bit of difficulty defining an “ad hoc” process.  Gary  related taking the development organization from a waterfall process with sign-off gates to a successful Agile process which actually produced working software.  At first, everyone contended that if only waterfall was followed, the software would succeed.  In reality, the software was failing in many ways.  Individuals would try valiantly, but just work themselves to a pulp.  The company depended on heroism by individuals, not the coordinated work of a gelled team.   

Gary called out the importance of a cadence to the developers’ work.  Iteration by iteration, the group obtained a stride, and through it all, the team built trust.  Developers instilled discipline in themselves.  Through past experience, developers were asking permission to do things that were necessary like unit tests.  By pushing decisions down, developers decided how the work should be done – not management.  Then by planning capacity, Troux was able to plan based more on reality and have the developers empowered to execute with discipline. 

Tools:  Gary recommends not using any tools for the first six months in order to establish the desired values.  Then, tools can be adopted base on fit.  He’s referring to project management tools like Rally, Team System, etc.  Finally, Gary helped his developers change and on the other hand, insisted they do so.  Then, he got out of the way.  About practices, he contends that continuous integration is their most important practice and that their holy grail will be when the build doesn’t break any more.

Metrics:  Gary does track some metrics, but they are very high-level and posted publicly.  He only tracks burn-down  of an iteration as well as builds.  He doesn’t attempt to track everything because that’s not valuable.  By the amount of discussion surrounding metrics, it sounds like there are a lot of opinions. 

The first meeting of AgileAustin was a huge success with standing room only.  Visit AgileAustin.org if you are interested in the group, and join us for our next meeting on October 2nd.