I'm the Agile lead for my company and I'm trying to shorten the feedback loops for the Appian development teams I coach. They are very resistant to splitting stories and complain that the Appian platform and its object model make splitting of large stories difficult if not impossible. I keep pushing back against that narrative so they will try the experiment but continue to get resistance. I've seen no evidence in my research that supports that claim. Can anyone provide insight into whether story splitting is indeed not possible or practical for development teams employing Appian?
Discussion posts and replies are publicly visible
I try to explain the way I try to work and have great success with. I try to simplify things as much as possible.
A sprint implements a transition of the whole app from one state into another. There is no such thing as a "feature deployment" where only a small part of the app gets deployed. This just creates opportunity for trouble and issues. This is a different way than a "high-code" developer is used to. IMHO devs should adapt their way of working to a low-code environment where many project risk just do not exist, and hence, do not have to be managed.
Now, how to implement a larger feature that takes more than one sprint. If possible, just make it a larger sprint. If that is not an option, use a feature flag to disable this feature on any production environment.
I hope this helps a bit with your internal conversations.
BTW, I plan a podcast episode on this topic on https://appian.rocks.
Hi Stefan,
Thanks for the quick reply. We are employing Kanban and the programming cycle times for our larger stories often range from 7 to 14 days. During a release cycle we have late stage quality debt emerging from our testing cycles that is overwhelming our team as they try to finish the release product. My goal is to get them to split these stories into smaller vertical stories and get feedback on them within the first week of development. Though they may not provide the full desired functionality this would result in the emergence of quality debt early and reduce the build-up that we currently are experiencing.
How do you mitigate the risk of emerging late stage quality debt when using the "transition of the whole app from one state to another" model with cycle times as high as ours?
When following the idea of SCRUM, each sprint produces a working application that could be released. If any issues come up, it is not released.
Working in a Kanban style, might make teams think in isolated features, which they then start fighting for. And they do not want to release something half-baked. Accepting or rejecting a release-early-release-often approach is part of your corporate culture.
Appian does this in a great way. The new translation feature is great. I have been waiting for it since decades. And, yes, it is the first release and has some drawbacks I am discussing with the product team. That's the kind of feedback you are talking about. And yes, that requires courage. Of ALL involved stakeholders.
Keep in mind that this is a very personal opinion, based on my 14 years doing Appian projects and 25 years as a software engineer and architect.
What do others think?
I'm going to start educating myself on the Appian development model since most of my experience is in "high-code" environments. I realize that I may be asking my teams to "jam a square peg into a round hole". Can you provide me a link to the "new translation feature" you mentioned?
I highly recommend doing this. IMHO, low-code is not about just using a different tool. Yes, it is still software development, but most low-level issues that you need to somehow manage risks on, just do not exist anymore. That allows you use a more relaxed implementation model. And teams now make a different set of mistakes that you need to cover.
Switching to Appian requires change on many levels to grow it's full potential :-)
https://docs.appian.com/suite/help/23.4/translation-set-object.html
And my blog post: appian.rocks/.../