Business Agility, or how IT Should Inspire Business

This morning, I hit the road for a quick 20-minute ride to RTP (Research Triangle Park), to attend a workshop on business agility, organized by Eliassen Group.

Animated and moderated by Tom Wessel, the Agile coach and delivery lead at Eliassen Group, the panel was dynamic and humoristic. His fellow panelists included Josh Brose, VP in Workplace Investing at Fidelity Investments, Rick Cobb, the president and co-founder at AgileCraft, and Tom Mullen, Eliassen’s regional Agile delivery leader. We were hosted in Fidelity Investments’ campus on RTP (Durham, NC).

The discussions went around 3 key aspects: don’t think project, think product, agility is not only an IT “thing”, and teams.

During my past years, I never thought of a project as a project. Projects handled as products can be constructed in a much nicer and efficient way. I have covered some of that in a previous write up on product design. For me a product is a finite set, vs. a project, which is often non-finite – to avoid using infinite here. The smaller the product is, the better it is, you can then incrementally build on it, start showing it early to your customers and partners. This is exactly what Fidelity is now doing.

A lot of questions and comments were raised about applying agility in the rest of the businesses, including highly regulated businesses or highly process-oriented departments. As often, the answer is that they might not be a way to apply a full agile methodology for, let’s say, procurement, but lean and agile concepts can be applied to this department. As an example, Fidelity has lean methodologies for HR and finance.

Teams were a long discussion. Although a team is not exclusively agile (I worked in waterfall teams too), teams are a great components of agility. Ideally a team is “seven plus or minus two” according to Tom Wessel, which translates to 5 to 9 for the slow thinkers. Of course, you can multiple teams on a same project, but you should not go over 150 people, this is more a sociological aspect of human-beings than IT.

Teams should stay together between 6 to 12 iterations to assure maximum adherence to the principles of agility, so they live the same pain points of delivery, testing, producing, analyzing (no particular order) over and over. Time does not seem to affect the team cohesion: if your sprints are a month long, if will take 6 to 12 months, if they are every 2 weeks, it will take 12 to 24 weeks. You should avoid “breaking” teams before 6 months, as the “construction time” will always take these 6 to 12 iterations. It is important to measure the team performance as well as the individual performance, or as one can say, assess the performance of the individual in a team.

Scarce resources or shared resources (experts such as UX specialists, Big Data guru…) can be split among the teams, but typically not more than 4 teams at a given time.

Over time, predictability of the team is better than pure velocity. Automation will help increase the quality and velocity of the product you’re building, like automated testing and continuous integration.

I find it reassuring that methodologies like agility and their adaptations as we applied them in my GreenIvory days are hitting the enterprise, and not only through the IT department.