Agility@Scale: Strategies for Scaling Agile Software Development
Timo Tenhunen has recently published his master's thesis, Challenges in Scaling Agile Software Development , and has been kind enough to make it available online. I suspect you'll find it to be an interesting read.
One of the scaling factors called out in the Software Development Context Framework is “geographic distribution". As with the other scaling factors the level of geographic distribution is a range, with co-located teams at one extreme and far-located at the other. When your team is co-located the developers and the primary stakeholders are all situated in the same work room. If you have some team members in cubicles or in separate offices then you're slightly distributed, if you're working on different floors in the same building you're a bit more distributed, if you're working in different buildings within the same geographic area (perhaps your team is spread across different office buildings in the same city or some people work from home some days) then your team is more distributed, if people are working in different cities in the same country you're more distributed, and finally if people are working in different cities around the globe you're even more distributed (I call this far located).
As you would imagine, because the project risk increases the more distributed your team is, the lower the average success rates of agile projects decrease as they become more distributed. The 2008 IT Project Success Survey found that co-located agile teams has an average success rate of 79%, that near located teams (members were in same geographic area) had a success rate of 73%, and that far-located agile teams had a success rate of 55%. The success rate decreases similarly for project teams following other paradigms.
The bottom line is that some organizations, including IBM, have been very successful applying agile techniques on geographically distributed teams. In fact, agile GDD is far more common than mainstream agile discussion seem to let on.
ScottAmbler 120000HESD Tags:  enterprise-discipline enterprise-architecture agility-at-scale agile asm 19,368 Views
People who are new to agile are often confused about how agile teams address architecture, but luckily we're seeing more discussion around agile architecture now in the community so this problem is slowly being addressed from what I can tell. But, what I'm not seeing enough discussion about, at least not yet, is how is enterprise architecture addressed in the overall agile ecosystem. So I thought I'd share some thoughts on the subject, based on both my experiences over the years (see the recommended resources at the bottom of this posting) as well as on an enterprise architecture survey which I ran in January/February 2010.
My belief is that effective enterprise architecture, particularly in an agile environment, is:
The Agile Scaling Model (ASM) calls out addressing enterprise disciplines, such as enterprise architecture, as one of eight scaling factors which may apply to a given project. The interesting thing about this scaling factor is that it's the only one where things get potentially easier for development teams when we move from the simple approach, having a project focus, to the more complex approach, where we have an enterprise focus. By having a common infrastructure to build to, common guidelines to follow, and valuable artifacts to reuse project teams can benefit greatly. So, I guess my advice is to seriously consider adding enterprise disciplines to your agile strategy.
ScottAmbler 120000HESD Tags:  agile-scaling-model agileexec agility-at-scale whitepaper asm agile 10,791 Views
My new paper Scaling Agile: An Executive Guide is now available. As the title suggests the paper overviews how to scale agile strategies to meet your organization's unique needs.
The executive summary:
Agile software development is a highly collaborative, quality-focused approach to software and systems delivery, which emphasizes potentially shippable working solutions produced at regular intervals for review and course correction. Built upon the shoulders of iterative development techniques, and standing in stark contrast to traditional serial or sequential software engineering methods, agile software delivery techniques hold such promise that IBM has begun to adopt agile processes throughout its Software Group, an organization with over 25,000 developers. But how can practices originally designed for small teams (10-12) be “scaled up” for significantly larger operations? The answer is what IBM calls “agility@scale.”
There are two primary aspects of scaling agile techniques that you need to consider. First is scaling agile techniques at the project level to address the unique challenges individual project teams face. This is the focus of the Agile Scaling Model (ASM). Second is scaling your agile strategy across your entire IT department, as appropriate. It is fairly straightforward to apply agile on a handful of projects, but it can be very difficult to evolve your organizational culture and structure to fully adopt the agile way of working.
The Agile Scaling Model (ASM) defines a roadmap for effective adoption and tailoring of agile strategies to meet the unique challenges faced by a software and systems delivery team. Teams must first adopt a disciplined delivery lifecycle that scales mainstream agile construction techniques to address the full delivery process, from project initiation to deployment into production. Then teams must determine which agile scaling factors – team size, geographical distribution, regulatory compliance, domain complexity, organizational distribution, technical complexity, organizational complexity, or enterprise discipline, if any — are applicable to a project team and then tailor their adopted strategies accordingly to address their specific range of complexities.
When scaling agile strategies across your entire IT organization you must effectively address five strategic categories — the Five Ps of IT: People, principles, practices, process, and products (i.e., technology and tooling). Depending on your organizational environment the level of focus on each area will vary. What we are finding within many organizations, including IBM, is that the primary gating factor for scaling agile across your entire organization is your organization’s ability to absorb change.
ScottAmbler 120000HESD Tags:  agileadopt disciplined-agile-deliver... agility-at-scale agile solution 22,366 Views
An imporant step in scaling your agile strategy is to adopt a Disciplined Agile Delivery (DAD) approach instead of one which is just focused on agile construction. One aspect of adopting a DAD approach it to mature your focus from just producing software to instead providing a solution which meets the needs of its stakeholders within the appropriate economic, cultural, and technical constraints. The fundamental observation is that as IT professionals we do far more than just develop software. Yes, this is clearly important, but in addressing the needs of our stakeholders we will often:
Although delivery of high-quality, working software is important it is even more important that we deliver high-quality working solutions to our stakeholders. Minimally IT professionals should have the skills and desire to produce good software, but what they really need are the skills and desire to provide good solutions. We need strong technical skills, but we also need strong "soft skills" such as user interface design and process design to name just two.
The shift to a solution-oriented focus from a software-oriented focus requires your agile teams to address some of the software-oriented prejudices which crept into the Agile Manifesto. The people who wrote the manifesto (which I fully endorse) were for the most part software developers, consultants, and in many cases both. It is little wonder that this group would allow a bias towards software development creep into the language of their manifesto.
Agile requirements activities are evolutionary (iterative and incremental) and highly collaborative in nature. Initially requirements are explored at a high level via requirements envisioning at the beginning of the project and the details are explored on a just-in-time (JIT) basis via iteration modeling and model storming activities. The way that you perform these agile practices, and the extent to which you do so, depends on the situation in which a project team finds itself. The Agile Scaling Model (ASM) is a contextual framework for effective adoption and tailoring of agile practices to meet the unique challenges faced by a system delivery team of any size. To see how this works, let's apply the concepts of the ASM to see how we would scale our agile approach to requirements.
First, let's consider how a small, co-located team would work. The first two categories of the ASM are core agile development and disciplined agile delivery, the focus of both are small co-located teams in a fairly straightforward situation. In these situations simple techniques such as user stories written on index cards and sketches on whiteboards work very well, so the best advice that I can give is to stick with them. Some teams will take a test-driven development (TDD) approach where they capture their requirements and design in the form of executable specifications, although this sort of strategy isn't as common as it should be (yet!), likely because of the greater skill and discipline that it requires. Traditionalists often balk at this approach, believing that they need to document the requirements in some manner. But, for a small co-located team working in a collaborative manner, requirements documentation proves to be little more than busy work, often doing nothing more than justifying the existence of a business analyst who hasn't made the jump to agile yet. Don't get me wrong, there are good reasons to write some requirements documentation, and we'll see this in a minute, but you should always question any request for written specifications and try to find more effective ways to address the actual goal(s) motivating the request. Never forget that written documentation is the least effective communication option available to you.
Although inclusive tools such as whiteboards and paper work well for requirements, for development activities you will need electronic tools. You will either put together an environment from point-specific tools or adopt something more sophisticated such as IBM Rational Team Concert (RTC) which is already fully integrated and instrumented. RTC is a commercial tool, but luckily you can download a 10-license environment free of charge, which is just perfect for a small team. Larger teams, of course, will need to purchase licenses. One of the things that a disciplined agile delivery approach adds to core agile development is it addresses the full delivery life cycle, which is important because it explicitly includes pre-construction activities such as requirements envisioning. The first step in scaling agile techniques is to adopt a full delivery life cycle which covers the full range of activities required to initiate a project, produce the solution, and then release to solution to your end users.
More interesting is the third category of the ASM, Agility@Scale, and how its eight agile scaling factors affect the way that you tailor your process and tooling strategy. Let's explore how each one could potentially affect your agile requirements strategy:
ScottAmbler 120000HESD Tags:  scaling-agile sdcf teams distributed governance amdd gdd agility-at-scale 13,760 Views
In my previous blog posting, http://www.ibm.com/developerworks/blogs/page/ambler?entry=strategies_for_distributed_agile_teams , I overviewed several strategies for improving your effectiveness at geographically distributed development (GDD). Those strategies were fairly generic and directly applicable to both traditional and agile development teams. In this posting I focus on strategies which are more agile in nature, although they could also be applied to more traditional approaches as well. These strategies are:Modified on by ScottAmbler
1. Get the whole team together at the beginning of the project. Your goals are to build rapport amongst the team, to get to know the people that you’re working with to facilitate communication later on, and to better understand the situation on the ground. The implication is that you will need to fly some people around, increasing your initial expenses, an investment that many organizations balk at. The reality is that you will eventually end up paying for travel anyway, either because you actually flew people around or because your communication costs are higher throughout the project. In short, don’t be penny wise and pound foolish.
2. Organize your team around the system architecture. The most effective way to organize a distributed team is around the architecture of the system that you are building, not around the job functions of the people involved. In other words, if your team is in Toronto, Rome, and Bangalore then each subteam should be responsible for one or more subsystems. It would be a mistake to organize the teams around job function, for example to have the architects and analysts in Toronto, the developers in Rome, and the testers in Bangalore because this structure would require significantly more documentation and other forms of communication to coordinate the teams, increasing both cost and risk. As I mentioned in my previous blog posting you will need to invest in some initial architecture envisioning at the beginning of a project to identify the subsystems and their public interfaces, and that to do that you’ll also need to do some initial requirements envisioning to drive this architecture effort. I suggest that you take an Agile Model Driven Development (AMDD) approach to this to enable you to gain the value from modeling without the costs and risks associated with up-front comprehensive modeling and documentation that get many traditional project teams in trouble.
3. Have “daily stand-up meetings”. A common practice on co-located agile teams is to have daily stand-up meetings where people share the status of what they did yesterday, what they intend to do today, and whether they’re running into any problems. These short meetings enable team coordination. Distributed teams can do this as well, the people in a given geographical location can hold local stand-up meetings and then representatives from each location can hold a shared meeting to coordinate the subteams. Whereas local stand-up meetings are held first thing in the morning, distributed daily stand-up meetings may need to be held at unusual times so as to include people at distant locations.
4. Have Ambassadors. Ambassadors are people who travel between sites, often technically senior people or senior business experts, to share information between the subteams. Getting the team together at the beginning of the project sets the foundation for communication, but without continual investment in maintaining effective collaboration between teams you run the risk of your subteams deviating from the overall strategy. These are typically short engagements, a week or two in length, because of the pressures it puts on the people doing the actual traveling. The implication is that you’ll have several people flying between sites at any given time on a reasonable rotation schedule. Because you’ll have some people flying around, your local team rooms should accommodate visitors by having one or more desks available for them to use when they’re visiting.
5. Have Boundary Spanners. A boundary spanner is someone who is located on site who focuses on enabling communication between subteams as well as within their subteam. On large distributed teams you’ll find that you have three flavors of boundary spanners – team leaders who take on project management responsibilities on the subteam, product owners who are responsible for representing the business within the subteam, and architecture owners responsible for technical direction on the team. These boundary spanners will work closely with their peers, having regular coordination meetings across all subteams as well as impromptu one-on-one meetings to deal with specific issues between individual subteams.
6. Ensure that the global team gets the credit it deserves. In both offshoring and nearshoring environments it’s common to see small teams in North America or Europe driving the efforts of significantly larger teams in another country. Yet, at the end of the project it always seems as if the smaller team, often because they work for the direct customer, gets the lion’s share of the credit – unless of course the project failed, then the subcontracting team often seems to get virtually all of the “credit”. This clearly isn’t fair, and it clearly doesn’t promote effective teamwork between the subteams in the future.
7. Take a lean approach to development governance. As I’ve written in the past, effective governance is based on enablement and collaboration instead of the traditional approaches of management and control. Good governance measures progress through regular delivery of working software, not through status reports or delivery of detailed specifications. Good governance is based on the idea of having a living process which changes to reflect lessons learned as your project progresses. In a previous blog posting at http://www.ibm.com/developerworks/blogs/page/ambler?entry=lean_development_governance I’ve discussed lean development governance in greater detail.
The strategies that I’ve described are clearly nothing more than common sense, something that can be said of all agile strategies. Sadly, as Mark Twain lamented, common sense isn’t very common in practice.[Read More]