Taking the Plunge

I was going to review AUP - the Agile Unified Process (having read about it, once, several years ago, when part of the company I was working for used RUP), but, in 2006, Scott Ambler abandoned it in favor of Disciplined Agile Delivery (DAD), which has since evolved into the Disciplined Agile Framework.  The reason for this shift was to address how to be effective at IT, not just at delivering IT solutions.

Disciplined Agile has its own manifesto and principles.  It is intended to be an extension of the Agile Manifesto, so it will seem very familiar when reading it.

Scott provides several reasons why you should choose Disciplined Agile.

1. Disciplined Agile picks up with Scrum leaves off, dealing with architecture, design, testing, programming, documentation, etc…
2. It is pragmatic, allowing you to choose how to execute it in response to your situation
3. It supports both lean and agile lifecycles
4. It is based on proven strategies used across multiple industries
5. It provides a foundation for scalability
6. It enables and goes beyond SAFe (Scaled Agile Framework; watch for it next week)
7. It is constantly evolving as new agile and lean strategies emerge

Roles are split into primary and secondary roles.  Primary roles exist regardless of the scale of the project.  They are:

• Stakeholder
• Product Owner
• Architecture Owner
• Team Lead (analogous to a Scrum Manager and Agile Coach)
• Team Member

As a project grows in scale, the following roles may be added:

• Specialist
• Independent Tester
• Domain Expert
• Technical Expert
• Integrator

As you learn more about Disciplined Agile, you'll begin to recognize flavors of other project management approaches.  It is intentionally a hybrid approach, with the intent of borrowing the best from other approaches and combining them in attempt to leverage their strengths and overcome their weaknesses.

In keeping with its emphasis on the agile organization, not just agile delivery, Disciplined Agile provides guidance on establishing and running agile Communities of Practice and Centers of Excellence, governing agile teams, and maintaining awareness of agile at five different levels within an organization.  This, combined with other practices, is referred to as Strategic Agility at Scale.  Organizational processes are broken down into lifecycles and blades.  These are:

Disciplined Agile Delivery

• Continuous Delivery
• Exploratory/Lean Startup
• Lean/Advanced
• Agile/Basic
• Program Management

Disciplined DevOps

• Non-Agile/Lean Lifecycles
• Release Management
• Operations
• Support
• Data Management

Disciplined Agile IT

• People Management
• Product Management
• Portfolio Management
• Enterprise Architecture
• Reuse Engineering
• IT Governance
• Continuous Improvement

While this is not the same process as ASAP, it's starting to feel the same - highly structured, which almost feels contrary to Agile - but that is not a bad thing when dealing with Agile at the enterprise level.

While I can't say whether or not Disciplined Agile is the best approach, I completely agree with the mindset that transitioning to Agile cannot be just an IT change.  Not only does Agile change how products are delivered, it changes how progress is reported, how requirements are prepared, how projects are planned, and more.  If your leadership is still expecting things to run the way they used to, you may struggle to get support because leadership expectations are not aligned with Agile practices - this is a concern with all Agile flavors, not just with Disciplined Agile.

Change of plans, and I apologize for the delay.  My intent was to cover, very briefly, three more flavors of Agile in one post, so that I could get to scalable approaches sooner.  These flavors are:

1. Agile ASAP
2. Feature Driven Development (FDD)
3. Disciplined Agile Delivery (DAD)

As I was working on this, I realized that I could not address all three in adequate detail without writing a short book (I'm trying to keep my posts more concise.  Trying…), and both FDD and DAD have elements of scalability built into them.  Addressing them individually makes more sense.

In case you've never worked on an SAP project (or maybe even if you have), ASAP stands for Accelerated SAP.  It is SAP's implementation methodology for SAP solutions, with end-to-end coverage of the Process Lifecycle, Application Lifecycle, Project Lifecycle, and Value Lifecycle.

ASAP addresses:

• Project Management
• Organizational Change Management
• Data Management
• Business Process Management
• Technical Solution Management
•  Integration Solution Management

…and provides templates, tools, questionnaires, checklists, and guidebooks to assist the project team.  I'd explain more, but I'm not sure I can condense a four day training class into a blog post; it is not a lightweight methodology.  So, how is this Agile?  It's not.  ASAP is the foundation for Agile ASAP.

What is Agile ASAP, then?  Essentially, it is a slightly lighter-weight methodology that uses elements of Lean and Scrum during development.  Kind of.  There's a little more to it than that, but I'm trying to keep it simple and I don't want to lose your attention rehashing Lean and Scrum. 

If you're using ASAP, Agile ASAP may be a good fit for you (transitioning to Agile is challenging), but it's really for SAP implementation projects, so I don't recommend it if you're working on other types of projects.

I've been working on several SAP implementations, over the last couple of years.  We haven't used ASAP, largely because of the technical requirements.  There are some specific requirements for your SAP landscape and SAP Solution Manager to use the methodology effectively that the company I work for has only recently started to pursue.  The new version of Solution Manager can, reportedly, be used for more than just SAP projects, and has integrated with Microsoft Project, to some extent, for the last couple of versions, at least.  It can add a lot of value if you have the time and resources to get everything set up correctly.

If you have experience using ASAP or Agile ASAP, please share your experience in the comments.

I'm going to keep it short today.  At least that is what I am telling myself.  Short is such a relative term to someone who can be as longwinded as me.

The DSDM Agile Project Framework is a scalable "full project" approach to Agile (it emphasizes more than development) that is supported by a set of eight principles built upon:

• People with defined roles and responsibilities
• An iterative and incremental lifecycle for development and delivery
• Clearly defined products
• Recommended practices

…and further founded on an underlying ethos of common sense and practices.  The principles are:

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control

After having read the framework, I would think that if you are hesitant to adopt Scrum because it seems too unstructured, DSDM might be a good alternative for you.  Keep in mind that I have never used it and have never spoken to anyone who uses it, so I am not speaking as an expert.  However, I am experienced enough in the majority of the information, tools, and processes presented in the framework that I am comfortable saying that this is a good approach to consider when deciding which Agile approach to use.

There, nice and short.  And I'm having to force myself to not go back and add all the detail behind those two short lists.  There is a lot of detail, and it's more than two lists, but if you have even minimal experience in Waterfall and Agile, you'll find very little that is new.  What makes it unique is how the pieces are put together; it's more than just Scrum.  There are things you would do on a Waterfall project that are not specifically called out in Scrum, but it's Agile.  I'm starting to feel like a candy bar commercial… Hey, you got Agile in my Waterfall…

Next week, I think I'll combine the last few flavors I've been thinking about into one post, so that I can get to scaling Agile a couple of weeks earlier than planned.

Crystal is a family of methodologies that I have not been able to find a wealth of information about.  I've found a few books by Alistair Cockburn:

• Crystal Clear: A Human-Powered Methodology for Small Teams (used as a reference for some of the content on this post)
• Crystal Orange: Surviving Object-Oriented Projects
• Crystal Orange/Web: Agile Software Development

…and there is a website, where Alistair Cockburn indicates that Crystal predates the Agile Manifesto:

http://alistair.cockburn.us/Crystal+methodologies

…but I haven't been able to find comprehensive coverage of all members of the family.

There are several members of the Crystal family, with the intent to scale up from a small project to large, complex projects.  The Crystal Family is divided as follows, with Crystal Clear being the smallest (1-6 team members) and, as best as I can tell, the largest is the last three, with Crystal Diamond and Crystal Sapphire including additional complexities, such as risk to human life:

1. Crystal Clear
2. Crystal Yellow
3. Crystal Orange
4. Crystal Orange Web
5. Crystal Red
6. Crystal Maroon
7. Crystal Diamond
8. Crystal Sapphire

I know, a link to wikipedia… this is not meant to be a scholarly article; please bear with me.

Each member of the Crystal family is built on what is referred to as a 'genetic code' made up of:

• The economic-cooperative game model, which says that, "software development is a series of resource limited games whose moves consist of nothing else besides inventing and communicating
• Selected priorities
  • Safety in the Project Outcome
  • Efficiency in Development
  • Habitability of the conventions
• Selected properties
  • Frequent delivery
  • Reflective improvement
  • Personal safety
  • Focus
  • Easy access to expert users
  • Technical environment with automated testing, configuration management, and frequent integration
• Selected principles
  • Exploratory 360
  • Early victory
  • Walking skeleton
  • Incremental rearchitecture
  • Information radiators
• Selected sample techniques
  • Methodology shaping
  • Reflection workshop
  • Blitz planning
  • Delphi estimation using expertise rankings
  • Daily standup meetings
  • Essential interaction design
  • Process miniature
  • Side-by-side programming
  • Burn charts
• Project examples

Notice the use of the word "selected?"  I find it interesting that, while there are several members of the Crystal family, there are few hard and fast rules.  You are not expected to use each item in the list, above, on every project.  Using the properties as an example, Crystal Clear only requires the first three.  Furthermore, Crystal (the family) is not opposed to using principles and practices from other project management methodologies. 

As you dig in to Crystal Roles and Work Products, you'll find artifacts that you expect to see in a waterfall project, that don't get a lot of attention in some of the other Agile flavors.  I wouldn't call it the perfect marriage of Agile and Waterfall, maybe more of an evolutionary step between Waterfall and more recently evolved flavors of Agile.  I don't know.  What do you think?

Let me start by saying that I am not going to give you the history of the Toyota Production System (TPS).  If you're familiar with it, great, you know what I'm talking about.  If you're not familiar with it, you should read about it.  Toyota provides several pages of information on both history and current practices of TPS that will give you context to the overview I will be providing.

Even if you are not familiar with TPS, you may have heard of Lean and Kanban.  You've probably heard them used together, more often than not.  I would argue that they represent the original Agile approach, but I have not found any evidence that they were used for software development before Agile became a "thing."  I think this may be, in part, because production processes do not directly translate into development processes.

Using the book "Lean Software Development - An Agile Toolkit," by Tom & Mary Poppendieck, as a reference, Lean gives us the following (highly summarized and subjective, on my part) principles and tools for software development.  I should warn you, some of this may seem counterintuitive at first glance, and could be difficult for people to accept without further discussion:

• Principle - Eliminate Waste: If something does not directly add value as perceived by the customer, it is waste.
  • Tool - Seeing Waste: If it is not analysis or coding, does it add value?
  • Tool - Value Stream Mapping: Map your value stream to start discovering waste
• Principle - Amplify Learning: Involve business people in the learning process; they will recognize business problems as they use the system.
  • Tool - Feedback: Feedback, early and often, will help you to identify problems  sooner.
  • Tool - Iterations: Use just-in-time inventory flows to meet customer demands, as opposed to meeting a schedule.
  • Tool - Synchronization: Make sure that people working on features with a common code base are working closely together.
  • Tool - Set-based Development:  Basing communication on constraints, as opposed to choices, reduces the amount of data that needs to be communicated and defers choices until the last responsible moment.
• Principle - Decide as Late as Possible:  This can be difficult because it also means allowing change as late as possible, which is in direct contrast to the common desire to be decisive and make decisions quickly.
  • Tool - Options Thinking:  Uncertainty can make it difficult to make final decisions early. What can you do to move from predictive processes to adaptive processes?
  • Tool - The Last Responsible Moment:  Not to be confused with procrastination, this involves delaying commitment until the moment at which failing to make a decision eliminates an important alternative.
  • Tool - Making Decisions:  Understand the decision making process and factors that affect decision making.
• Principle - Deliver as Fast as Possible:  Customers like fast delivery.  Providers should too.  The faster you can deliver something, the longer you can delay making decisions.  This sounds counterintuitive, but think of it this way; If you can make a change in a week and have a month until you can deliver, you have three weeks to make a decision about the change.  Remember, this is not procrastination.
  • Tool - Pull Systems:  Let customer need pull the work, instead of having a schedule push the work.
  • Tool - Queuing Theory:  How do you make cycle time as short as possible?
  • Tool - Cost of Delay:  Understand the price tag on time in four areas 1) development cost, 2) unit cost, 3) performance, and 4) introduction date.
• Principle - Empower the Team:
  • Tool - Self Determination: Provide workers with the expectations and let them determine how to achieve them.
  • Tool - Motivation:  There are a lot of factors that affect motivation; purpose is chief among them.
  • Tool - Leadership: Teams need leaders, not just managers.
  • Tool - Expertise:  Make sure your team either has the expertise it needs, or access to it.
• Principle - Build Integrity In:  Product integrity is found in high performing companies.
  • Tool - Perceived Integrity:  The totality of the product achieves a balance of function, usability, reliability, and economy that adds value for the customer.
  • Tool - Conceptual Integrity:  The system's central concepts work together as a smooth, cohesive whole.
  • Tool - Refactoring:  Start with something that works, learn from its weaknesses, and improve the design.
  • Tool - Testing:  Test that design intent is achieved and that the system does what customers want it to do.
• Principle - See the Whole:  A system is not just the sum of its parts - it is the product of their interactions.
  • Tool - Measurements:  Don't measure complex, unstructured work by disaggregation; measure the aggregate.  i.e. measure group performance, not individual performance.
  • Tool - Contracts:  Use contracts to build trust between organizations, not to create barriers.

Kanban fits smoothly into Lean Principles, with the following principles of its own:

• Start with the existing process
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities and titles
• Leadership at all levels

…as well as the following values:

• Visualize the workflow
• Limit Work in Progress (WIP)
• Manage the Flow

Similar to Scrum, in Kanban, visualizing work is done with a board and cards.  One of the primary differences is that Kanban emphasizes WIP, or the amount of work that the available resources can work on at any given time, as opposed to velocity - how much work can be completed in a time-boxed period.  Here are some additional differences, as identified by VersionOne:

While this may change, I currently do not intend to spend a lot of time on hybrid flavors, but I will at least share some links.  Here are a couple of Kanban hybrids you may, or may not, have heard about:

• Leanban
• Scrumban

I'll say this now, and try to remember to repeat it often as I post about agile.  If you're going to adopt a flavor of agile, pick the one that fits your company culture best, to the best of your knowledge, and learn how to do it right.  Once you have it down, apply the final principle of Agile:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Learn and adapt.  Be agile, not just Agile.  If you can't adopt a flavor of Agile, adopt as many of the principles as make sense for your organization.  You're probably already following some, and can easily identify areas where you can improve.