Taking the Plunge

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.

Holidays and families…  It's a good combination, and it's a good thing my writing deadlines are my own. 

I thought I would take a few posts to review the basics of some of the flavors of Agile.  I'll start with Scrum and XP (eXtreme Programming).

At its core, Scrum consists of the following:

Roles:

• Product Owner
• Scrum Master
• Scrum Team

Meetings:

• Sprint Planning
• Daily Standup
• Sprint Review
• Sprint Retrospective

Practices:

• Planning Poker/Estimating/Sizing
• Velocity
• Iterative Development
• Regular Releases
• Team Colocation

Artifacts:

• Product Backlog
• User Stories/Story Cards
• Sprint Backlogs

I'm not sure that everyone will agree with me, but my perspective on XP is that is it basically Scrum from the developers point of view.  Almost everything listed above is part of what XP categorizes as "Business Practices."  XP also defines "Developer Practices"…:

• Test Driven Development
• Pair Programming
• Collective Code Ownership
• Integrate Continuously

…"Coding Practices"…:

• Code & Design Simply
• Refactor Mercilessly
• Develop Coding Standards
• Develop a Common Vocabulary

…and Values that are in line with Scrum:

• Communication
• Feedback
• Simplicity
• Courage

I'm not going to go into these, in depth, but it is worth noting that the first business practice of XP is to Add a Customer (Scrum's Product Owner), and that the Tracker role, XPs corollary to the ScrumMaster, is optional.  Additional differences worth noting are that XP:

• Allows for overtime
• Recognizes the role of Coach, which is basically a lead developer who may, or may not, participate in development work

Personally, I think that Scrum and XP are almost interchangeable, and would work well blended together.  You could be using a hybrid-Agile approach and not even know it.

I touched on when to use Agile, previously.  Once I finish discussing the flavors of Agile, I think I'll dedicate a post to Agile certifications.  This is something of a personal interest to me, for reasons I'll describe in a moment.  For the post, I'll focus on certifications related to the different flavors of Agile, as opposed to the Scrum certifications I am interested in. 

I'm currently a CSM and will be a CSPO in a couple of months, after I take the class.  I'm hoping to be more involved with Agile projects at work so that I can become a CSP (Certified Scrum Professional) before too much longer.  One of the career paths I'm considering is becoming a CST (Certified Scrum Trainer) and ultimately a CEC (Certified Enterprise Coach) which will allow me to certify coworkers as CSMs and CSPOs via coaching, not just through teaching classes.  I'm not ready to do a lot of traveling to teach classes and coach companies, yet.  I'd like wait until my youngest is out of the house before I do too much traveling.

I occasionally hear things that give me the impression that some people believe that adopting a flavor of Agile makes that company agile.  I'd like to disabuse people of this notion.  While a company is affected by its development practices, if all you do is adopt a flavor of Agile, it's not enough.  The Agile Manifesto and the twelve guiding principles, which essentially represent agile values, must be shared by the whole company, not just IT.

I would also argue that being agile is not the end goal; that it is merely an aspect of being responsive and, ultimately, resilient.  Let's look at a few definitions.

Agile

• Google - Able to move quickly & easily
• Dictionary.com - Quick and well-coordinated in movement

Responsive

• Macmillan
  • Quick to react in the way that is needed, appropriate, or right for a particular situation
  • Showing interest or emotion in reaction to someone or something
  • Willing to reply to a question or talk about something

Resilient

• Merriam Webster - The capability of a strained body to recover its size and shape after deformation caused especially by compressive stress.

Being able to move, or respond to change quickly is the promise of Agile, and it needs to be coupled with Responsiveness to be successful.  What good is it to be able to respond to change quickly if IT and the Business are going in different directions?  You risk ending up with frustrated leaders who are unwilling to collaborate.  I've seen shadow IT evolve and PMOs fail when organizations refuse to be Responsive and work together.

Just looking at the definitions, it might not be clear how being Agile and Responsive are part of being Resilient.  Try recovering from a negative impact to the business without being Agile and Responsive and see how you fare.  Recovering quickly involves moving quickly, having good communication, and common goals, among other things.  An organization might not return to its original size and shape as it recovers, but if the negative impact resulted in a change of priorities, that is not unexpected; the company may not have had the correct size and shape, in the first place.

There are companies that work with other companies to help them become Resilient.  I'm not going to advertise for them; I just want to promote the following:

• Whether or not your company adopts a flavor of Agile, adopt agile values and principles.
• Build an organization that is communicative and collaborative; willing to engage in dialog about change.
• Develop the capacity to learn, adapt, and change quickly, from the top down.  Everyone must be committed to this.

