IBM Rational recently published an update to my Agility@Scale e-book, which can be downloaded free of charge. The e-book is a 21 page, 2.3 meg PDF (sorry about the size, guess the graphics did it) . It overviews the Agile Scaling Model (ASM) (which has since been replaced by the Software Development Context Framework (SDCF) ), Disciplined Agile Delivery (DAD), the scaling factors of agility at scale, and ends with some advice for becoming as agile as you can be. In short it's a light-weight coverage of some of the things I've been writing about in this blog the past couple of years. Could be a good thing to share with the decision makers in your organization if they're considering adoption agile strategies.
Agility@Scale: Strategies for Scaling Agile Software Development
ScottAmbler 120000HESD Tags:  agility-at-scale disciplined-agile-deliver... agile e-book sdcf 12,046 Views
ScottAmbler 120000HESD Tags:  agileadopt disciplined-agile-deliver... training 1 Comment 10,976 Views
I'm happy to announce that IBM Rational's RP252 Advanced Disciplined Agile Delivery (DAD) workshop is now available. This is a 3-day, hands-on workshop which teaches students the fundamentals of Disciplined Agile Delivery (DAD). This workshop is offered both publicly and privately.
ScottAmbler 120000HESD Tags:  agile enterprise-agile disciplined-agile-deliver... 3 Comments 10,812 Views
A fair question to ask is why should your organization consider adopting the Disciplined Agile Delivery (DAD) process framework. I believe that there are several clear benefits to doing so:
In short, DAD provides a lot of proven advice culled from years of experience applying agile software techniques in enterprise-class environments. Instead of figuring all of this stuff out on your own, why not jump ahead and leverage the hard-won lessons learned from other organizations that have already dealt with the challenges that you're struggling with today?
The primary shortcoming of the DAD framework is it makes it very clear that software development, oops I mean solution delivery, is quite complex in practice. As IT practitioners we inherently know this, but it seems that we need to be reminded of this fact every so often. DAD doesn't provide a simplistic, feel-good strategy that you can learn in a few hours of training. Instead it defines a coherent, tailorable strategy that reflects the realities of enterprise IT.
There is a wealth of information at DAD posted at the Disciplined Agile Delivery (DAD) web site and great discussions occuring on the DAD LinkedIn discussion forum. For those of you interested in agile certification, the Disciplined Agile Consortium site will prove valuable too, in particular the list of upcoming DAD workshops provided by several IBM partners. And of course the book Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise (IBM Press, 2012) written by Mark Lines and myself is a very good read.
ScottAmbler 120000HESD Tags:  metrics enterprise-agile governance disciplined-agile-deliver... 9,971 Views
Recently I have been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common. In order to get properly account for the costs incurred by software development teams you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn't have to be complex: at one customer developers spend less than five minutes a week capturing such information.
Why is Time Tracking Potentially Valuable?
There are several financial issues to be aware of:
The point is that the way that a software developer's work is accounted for can have a non-trivial impact upon your organization's financial position.
What Do Agilists Think of Time Tracking?
So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) to choose from:
The poll results reveal that we have a long way to go. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity that a developer performs in a given week.
The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:
I think that there are several interesting implications from this discussion:
Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that many agile developers believe that an activity such as time tracking is a waste when that clearly doesn't have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.
Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more. But you know what? Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).
ScottAmbler 120000HESD Tags:  disciplined-agile-deliver... spi agileadopt criteria governance 5 Comments 9,414 Views
Although it might not be obvious, and important success factor in adopting agile techniques is to be able to determine whether a team is agile or not. The challenge that many organizations face is that many teams will claim to be agile, yet management, who often has little or no experience with agile approaches, cannot tell which claims are true and which are over zealous (I'm being polite). The following are the criteria that I suggest you look for in a disciplined agile team:1. Produce working software on a regular basis. This is one of the 12 principles behind the Agile Manifesto, and in my experience is a critical differentiator between the teams that are agile and those that are merely claiming it. Ideally the team should produce potentially shippable software each iteration. That doesn't mean that they'll deploy the system into production, or the marketplace, each iteration but they could if required to do so. Typically the team will deploy into a pre-production testing environment or a demo enviroment at the end of each iteration (or more often for that matter).2. Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach. Agile developers test their work to the best of their ability, minimally doing developer regression testing via a continuous integration (CI) strategy and better yet do developer-level TDD. This approach enables development teams to find defects early, thereby reducing the average cost of addressing the defects, it also helps them to deliver higher quality code and to move forward safely when adding or changing functionality.3. Work closely with their stakeholders, ideally on a daily basis. A common practice of agile teams is to have an on-site customer or product owner who prioritizes requirements and provides information on a timely manner to the team. Disciplined agile teams take it one step further and follow the practice active stakeholder participation where the stakeholders get actively involved with modeling and sometimes even development.4. Are self-organizing within a governance framework. Agile teams are self-organizing, which means that the people doing the work determines how the work will be done, they're not told by a manager who may not even be directly involved with the work how it will be done. In other words the team does its own planning, including scheduling and estimation. Disciplined agile teams are self governing within an effective governance framework.5. Regularly reflect on how they work together and then act to improve on their findings. Most agile teams hold a short meeting at the end of each iteration to reflect upon how well things are working and how they could potentially improve the way that they are working together. Sometimes this is done in a more formalized manner in the form of a retrospective, but often it's done informally. The team then acts on one or more of their suggested improvements the next iteration. Disciplined agile teams take this one step further and measure their software process improvement (SPI) progress over time: the act of taking these measures, perhaps via a product such as Rational Self Check, helps to keep the team on track in their SPI efforts.
I have yet to discover an ad-hoc development team which met all five criteria, and most of them rarely meet two or three.
ScottAmbler 120000HESD Tags:  disciplined-agile-deliver... agileexec agile agility-at-scale risk rup phases governance 6 Comments 9,352 Views
The explicit phases of the Unified Process -- Inception, Elaboration, Construction, and Transition -- and their milestones are important strategies for scaling agile software development to meet the real-world needs of modern organizations. Yes, I realize that this is heresy for hard-core agilists who can expound upon the evils of serial development, yet these very same people also take a phased approach to development although are loathe to admit it. The issue is that the UP phases are like seasons of a project: although you'll do the same types of activities all throughout a project, the extent to which you do them and the way in which you do them change depending on your goals. For example, at the beginning of a development project if you want to be effective you need to do basic things like identify the scope of the project, identify a viable architecture strategy, start putting together your team, and obtain support for the project. Towards the end of a project your focus is on the activities surrounding the deployment of your system into production, including end-of-lifecycle testing efforts, training, cleaning up of documentation, piloting the system with a subset of users, and so on. In between you focus on building the system, including analysis, design, testing, and coding of it. Your project clearly progresses through different phases, or call them seasons if the term phase doesn't suit you, whether your team is agile or not.
The UP defines four phases, each of which address a different kind of risk:1. Inception. This phase focuses on addressing business risk by having you drive to scope concurrence amongst your stakeholders. Most projects have a wide range of stakeholdres, and if they don't agree to the scope of the project and recognize that others have conflicting or higher priority needs you project risks getting mired in political infighting. In the Eclipse Way this is called the "Warm Up" iteration and in other agile processes "Iteration 0".2. Elaboration. The goal of this phase is to address technical risk by proving the architecture through code. You do this by building and end-to-end skeleton of your system which implements the highest-risk requirements. Some people will say that this approach isn't agile, that your stakeholders should by the only ones to prioritize requirements. Yes, I agree with that, but I also recognize that there are a wide range of stakeholders, including operations people and enterprise architects who are interested in the technical viability of your approach. I've also noticed that the high-risk requirements are often the high-business-value ones anyway, so you usually need to do very little reorganization of your requirements stack.3. Construction. This phase focuses on implementation risk, addressing it through the creation of working software each iteration. This phase is where you put the flesh onto the skeleton.4. Transition. The goal of this phase is to address deployment risk. There is usually a lot more to deploying software than simply copying a few files onto a server, as I indicated above. Deployment is often a complex and difficult task, one which you often need good guidance to succeed at.
Each phase ends with a milestone review, which could be as simple as a short meeting, where you meet with prime stakeholders who will make a "go/no-go" decision regarding your project. They should consider whether the project still makes sense, perhaps the situation has changed, and that you're addressing the project risks appropriately. This is important for "agile in the small" but also for "agile in the large" because at scale your risks are often much greater. Your prime stakeholders should also verify that you have in fact met the criteria for exiting the phase. For example, if you don't have an end-to-end working skeleton of your system then you're not ready to enter the Construction phase. Holding these sorts of milestone reviews improves your IT governance efforts by giving senior management valuable visibility at the level that they actually need: when you have dozens or hundreds of projects underway, you can't attend all of the daily stand up meetings of each team, nor do you even want to read summary status reports.
These milestone reviews enable you to lower project risk. Last Autumn I ran a survey via Dr. Dobb's Journal (www.ddj.com) which explore how people actually define success for IT projects and how successful we really were. We found that when people define success in their own terms that Agile has a 71% success rate compared with 63% for traditional approaches. Although it's nice to that Agile appears to be lower risk than traditional approaches, a 71% success rate still implies a 29% failure rate. The point is that it behooves us to actively monitor development projects to determine if they're on track, and if not either help them to get back on track or cancel them as soon as we possibly can. Hence the importance of occasional milestone reviews where you make go/no-go decisions. If you're interested in the details behind the project, they can be found at http://www.ambysoft.com/surveys/success2007.html .
Done right, phases are critical to your project success, particularly at scale. Yes, the traditional community seems to have gone overboard with phase-based approaches, but that doesn't mean that we need to make the same mistakes. Let's keep the benefit without the cost of needless bureaucracy.[Read More]
A recurring discussion that I have with experienced agile developers is what it means to take a disciplined agile approach. The conversation usually starts off by some saying "but it already requires discipline to do agile", something that I fully agree with, followed by "therefore 'disciplined agile' is merely a marketing term", something which I don't agree with. The challenge with the "standard" agile discipline is that it is often focused on construction activities within a single project team, clearly important but also clearly not the full picture. There's more to an agile project than construction, and there's more to most IT departments than a single development project. In short, there are many opportunities for IT professionals to up their discipline, and thereby up their effectiveness, opportunities which we make explicit in the Disciplined Agile Delivery (DAD) framework.
Let's explore the many aspects to taking a disciplined agile approach:
Material for this blog posting was adapted from Chapter 21 of Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise, published by IBM Press in June 2012.
ScottAmbler 120000HESD Tags:  agility-at-scale agileadopt architecture reuse disciplined-agile-deliver... soa 2 Comments 8,555 Views
A common question that I keep running into with customers is whether you can take an agile approach to service oriented architecture (SOA). The quick answer is yes, because Agile is orthogonal to the implementation technologies used. You can take an agile approach developing COBOL applications running on mainframes, fat-client Java applications, multi-tier J2EE applications, and yes, even services. Granted, it's easier to do with some technologies than others, either because of the nature of the technology or because of the supporting tools.
The long answer is "yes, but". You don't adopt an SOA approach for the sheer joy of doing so, instead you very likely want to improve the level of reuse within your organization. To succeed at SOA-driven reuse you need an enterprise focus, something that doesn't appear to be very common on many agile teams. Therein lies the challenge. Several strategies for improving your chances with Agile SOA, and SOA in general, follows:1. Invest in some initial enterprise architecture modeling. You don't need to identify all of the details up front, that would take too long and actually put the effort at risk, but you do need to set a starting point to guide development teams. Identifying the technical architecture is critical, and identifying a few basic services which would provide immediate business value to one or more teams is critical. Involve people from several application project teams to ensure that you get a wide range of input. See http://www.agiledata.org/essays/enterpriseArchitecture.html for a streamlined approach to enterprise architecture modeling. Creating big, detailed models often proves to be a waste of time because development teams are rarely motivated to read mounds of documentation.2. Build out the initial infrastructure on a real application development project. This proves that your SOA strategy actually works and puts the technical foundation in place for future teams. During this period you'll be tempted to try to support several development teams, which is feasible but dramatically increases your risk. It's also tempting to focus simply on getting the infrastructure in place without delivering any business functionality, but this risks producing an ivory-tower architecture that nobody is interested in.3. Spread the service architects out onto application development teams. The people that formulated and then proved your SOA should be actively involved on the development teams that are working with it to ensure that the teams use it appropriately and to ensure that the architects get concrete feedback which they can use to evolve the architecture. When working on agile teams, these people will need to work in a collaborative and evolutionary approach just like other team members.4. Fund reuse separately. I've lost track of the number of organizations that I've run into that fail at reuse because their development teams never have the resources to develop reusable assets. That's simply the nature of the beast -- project teams will always be more interested in addressing their own specific requirements than they are in investing the time and effort to make something reusable. The real problem here is that you expect them to act differently. A better strategy is to have a separate reuse engineering team that has the resources to monitor existing projects to look for potentially reusable assets. When they find said assets this team does the work to harvest the asset, to reengineer it to make it reusable, and then to integrate back into the original source project. The goal is to make it as painless as possible to produce reusable assets such as services. If you expect project teams to do this work out of the goodness of their hearts then you're effectively punishing them when they do the right thing. That's not a very good governance strategy, IMHO.5. The reuse team now owns the asset. Any reusable asset, including services, will need to be maintained, evolved over time, and supported. This isn't free nor is it viable for project teams to do so.
If you're interested, I provide agile strategies for both enterprise architecture and strategic reuse in the book "Enterprise Unified Process". Although written under the assumption that you're taking a RUP-based approach to development, the reality is that the EUP can extend any evolutionary/agile software development process so that it addresses the larger-scale needs of modern IT organizations.
- Scott[Read More]
When adopting agile software development techniques across a large number of teams within your organization it is important to provide a definition for what agile software development is, in addition to criteria for what it means to be agile. Many people will point to the four values of the Agile Manifesto and claim that's a good definition. Well... it might be a good definition for the visionaries and early adopters among us, but for people on the right-hand side of the technology adoption chasm (the early majority, late majority and the laggards) this isn't enough. Don't get me wrong, I'm a firm believer in the agile values but I like to cast them as philosophies instead of as a definition.
At IBM Software Group, the definition of disciplined agile software delivery which we have been sharing with our customers is:Disciplined agile software delivery is an evolutionary (iterative and incremental) approach to delivery which regularly produces high quality software in a cost effective and timely manner. It is performed in a highly collaborative and self-organizing manner, with active stakeholder participation to ensure that the team understand and addresses the changing needs of its stakeholders. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
I think that this is a pretty good definition, although I have no doubt that we'll evolve it over time.
I also suspect that the agile community will never settle on a common definition for what agile is and more than likely are smart enough not to even try. ;-)
ScottAmbler 120000HESD Tags:  agility-at-scale xp outside-in-development modeling scrum disciplined-agile-deliver... agileadopt amdd analysis agile 3 Comments 7,892 Views
The popular Agile literature can often seam naive when it comes to how Agilists work with project stakeholders:- Extreme Programming (XP) has a practice called On-Site Customer where one or more people work closely with your team to provide information and to make decisions in a timely manner.- Scrum has the role of Product Owner who is the one single person that the development team goes to for decisions about requirements. - Agile Modeling (AM) has the practice of Active Stakeholder Participation which extends On-Site Customer to get the stakeholder(s) actively involved with the modeling effort through the use of inclusive tools and techniques.
These are great strategies for small, co-located teams doing straightforward development, but they quickly fall apart at scale. This occurs for several reasons:1. Stakeholders are a diverse group. Your stakeholders include end users, business management, project funders, enterprise architects, operations staff, support staff, other system development teams, and many others. Different people have different, and often contradictory, requirements and they certainly have different priorities. It's questionable whether a single person, or a handful of persons, can adequately represent this diverse group.2. One person becomes a bottleneck. Even with a small co-located team this is a problem, let alone one that is geographically distributed or one that is very large. There's no way that a single person can be available 24/7 in a responsive manner to support distributed teams.3. It's a difficult role. The Product Owner/Customer (POC) is responsible for representing the business to the development team. They're making important decisions on a regular basis, decisions which they'll be held accountable for.4. One person becomes a serious project risk. Not only is it questionable whether a single person can fairly represent all stakeholders, even if they could what happens if you lose that person? They effectively become a single point of failure for your team.
To scale this role, consider the following strategies:1. Recognize the true scope of the POC role. Not only are they stakeholder proxies they also are a development team representative to the stakeholder community as a whole. As stakeholder proxies they'll make decisions and prioritize the work, they'll run requirements elicitation sessions, they'll negotiate priorities, and they'll put the development team in contact with stakeholders who have expertise in specific aspects of the domain. As team representatives they'll often demo the current version of the system to other stakeholders, communicate the status of the project to people, and respond to various requests for information from the stakeholders.2. Have multiple people in it. A single POC works well for small, co-located teams developing simple software. At scale you'll soon discover that you need multiple people in this role so that they don't become a bottleneck. For distributed teams it's common to see each subteam have one or more POCs who are managed by a primary/chief POC. The primary POC typically works on the coordinating team with the chief architect (I'll talk about this role in a future blog posting) and the program manager (also a topic for a future blog posting).3. Train them in business analysis skills. The person(s) in the POC role need good business analysis skills. If fact, it's common for people who were formerly BAs for traditional teams to step into the POC role, particularly with BAs who originally come from the business side of your organization. This strategy has its advantages and disadvantages. As a BA they've likely got solid business knowledge but their instincts may motivate them to take a documentation-driven approach to providing information to the development team instead of a collaboration-based approach. Be careful.4. Consider the full system development lifecycle. There's far more to the POC role than supporting the development team during Construction iterations. During "Iteration 0", the Inception phase for an Agile RUP project or the warm-up phase for an Eclipse Way project, the POC(s) will often lead the initial requirements envisioning efforts. The product backlog, or better yet your work item list, needs to come from somewhere after all. During the release iteration(s), the Transition phase for RUP or the End-Game phase for Eclipse Way, the POC(s) will focus on communicating the upcoming release to the stakeholder community, will be actively involved with any final user acceptance testing (UAT), and may even be involved with training end users.
In my January 2008 column in Dr Dobb's Journal, posted at http://www.ddj.com/architect/204801134 , I provide detailed advice about how to scale the way that you work with stakeholders on Agile projects by applying the practices of Agile Model Driven Development (AMDD). There's no magic solution, you just need to choose to organize yourself effectively. The good news is that you can easily work with stakeholders at scale.[Read More]