jump to navigation

Agile Team Scaling August 15, 2006

Posted by newyorkscot in Agile.
trackback

Decent article here from Dr. Dobb’s Portal on how to scale agile projects.

In our experience, on a discrete project basis, a small team of senior engineers will generally always outperform larger “less senior” teams (depending on the success criteria of course!) especially when working with trading, pricing and risk management systems and their ever-changing needs. The real problem in scaling becomes evident when different groups need to integrate their part of an overall solution. In too many cases in Financial Services, each component of a Service Orientated Architecture for example, is so generic (ie not a fully encapsulated service) that is not actually that useful on its own. And end-to-end programs/workstreams that try to stitch these components together are incredibly guilty of taking the ‘command and control’ approach to planning, design and implementation. This forces any agile work down into the grass roots, and limits its adoption across an organization. It can also seriously hinders client-developer communication and feedback. Release planning and integration also become a nightmare and highly frustrating for the agile team (I assume non-agile teams are also frustrated but that is modus operandi).

I am glad to see Collaboration getting a good profile in the article, as it is absolutely paramount to successful agile development, let alone scaling it. We have had a lot of success both internally and with clients in using a wiki to provide complete transparency, continuous updates and real-time issue/risk management — but it is only one part of the solution. Executing larger scale projects needs a high degree of interaction and collaboration on a number of levels including client-driven planning, continuous communication & feedback, daily stand-ups (team and Meta flavours), and in-your-face planning & retrospectives. For distributed teams, even if the teams have actually successfuly worked together before, the initial planning (iteration zero?) phase MUST be physically done in person (a la Agile Modeling Driven Development, if need be) — to establish a real working relationship and sense of trust and understanding, especially for those darn conference calls you need to work your way through ….

Advertisements

Comments»

1. PM Hut - January 25, 2009

How do you usually coordinate communication between these teams, and what role takes the responsibility for this?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: