Taking the Plunge

You might recall previous posts where I stated that making the transition to Agile can be challenging?  Well, this is where I give a personal example of my experience as the company I work for makes an agile transformation.

I was recently asked to be ScrumMaster over a mobile project.  Okay, it would probably be more accurate to call the project a program, and to call myself an agile coach, but that is not how it was presented.  Our framework is Scrum-like, but given the following conditions, I can't really call it by-the-book Scrum.  However, that does not mean we're not going to make it as Agile as possible.

• Six developers; two local, four off-shore.
• 4 product owners
• iOS and Android versions of each product.  Would that be four products, or eight?
• These are ongoing maintenance efforts

I joined the project team on the last day of the Sprint.  It was a 45 minute meeting where three different sprint backlogs were reviewed and two features were demoed (is that a word?).  A sprint retrospective was not held.

I know, some of you are probably ready to tell me how agile we're not and how I need to fix things, quickly, but would that be in the spirit of agile?

Currently, we are meeting 3 days a week for 30 minutes to an hour, on a video call with developers in three different locations.  Sprint planning is on the fly, and sprint retrospectives have not been done in a while.  Among the areas where I have identified that we can make improvements are:

• A consolidated story board and sprint backlog
• Potential changes to the meeting schedule
• A unified workflow across all products
• Product roadmaps
• Standard definitions for the following, across all products, since the developers all work on more than one product
  • Definition of Ready
  • Completion Criteria
  • Definition of Done

I've created a consolidated story board and sprint backlog, and we've started talking about the other items.  I intend to have a more formal discussion about these items during the retrospective, next week.  I could try to force changes in all of these areas, at once, but I think that would do more damage than good, not to mention that the team would spend more time on process improvement than development.  The team was getting work done before I became the scrum master agile coach.  Some people might have thought things were a little rough before, but change doesn't guarantee they won't continue to be rough; they'll just be different.

I am aware that there are times when it is best to just rip off the bandage, but my intent is to treat my team like a high performing team.  There are changes that can be made, sure.  Scrum has a process for fine tuning team processes, called the retrospective.  I will use this tool to make recommendations to the team, as well as encouraging them to identify areas where we can improve, and then let them decide the changes they want to make, determine the priority of the changes, and establish their own cadence in making those changes.  The collective team may have better solutions than I could come up with on my own.

I'm ready for this adventure and look forward to working with my team.  I'll share more as they become the high performing team that I know they can be.

Let me preface this by saying that this is not the introduction to 10+ posts on the Flavors of the Waterfall methodology.  It's one post with the intent to explore Waterfall's origins.

Why?  I've lost track of the number of times I've heard (or read) Agile evangelists offer a proscriptive definition of Waterfall and then blame the process for failed projects.  They almost make you think that every Waterfall project fails.  So, what happened before Agile, and what, exactly, is Waterfall?

The most popular theory that I can find is that Waterfall came from a paper written by Dr. Winston W. Royce, titled "Managing the Development of Large Software Systems," published in 1970.  Dr. Royce never named a methodology Waterfall, and in his paper he gives the impression that he thinks that there is more than one approach to software development.

The first approach is described as the "…two essential steps common to all computer program developments, regardless of size or complexity…" analysis and development.  If the program being developed is small enough, this is all that is needed.  Hmmm.  This doesn't seem highly proscriptive, and could be argued to be the foundation for iterative development (although a bit of a stretch).  This must not be Waterfall.

The second approach, specifically for developing large computer programs for delivery to a customer, is described with the following phases:

• System Requirements
• Software Requirements
• Analysis
• Program Design
• Coding
• Testing
• Operations

Now that looks like Waterfall!

But Dr. Royce didn't stop there.  He went on to explain that each of these phases has an iterative relationship with the phase immediately preceding it.  What this means is that once System Requirements are complete, it is possible that something could be found during Software Requirements that requires you to go back to System Requirements, and so on through the phases.  That does not sound like the Waterfall that the Agile evangelists complain about. 

He didn't express any concerns with the iterative relationship between sequential steps.  The concern he expressed was that this iterative relationship had the potential to jump back multiple phases, resulting in significant delays because you couldn't skip back to where you came from; you had to go through the phases in sequence to get back to where you were.  This sounds more like the Waterfall that so many have come to know and dislike.

