Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
What is Waterfall?
Categories:
Agile
Categories: Agile
| 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:
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:
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. |
Posted on: October 11, 2016 02:26 AM
| Permalink |
Comments (3)
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)