Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Flavors of Agile - Certifications
Categories:
Agile
Categories: Agile
| 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.
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.
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:
Here are additional Scrum certification providers:
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.
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.
Which one is right for you? I can't tell you that. You need to evaluate several variables:
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. |
Posted on: October 03, 2016 11:54 PM
| Permalink |
Comments (5)
Flavors of Agile - Make it FAST
Categories:
Agile
Categories: Agile
| 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:
The roles in FAST are:
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:
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. |
Posted on: September 26, 2016 11:35 PM
| Permalink |
Comments (6)
Flavors of Agile - Do More with LeSS?
Categories:
Agile
Categories: Agile
| 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:
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. |
Posted on: September 19, 2016 03:45 PM
| Permalink |
Comments (3)
How do I Agile?
Categories:
Agile
Categories: Agile
| Nine years ago, when I signed up for the CSM class, I went into it thinking, "I'm going to learn how to do Scrum, at work." I was partially correct, and I wasn't alone. As mentioned in my last post, I don't have figures for how many people take a Scrum (or other flavor of Agile) class, expecting to know how to make it work at their company afterward, but the more people I talk to about this, the more people I find who experienced the same thing; Scrum certification classes focus on using Scrum, not on how to get the rest of your company to use Scrum. Admittedly, it is a small group. If you search the web for how to become Agile, you will get a lot of different results. Some people say being Agile is more about your state of mind than your skills. Others attempt to point out that it's not really agile to strictly adhere to one project management/development approach. A lot of online information about becoming Agile isn't that different from the CSM and CSPO training classes, in that they focus on steps to use a framework or methodology, as opposed to how to successfully transition your company to using Agile processes, which is where the pain point really lies. It can be discouraging to want to do something that can be a game changer if you are the only willing to do it. It's hard enough when you have support for the change. Don't get me wrong, I'm not saying these are useless resources. Some are very good. A couple that I found, this week, that I like are: But, it seems like if you want to learn how to transition your company to using a flavor of Agile, you have to hire a consultant/company to take you through the process. This is not necessarily a bad thing, but it could be difficult to convince company leadership and get approval for the budget. Perhaps one of the biggest reasons that it is difficult to find meaningful information on transitioning a company to Agile, freely available, is that there is no one-size-fits-all approach to doing so. I'll withhold cynical comments about it being a source of income for some companies. Some sources say, "Just get started." In a sense, they are right. If you spend your time worried that you won't be able to do it, you'll be right. So, how do you get started? I wish there was a simple answer. If all your company does is develop one piece of software for retail sale, making the transition to Agile is less complicated than it might be for a company that has multiple product lines, and multiple sales channels, in multiple global markets, with separate, yet connected, back end systems that all need regular development and upgrades. In the spirit of "just get started," are you able to run an experiment? Can you pick a team, get them trained, and run an Agile project for one of your products? If you're successful, you potentially have champions for taking this to other groups in the company. I'm not saying that this is the best approach, but it's one way to demonstrate value, if you succeed. I've said it before; transitioning to Agile is organizational change. It's risky. It's bumpy. It's hard. If you want to succeed, key ingredients are either adding value that others value (not just you), or solving a problem that is causing others significant pain. You could start top down - convince the executives that Agile is the right way to go and then drive it out to the organization - but I still recommend starting small. A big bang approach might work, but it could also magnify a single issue that is experienced by multiple teams. You need to make sure that all affected understand that it is a learning process, not an instant fix. You also need to make sure that everyone understands their part. There may only be a few roles in Scrum, but you can't run a business with just a Scrum team. At least, not a large business. There are other people who may not play a direct role in a Sprint, but they are affected by processes and outcomes and may have a voice in whether or not you continue to use your particular flavor of Agile. Considering all of the above factors, this is probably why companies use a third party to help with the transition. Even using a consultant is not a guarantee of success, but not because Agile doesn't work. Many companies have demonstrated that Agile works for them. The trainer for my CSM class related a story about a company he was working with. There were certain changes that he told them they needed to make in order to use Scrum effectively. They refused to make the changes. After considerable discussion, the decision was made to terminate the transition. This speaks to why I feel that more could be done to educate companies, not just individuals, on what it takes to be successful using a flavor of Agile. If the company leadership is not committed to making changes to how their company functions (or dysfunctions) and follow agile practices, the transition will eventually fail. Chances are, when this happens, the failure will be blamed on Agile, not on the inability of the company to change. The right mindset is an important part of making the transition. I like the approach Mountain Goat Software takes to determining when to use Agile. It's not a question of whether or not your company can use Agile (although this is a good place to start), it's which projects are suited for Agile. A company doesn't have to adopt the same agile processes across the entire organization. It may make sense for a company to have some dedicated Agile teams while the rest of the company uses other approaches. I wish I could give a simple, definitive response to "How to transition to [pick a flavor of Agile]", and not just because of potential financial implications. It's not simple, but it's worth finding out if your company can benefit from making the transition. It's worth taking a class and getting hands-on practice using it - reading about it can only do so much. It's worth starting the conversations around what Agile is and how your company can benefit from Agile principles, if not from Agile practices. You have to start somewhere; start with the conversation. Build interest. Discuss the problems you are trying to solve. Even if you don't adopt a flavor of Agile, having these kinds of conversations could lead to making changes that are needed to help your company be more successful. |
Posted on: September 12, 2016 01:51 AM
| Permalink |
Comments (4)
Scrum and the Golden Circle
Categories:
Agile
Categories: Agile
| We're going to take another detour from the Flavors of Agile and, instead, touch on a few points from the CSPO class I participated in, last week. For those of you not aware of what CSPO means, it stands for Certified Scrum Product Owner; it's the business side of Scrum. In a nutshell, the Product Owner is responsible for creating & prioritizing the product backlog, answering the developer's questions so that they know what to build, maintaining the product backlog, and accepting or rejecting completed work. I need to give a disclaimer before I continue; I consider the information taught in the CSPO class to be valuable. I'm not going to rehash the class, step by step. Instead, I will be addressing some areas where I feel more could be done. I recommend this class to anyone wanting to gain a greater understanding of how Scrum works. In fact, if you want to be a scrum master, I recommend you take both the CSM and CSPO class. Don't let the following criticisms dissuade you. Early in the class, the instructor introduced us (or re-introduced, in some cases) to Simon Sinek's concept of the Golden Circle, where you express why you do what you do, how you do it, and then what you actually do. This was in relation to developing a project vision, but I think it has larger application. I was hoping that this would be how the class was taught. It was, to some extent, but there were some pieces that I feel were missing. For starters, 'who' was missing. I like the concept of the golden circle, but who you are doing things for needs to be considered before why. The class addressed why, how, and what from the point of shortly before the first sprint planning session. The gap was the sequence of events in the early stages of a project. Who, why, how, and what are important, but in a training class, when is also important, even if it is just for one possible approach. Another gap is the notion that the scrum master is the coach for the product owner, even before the first sprint planning session. How can a scrum master coach a product owner and be responsible for making sure the product owner holds the needed meetings and communicates effectively with stakeholders (as stated during the class) when the scrum master class does not teach everything that the product owner should do, prior to the first sprint planning session? I can't coach someone or be responsible for making sure they do their job, if I don't know what that person is supposed to do. Let me be clear… I am not criticizing the instructor or the training provider. The only reason I don't praise them is that it would not be fair to associate them with my criticisms. I am criticizing the approach to how Scrum is taught which is, in large part, controlled by the Scrum Alliance. The CST develops the content, but Scrum Alliance has guidelines for it and has to approve it. If you take a Scrum class, you are learning how to use Scrum in an environment that already uses Scrum. You are not learning how to implement Scrum from scratch. You can borrow bits and pieces, but if you don't take a top-down approach to implementing Scrum across an organization, you will be lucky if all you do is fail. I'm not sure you can take a class on 'How to Implement Scrum' without first engaging a consultant to help make the actual transition. I may have to look into that. I don't fault Scrum Alliance for taking this approach. There is no one-size-fits-all approach for organizational change, and that is what implementing Scrum is. I think it would be easier for companies to recognize the benefits of moving to Scrum if Scrum Alliance was more involved in accurately defining the bigger picture of 1) who should use Scrum, 2) why they should use it, 3) how to make the transition to Scrum, and 4) what to do once the transition is made. |
Posted on: September 05, 2016 04:05 PM
| Permalink |
Comments (6)