This is also the first two pages of the paper.  The rest of the paper consists of diagrams and steps to eliminate the risks inherent in the process.  These steps are:

• Introduce preliminary program design before analysis
• Document the design.  Dr. Royce was a firm believer in documentation, and lots of it.  Yes, we're back on the Waterfall path, again.  However, he is not recommending documentation for the sake of documentation.  He just feels that a large software development project requires a lot of documentation, for very specific purposes.
• Do it twice.  Run a smaller scale pilot, in a shorter timeframe, to simulate the process and identify then resolve problems before running the full project.  And, yes, this is, counterintuitively, done before the next step…
• Plan, control, and monitor testing. 
• The "last" step, although it is not so much a sequential step as a set of steps throughout the project, is to involve the customer.  Three formal points for identifying the customer are identified, 1) during the Preliminary Software Review, held between the Preliminary Program Design and Analysis, 2) during the Critical Software Review, held between Program Design and Coding, and 3) during the Final Software Acceptance Review, held after Testing and before moving into Production.  The expressed purpose for involving the customer is to gain commitment; giving the developer free rein is a recipe for failure.

I'll be honest, I have used similar phases but, in 15 years managing projects, I have never done it exactly like this.  Does that mean I wasn't using Waterfall, because I wasn’t doing it right?

No.  This process potentially provides a foundation for both Agile and modern Waterfall.  On the Agile side, there is iterative work and maintaining a close relationship with the customer.  On the Waterfall side, there are sequential phases and lots of documentation.

This process could take a lot of time.  Keep in mind that Dr. Royce never described a process for a medium sized development project.  The process he described is intended for a large software project, which could take a lot of time even if you used Agile, instead.  Agile does not guarantee faster delivery of a completed project, it attempts to deliver useable features faster.  Agile may actually take longer than Waterfall on a large project, with the tradeoff being that what is delivered has a higher likelihood of being useful (and different from what was designed at the beginning of the project).

So, what is Waterfall, today, 46 years after Dr. Royce's paper was published?  It's still sequential, mostly.  It can still require a lot of documentation, but each project should be looked at to determine how the phases should interact and what the right level of documentation is.  The area where Waterfall struggles the most is an area that would cause Agile to fail, as well.  Customer involvement.  Agile prescribes customer involvement. Waterfall apparently does, too, according to Dr. Royce.  It's just not always implemented that way.  When an Agile evangelist blames Waterfall for project failure, that person is removing accountability from the people who ran the process that failed. The project that failed may be one that would have been better served by Agile, but it may also be that the process needs to be adjusted and the people running the process need to learn from their mistakes.

Right or wrong, here is my attempt to organize Flavors of Agile according to weight.  The first group is lightweight frameworks; they attempt to accomplish as much as possible with minimal structure.  In most cases, the majority of information that you will find about lightweight frameworks is going to focus on single team, single product, with instruction on how to run the process and little to no instruction on how to roll it out to an organization.  This is not to say that there is no information on scaling or rolling it out; it's just not the primary focus.

• FAST Agile
• FDD
• Kanban
• Lean
• Scrum
• XP

I consider the rest of the flavors to be "more" substantial.  They're not all heavy processes, like Agile ASAP, they're just more substantial than the lightweight frameworks.  Additionally, some include more roles and processes, and are either built for large projects or include instruction on scaling up to large projects.

• Agile ASAP
• AUP/DAD
• Crystal - weight varies based on the size of the project and other factors
  • Crystal Clear
  • Crystal Yellow
  • Crystal Orange
  • Crystal Orange Web
  • Crystal Red
  • Crystal Maroon
  • Crystal Diamond
  • Crystal Sapphire
• DSDM
• Scrum Plus
  • LeSS
  • SAFe
  • SLIM

There is a plethora of Agile certifications, most of which are related to Scrum.  I was going to harp on the online certifications, like those offered by the International Scrum institute, which you pretty much pay a fee for and then take a test.  No other training or experience is required.  After thinking about it, though, I'm leaning toward the biggest negative being that they are not as well known.