I can't tell you exactly how to do this; it will be different for each company.  Even if your company is already Agile and agile, it will probably take time; culture and process change are not usually quick.  My point is that you shouldn't stop once your company becomes Agile; it's just a step toward becoming a more Responsive and Resilient organization.

NOTE:  Going forward, when using the word Agile to represent the several methodologies and frameworks associated with Agile, I will use the phrase "flavors of Agile," unless I am quoting someone.  If I am talking about a specific framework or methodology, I will identify it by name, i.e. Scrum, Kanban, and so on.

I was recently asked, "Which projects should you use Agile on?"  I'm not sure if my answer was satisfactory, so I thought I would address the question in more detail, here.

For starters, you should always use the Agile principles that apply to your project, even if you're not using a specific flavor of Agile.  (See my previous post for further explanation.)  There are several variables that need to be considered when evaluating when to use a flavor of Agile.

1. Is your organization already using a flavor of Agile?

If your organization is already using a flavor of Agile, the question of when might be out of your control.  If you're not using it for every project, you should have specific guidelines for determining when to/not to use it.  One of the basic guidelines should be whether the project would benefit from or be hindered by iterative development.  Don't assume that just because you have been successful with one flavor of Agile that you will be successful with another.  You're headed toward organizational change, and it doesn't always work that way.

2. Do leadership and non-IT components of your organization understand and support Agile processes?

If your organization is not currently using a flavor of Agile, this is a must.  You must have top-down and lateral support.  If 'Going Agile' is just an IT initiative, you will fail.  If the experience is too painful, people may never want to hear the word Agile again, even if the failure was caused by others not understanding the benefit of the specific flavor of Agile or how it works.

You also need to make sure that everyone using your flavor of Agile is trained on how to participate in it and what to expect from others.

3. What is your company culture?

Does your company embrace change and face organizational issues head on?  Switching to a flavor of Agile is an organizational change, and you will have to face organizational issues in order to change successfully.  The first time one of your teams uses a flavor of Agile, it will be bumpy.  If you're not prepared for bumps, and if the organization cannot handle bumps, it would be an understatement to say that adoption will be difficult.  When working on a large CRM implementation, overseas, I found myself regularly telling the team, "Remember, it's not about whether or not we encounter issues, it's how we deal with the issues that matters.  There will be issues; it's up to us to make this successful."  Are you ready to be a cheerleader?

4. How much is known about your project?

Do you have a strong understanding of the complexity of the project and how complicated the work is, when looking at requirements, technology, and process?  If it is a well-defined and/or simple project, you may not realize any greater benefit from a flavor of Agile than you would from Waterfall.  As details become more vague and the project begins to take on more of an exploratory feel, a flavor of Agile becomes a stronger candidate for success.  As you foray too deeply into the unknown, you may find your time better spent adding a little more definition to your project before choosing a methodology for how you will execute it.

5. What type of project is it?

1. Hardware or software roll-out (internal or third party) - You might be able to use a flavor of Agile if this includes software development, but COTS (Commercial Off The Shelf) rollouts tend to be straightforward (at least on the surface), with little room for iterative discovery.  Changes may go into sprints and releases, but you may be looking at an Agile influenced (hybrid) release management process, as opposed to a flavor of Agile.
2. Process change - This is not a strong candidate for a flavor of Agile.  As noted in a previous post, Scrum is not used to roll out Scrum in an organization.  Organizational change, while it may be progressive, leans toward linear change, as opposed to iterative.  This is not to say that nobody has ever made this work; it's just not a strong candidate.
3. Software or Product Development - These types of projects are often good candidates for a flavor of Agile.  Just keep the above information in mind, as well.
4. Researching/Prototyping - Discovery-type projects are the strongest candidates for a flavor of Agile.  Being able to learn, adapt, and repeat is an important part of these types of projects.

Am I missing something? Probably.  Feel free to share in the comments.

It seems like the next question should be, "What are the flavors of Agile, and which should I use?"  I'll need a little time to prepare answers for that.  Scrum and Hybrid seem to be getting the most attention, lately, but I'm not convinced that it is that simple.  Give me a few weeks to gather my thoughts on the matter.

Need free PDUs?  I'm going to let PMZilla keep you busy for a while.  I haven't checked the links, yet, but the page lists 24 ways to earn from 0.5 to 30+ PDUs.  If I come across anything significant NOT on this list, I'll let you know.