During my career, I have used many Agile methods/processes. IBM’s Agile with Discipline (AWD) happens to be one of them; therefore, I would be remiss if I did not share my experiences learning and using it.

I first stumbled upon AWD in 2008 while evaluating a Scrum implementation for a major telecommunications company.  I heard the company had, at one time, considered AWD and then decided to hire another company that used Scrum. 

As I was an IBM employee and this was an IBM offering, my already inquisitive nature was definitely piqued.  I decided to find out as much as I could about AWD.  Paul Gorans was the Practice Leader of IBM’s Accelerated Solution Delivery (ASD) Group at that time, so I decided to reach out to him.  Lucky for me, they were sponsoring an in-house course on AWD.  I signed up immediately. 

The rest of this blog will cover the history and basic methodology concepts of IBM’s AWD.

IBM's Agile with Discipline (AWD) is part of the standard development methodology of IBM’s Unified Method Framework (UMF). 

Disclaimers: 

1. As I was writing this blog, Paul Gorans informed me that there will be a modification to AWD in the near future.  However, the modification is purely for U.S. Federal agencies.  AWD for non-federal agencies is probably going to stay the same.
2. AWD is not to be confused with IBM’s Disciplined Agile Delivery (DAD), which was created by Scott Ambler, formerly of IBM.  It is important to note that while Scott & Paul collaborated on several things, AWD is different from DAD. 

AWD takes bits and pieces of several methodologies, such as Rational Unified Process (RUP), Scrum, Lean, XP, and then adds some project management “discipline” and “just enough” documentation and processes to be successful.  AWD puts focus around the planning, execution, and control of Agile and rapid development practices.

Here is a snapshot of the overall AWD concept:

Figure 1

AWD can be used for custom application development projects in which time to market and iterative development of prioritized requirements is emphasized.  This model consists of the four phases shown below.  Two of these phases, Solution Definition and Solution Development, are repeated for new iterations of the application. 

Figure 2

 

The first thing those with RUP experience will notice is that AWD is extremely RUPish in appearance.  In fact, the only high-level outward difference is the phase names.  It could be argued that RUP is Agile-like because it does have iterative and incremental phases, but I will not get into that here.

Before looking at the different phases of AWD, we need to spend some time discussing the roles and responsibilities of the typical Agile team in AWD, as well as what AWD calls its accelerators.

Roles/Responsibilities:

I have worked on many AWD proposals and projects and have found the roles and responsibilities of AWD and Agile to be very similar.  That said; it must be noted that on each of these AWD proposals/projects I found the following additional roles:

• Project Manager - The PM is responsible for the “governance” of the team; the role is not counted as part of the agile team per se.  The PM is NOT the Product Owner.
• Offshore Project Manager - Manages offshore teams, as necessary.
• Architect Owner - This Senior/Lead Architect is responsible for the overall solution architecture.
• Development Team Lead - Senior Developer that is responsible for leading the development effort.

Figure 3

 

The concept of Agile teams in AWD is pretty much the same as a Scrum Team.  AWD calls these Accelerators:

•  Teams are small (ten or less), if possible.
•  Teams are co-located, if possible.
•  Cross-pollination of skills is encouraged.
•  Emphasis is on skill generalization versus subject matter experts (SME’s).
• SME’s are brought in on an as-needed basis.
• Teams are self-organizing with an “appropriate” amount of “governance”.
• Teams are highly collaborative.
• Team members are 100% dedicated to the project, shared resources are strongly discouraged.

Now for the dive into AWD.  I am going to go through each of the phases and describe the key activities so you can get a more thorough understanding of AWD.

The Open Phase:

The following activities occur during the Open Phase:

• Build the initial team.
• Develop a shared vision:  What are the goals? Who are the stakeholders? What are you trying to achieve?
• Initial requirements envisioning: What is the scope?
• Initial architecture envisioning: What is the technical vision?
• Setup the environment: The team needs tools, a place to work, and other resources.
• Initial high-level release planning: How long will the project take?  What will be the cost?

Figure 4

 

The Solution Definition Phase:

The Solution Definition Phase in AWD usually starts with a Sprint 0 which can be used to ramp up the teams, install and configure the development, test, and production environments, as well as any other steps that the PM and/or team feel they need to perform prior to actually starting the first iteration. After Sprint 0, the iterative and incremental aspect of the Solution Definition Phase begins.

Figure 5

 

The Solution Development Phase:

As you can see from the Figure 6, the Solution Development Phase is where the real work towards delivering software begins.  This is also the phase that would be most familiar to people in the Scrum world.

Figure 6

 

The Close Phase:

This phase is where everything for the project or the release is wrapped up.  All of the PM activities are concluded, the artifacts are delivered, the solution has been accepted and has been signed off by the client, and the development team prepares to either roll off the project, start another project, or switch to a maintenance effort.

Figure 7

 

So, that’s AWD at a high level. I purposely did not get into the document templates that are used because they are IBM proprietary property.  I have used AWD on projects and the process worked extremely well.  I have also seen projects fail because AWD processes were used improperly.  Like Scrum, XP, or any other of the Agile processes/methods/frameworks, AWD will not help a project if it does not have the appropriate level of executive/management support and the teams are not trained or motivated to be Agile.  The key to a successful Agile project, whether it is Scrum, AWD, DAD or whatever, is to actually be agile and not just talk agile.

If you want to know more about IBM’s Agile With Discipline feel free to leave a comment, and I will get back to you.

Thanks for taking the time to read this blog.

Be safe and live free