Consider this.  To become a CSM, you have to attend a two day class and pass a short & simple quiz on the basics of what you just covered.  If you can answer the Agile Fact or Crap game cards correctly, you can probably pass the test.  Is this significantly more meaningful than maybe having some experience, maybe reading a book or two, and paying a fee and taking a test to get the SMAC from ICI?  There is value in being trained by someone with experience, but consider CLEPping a class in college.  I CLEPped a macroeconomics class and received full credit for it.  Like the macroeconomics CLEP, the CSM is about knowledge, not experience, it just happens to be the most well-known Scrum certification.  The real value comes from what it can do for you and how you can use it to your advantage.  I don't know if the following will add any value to your resume, but here is one online Scrum certification provider and the certifications it offers:

• International Scrum Institute
  • Scrum Master Accredited Certification
  • Scrum Product Owner Accredited Certification
  • Scrum Team Member Accredited Certification
  • Scrum Coach Accredited Certification
  • Scrum Trainer Accredited Certification
  • Scaled Scrum Expert Accredited Certification
  • Scrum Certification for Web Developer
  • Scrum Certification for Java Developer

Here are additional Scrum certification providers:

• EXIN Agile Scrum Master
• Less
  • Certified Less Practitioner
  • Certified LeSS Executive
  • Certified LeSS Trainer
• Scrum Alliance
  • Certified ScrumMaster
  • Certified Scrum Product Owner
  • Certified Scrum Developer
  • Certified Scrum Professional
  • Certified Scrum Trainer
  • Scrum Alliance Certified Enterprise Coach
  • Scrum Alliance Certified Team Coach
• Scrum.org
  • Professional Scrum Master
  • Professional Scrum Product Owner
  • Professional Scrum Developer
  • Scaled Professional Scrum
  • Professional Scrum Trainer

I could not find any certifications for Crystal, SLIM, or XP.  SAP offers classes on Agile ASAP and has their own SAP project management certification, but no Agile certification.  Here are some more Agile certifications; some offered by the respective authors of a specific flavor of Agile, others by certifying bodies that don't offer a specific flavor of their own.

• ACI
  • Certified Agile Associate
  • Certified Scrum Associate
  • Accredited Agile Practitioner
  • Accredited Scrum Master
  • Accredited Product Owner
  • Accredited Scaled Agile Practitioner
• Kanban
  • Scrum Alliance Kanban Practitioner
  • ACI Accredited Kanban Practitioner
• Lean
  • Lean Bronze
  • Lean Silver
  • Lean Gold
  • ACI Accredited Lean Software Development Practitioner
• FDD
  • Certified FDD Aware
  • Certified FDD Associate
  • Certified FDD Practitioner
  • Certified FDD Project Manager
  • Certified FDD Consultant
• Disciplined Agile
  • Disciplined Agilist
  • Certified Disciplined Agilist
  • Certified Disciplined Agilist Practitioner
  • Certified Disciplined Agilist Coach
  • Certified Disciplined Agilist Instructor
• SAFe
  • SAFe Agilist
  • SAFe Practitioner
  • SAFe Program Consultant
  • SAFe Program Consultant Trainer
  • SAFe Product Manager/Product Owner
• APMG International (DSDM)
  • Agile Programme Management
  • Agile Project Management
• Certified Agile Leader
• PMI-ACP

ICAgile has the Agile certification of Agile certifications.  The ICAgile Certified Professional is the foundation.  From there, you work through professional certifications to expert certifications in a range of topics.  Each expert certification has 1-2 prerequisite professional certifications.  They require classroom learning, demonstrated experience, and an exam.  I wasn't able to find an exact number of certifications needed to become a Certified Master Agilist; the description says multiple, not all of them.

I saved this for last because it addresses the development of an agile organization.  I can't imagine anyone (sane) getting all of the certifications but, if you are considering an agile transformation, it might not be a bad thing to have a team of people who, cumulatively, have all of the certifications, engaged in the process. 

While it has not been proven, yet, that I am not sane, the thought of becoming a Certified Master Agilist with all of the expert certifications has a little appeal.  It would be cheaper than a PhD, and might not take much longer, assuming I try to maintain at least a marginal work-life balance.  There is a good chance that by the time I finished, however, I would have forgotten everything I learned while obtaining the first half of the certifications.

• ICAgile
  • Certified Master Agilist
    • Business Agility
    • Agile Coaching
    • Value Management
    • Delivery Management
    • Agile Coaching
    • Agile Engineering
    • Agile Testing
    • DevOps
      • Certified Professional

