At the end of our last sprint, I switched my mobile team from Scrum-like to Kanban-like.
Why would I do that, and what does it even mean? Both good questions.
My mobile team has five developers, two testers, one designer, three products with both iOS and Android apps, and three product owners. Each of the product owners have other products they are responsible for, and these other products have a higher priority. I am fortunate if all three product owners are able to attend the stand-up meetings we hold three days a week.
When I took over, there was no velocity, and it became clear, fairly quickly, there wasn't likely to be. I have been able to hold retrospectives, but sprint reviews are basically demos in the Friday stand-up, and sprint planning was the first stand-up meeting of the sprint. These were 30 minute meetings. Having developers split across three time zones didn't help. The result of sprint planning was, usually, that unfinished work was rolled into the new sprint, and a few new stories were added.
I'm sure there's a strict Scrum advocate whose head just exploded, somewhere.
As a team, we decided to switch to a Kanban-like process; this is more in line with how the team works. The product owners manage their backlog. When they are ready, they move their story cards into the To-Do column, which makes them available for the developers to work on. I've got a sneaking suspicion that we may encounter some issues with WIP, but we'll work it out.
We'll continue to hold retrospectives and evaluate our process as we go. If it doesn't work, we can go back to sprints.
Overall, I like the direction we're taking. I was struggling to figure out how to make the team more Scrum-like. It wasn't until I began to understand more about how the team works that I realized it makes more sense to make the process fit the team than it does to try and make the team fit the process. I work with a great team, and I need to make sure they know that.
There are other products, in our company, that have dedicated teams. They're doing well using Scrum. If I had three different dedicated teams for my three products, I'd probably be running them all on Scrum, still.
I want to be clear about something. I am not a proponent of customizing an approach before you even try it. Scrum, out of the box, can work great. As you use it, you may identify constraints and will need to choose to either eliminate the constraint or change the process.
Being agile isn't about strictly using Scrum, or Kanban, or some other flavor of agile. There are no methodologies or frameworks mentioned in the Agile Manifesto. An important part of agile is experimenting; learning how to deliver value more quickly than you've done in the past. Where you end up may not look the same as where you start, and that's okay.
Where are you on your Agile journey?
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.
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:
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
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:
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.
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.
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.