Which one is right for you?  I can't tell you that.  You need to evaluate several variables:

• What are your goals?
• What is your current reality, with regards to your experience, education, employment, and the job market? 
• When you search your local job market (or the job market where you want to work), what certifications do you see being sought by potential employers?

If your experience is in the software industry, in the United States, CSM might be the best choice.  If you're in manufacturing, Lean/Kanban might be better.  If you're in the UK, DSDM is probably your best bet.  In some cases, employers are looking for any certification because they've heard about agile and want someone who knows more than they do, about it.  There's no silver bullet.

I'm going to take a moment to talk about the dark side of certifications.  You might start to feel like certification is a racket.  There are people with multiple acronyms after their names that can't get a job.  Some of these people have been sold on the idea that getting the certification will make them more money.  Once you start down this path, you end up taking classes, participating in webinars and conferences, and watching video broadcasts, all in the name of getting and maintaining a credential.  For what?

If you took the shotgun approach to certifications, there is a good chance it was for nothing.  Approach certifications like a sharpshooter.  I was going to say like a sniper, but you don't need that level of perfection or long term planning; you need to be able to reach your target quickly, while remaining flexible enough to deal with changes that occur over time.

In my case, I'm a CSM and CSPO, with the intent of becoming a CSP.  This will put me on the path, should I choose to pursue it, of becoming a CST for both the CSM and CSPO classes.  Will I become a CST?  I don't know.  While I figure that out, the training I received while obtaining both credentials will help me to be a better coach for my agile project teams.  As I gain more experience, it will hopefully compound the effect and my effectiveness. 

FAST Agile - "…a collaboration model for organizing people around work."

As far as I can tell, FAST is not an acronym.  It borrows from Scrum and XP, among other things, but is even lighter weight.  It has a vision, values, rules, and principles that may sound a little chaotic, if you're new to Agile, but a little chaos might not be a bad thing.  The prerequisites can be summed up as follows:

• Be committed to self-organization
• Co-locate your team
• Have a large room for the one meeting you will have between each release.
• Management support and willingness to experiment

The roles in FAST are:

• Product Director - similar to the Product Owner in Scrum
• Stakeholder - what it sounds like.
• Developer - people with cross functional skills, dedicated to the team, organized into what is called a Tribe.
• Resource - a part time member of the tribe
• Story Steward - someone who suggests a story in the Marketplace

There is a FAST Project Manager, but not much is said about this role.  I'm assuming it's similar to Scrum Master, but I could be wrong.

Call it a release map, product wall, or story map, this is how work is planned and tracked.  It is the only artifact for the project.

There is only one prescribed meeting, although the team can have huddles whenever they feel the need.  The FAST meeting is broken into four parts:

• Show and Tell, where work from the previous iteration is demonstrated
• The Marketplace, where members of the tribe get up and discuss stories or problems they would like to work on in the next iteration
• Public announcements and alignment of vision
• Team huddle for planning and to discuss dependencies

There you have it… FAST, fast.

If you have an experienced agile team but you feel like you’re getting a little stagnant, FAST could be a way to change things up and invigorate the team.  If you're new to agile, however, you may just experience failing fast and failing often, and not in a good way.  As I mentioned before, this is a very lightweight framework, it is also very developer-centric, and very experiment-based.  As you go through the FAST agile web site, you might even think FAST is unfinished as the author does not attempt to address every possible scenario and encourages feedback as you use the process and try new things. This just means it is young and evolving.  By the time you read the web site, there could be additions to the process.

Unless I come across another Flavor of Agile, this is the last one I will attempt to summarize.  I will give an honorable mention to SCARE - Sustainable, Cultural Agile Release for the Enterprise, but I can't really call it a Flavor of agile.  Instead of covering how to conduct an iterative release process, SCARE is more about a mostly bottom-up approach to introducing a Flavor of agile into an organization and working toward adoption.

I'm planning on one more Flavors of Agile post.  In it I intend to group the flavors that I have covered into Scrum-based, RUP-based, and any other foundations that may be contributing to the flavor, to distinguish their roots.  Kind of like sweet, salty, and savory flavors.  I will also present a list of Agile certifications and attempt to distinguish differences between them.

If I missed any flavors of agile, please let me know.

Large Scale Scrum, that is.

Take multi-team Scrum with a Scrum of Scrums, add Sprint Planning of Sprint Plannings and Retrospective of Retrospectives, and voila!

Okay, it may not be that easy, but it's close, on paper, when you want to explain it, at a high level, to someone who does not care about the details.

When you take a Scrum training class, you are most likely learning what The LeSS Company refers to as 'Single Team Scrum.'  I would amend this to 'Single Team, Single Product Scrum.'  I'll get to why, later.  For now, I'll just call it Scrum.  Understanding how Scrum works is your foundation to being able to scale-up Scrum.

LeSS offers two frameworks:

• LeSS - up to eight Scrum teams
• LeSS Huge - up to a few thousand people on one product

Regardless of which framework is used, there is a single Product backlog, one Product Owner, multiple teams, one sprint (at a time), all coming together to deliver one shippable product, each sprint.

How does LeSS compare to Scrum?  In leSS, Sprint Planning is split into two parts.  In part one, all teams participate and discuss how to split the work between teams.  In part two, the individual teams meet separately to plan their own sprints.  Daily Scrums are held by each team, and members from one team can observe another team's meeting in order to increase awareness of overall progress and share information.

Yes, there can be a Scrum of Scrums - optional , but beneficial.  Product Backlog Refinement combines all teams; it is not held separately by individual teams.  The same is true for the Sprint Review and Overall Retrospective.  It is worth noting that the Overall Retrospective does not require all team members to participate; just representatives from each team.  It can be different representatives, each time. 

Truth be told, I would still recommend individual team retrospectives.  Yes, it adds another meeting (and who wants that?), but each individual team will go through Tuckman's stages of group development - forming, storming, norming, and performing.  Once they are a high performing team, there are still minor adjustments that can be made and goals that can be set.    Without this, their representative may come back from the Overall Retrospective with goals and adjustments that the team did not agree to.

As you get into how to run LeSS Huge, the differences to Scrum start to grow.  IT still looks like Scrum, but it's not as organizationally flat.  A simple summation would be Requirements Areas, Area Product Owners, and potentially more meetings because more coordination is required.  The Product Owner breaks features down into Requirements Areas.  Separate Product Owners (Area Product Owners) own the Requirements Areas.  From there, it starts to look the same.

LeSS, of course, has its own set of principles that you are welcome to read about.  I can't say you'll find anything new or significantly different from other flavors of Agile, but they may help you understand the reasoning behind the approach. 

As I delve through the less.works site, I'm developing the opinion that a truly valuable tool in LeSS is User Story Mapping.  Whether you are using LeSS, or LeSS Huge, user story mapping provides a way to break up the work into related clusters that can be assigned to individual teams that all contribute to the finished product.

I think I found my new favorite (work-related) quote, which holds true for any flavor of Agile, or other approach to project management:

"There are no such things as best practices.  There are only practices that are good within a certain context."

The context in LeSS, as in many of the flavors of Agile, is Single Product.  So what do you do if you have multiple products?  Enter SLIM, or Scrum Lean In Motion.  If you visit the link, down at the bottom, you'll find that SLIM is a made up acronym, but the principle behind it may make sense, depending upon the context of your organization.  This principle is that, instead of scaling Agile up, you scale your organization down.

Does this mean dump products, or split the organization into multiple organizations that only focus on one product?  Is this even reasonable, let alone feasible?  I couldn't say, but I think that most companies would be unwilling to make such drastic changes just so that they could use a framework.  That would take well-quantified value, with the value being the goal, not the framework, so I won't say it's impossible.  My point in bringing up SLIM is to reiterate that organizational change is needed regardless of which flavor of Agile you adopt.  How much change can your organization tolerate?

This leads me to questions that I'm sure many others in a similar situation ask.  I work for a company that has multiple web sites, mobile apps, and back end systems that serve different customers, but are interconnected and, in some cases, share developers.  It is difficult to make a major change in one system without affecting another.  Do we have one product, or many?  We're embracing agile practices, where we can, but how do we take that step from release management to truly agile?

I've got a few more flavors of Agile to go, but I'm pretty sure they will be more along the lines of scalable single product variants.  As I wrap up the flavors of Agile, I'll put some more thought into multi-product approaches.  Hybrid comes to mind, first.  I'll deal with that in a future post.