November 6, 2018 at 9:05 pm
Comments posted to this topic are about the item Wasted Work
November 7, 2018 at 9:08 am
The DevOps culture is great for allowing a continuous stream of small enhancements and improvements. Switching across to such a culture is more difficult than it appears as small incremental deployments requires business owners to think carefully and in some detail about what small incremental improvements will deliver the value. Whoever designs the resulting systems has to think carefully about how to design in a manner that allows small incremental deployments.
Delivering small increments at speed requires careful thought about how such features and functionality can be tested, and up-front, not relying on a huge manual testing operation after development.
One thing I have observed is that when a technical team switch to approaches that allow small incremental deliveries they get through one hell of a lot of work and to the extent that the team spend time twiddling their thumbs waiting for the business to decide what the next priorities are.
November 7, 2018 at 9:35 am
I can related to your point about building features that aren't used. The team that I'm on have to follow a certain pattern, when developing applications, to show the user lots of buttons, choices, etc. So many, in fact, that some of them aren't even easily discoverable, because they're not visible. You have to be told about them, otherwise you won't even know they're there. We don't do what's known as usability studies/tests, so I can't tell you for sure but I suspect that not all of the functionality is used.
The main focus of this article is waste, especially in software development. There is a lot of wasted effort, where I work now. This is hard for me to deal with. In the last couple of years I've worked on 4 new applications with some of my colleagues. Of the 4, only one of them is used today. As a team we've worked on more than 4, but I think it's only one of all of those we've built (I don't know how many that is) that is in use today. I just don't get why this is. I'd like to know if this is common.
Kindest Regards, Rod Connect with me on LinkedIn.
November 7, 2018 at 9:58 am
Rod at work - Wednesday, November 7, 2018 9:35 AM. As a team we've worked on more than 4, but I think it's only one of all of those we've built (I don't know how many that is) that is in use today. I just don't get why this is. I'd like to know if this is common.
My experience would suggest that it is common. It is particularly galling where one that wasn't used was the one where vacation time was put on hold, over time was authorised and the project was sold as essential if we wanted the world to continue rotating on its axis.
November 7, 2018 at 10:19 am
How do you handle the all too common situation where a feature is not used because it just can't be done well enough or complete enough as a small change to be useful? Releasing these as incomplete or half baked ends up providing the negative feedback leading to cancellation, when in reality, some extra effort may have provided the breakthrough required for a real game changer.
November 7, 2018 at 12:03 pm
Hmm... I don't think that dev ops should be used as a way to mitigate feature bloat in projects, that really just sounds like a recipe for projects that never end.
November 7, 2018 at 2:34 pm
ZZartin - Wednesday, November 7, 2018 12:03 PMHmm... I don't think that dev ops should be used as a way to mitigate feature bloat in projects, that really just sounds like a recipe for projects that never end.
That's not the intention. Projects are shorter, and scoped tighter. You should end up with smaller batches of work.
Having a large project is an invitation for something that's never done or doesn't really suit the customer in many cases.
November 7, 2018 at 2:36 pm
RenoChris - Wednesday, November 7, 2018 10:19 AMHow do you handle the all too common situation where a feature is not used because it just can't be done well enough or complete enough as a small change to be useful? Releasing these as incomplete or half baked ends up providing the negative feedback leading to cancellation, when in reality, some extra effort may have provided the breakthrough required for a real game changer.
For something that takes longer, you still release as smaller sections, but likely hidden or limited in ability by a feature flag/toggle. There are features in SQL Server that were released like this in Azure SQL DB, allowing some developers to use them and experiment, then a limited set of users, then a larger set.
You don't release a broken feature, but complete ones. If this takes multiple releases to get a large feature done, you scope it as larger, but most of the time you can find smaller, incremental changes that allow you to determine if the feature is moving forward.
November 7, 2018 at 4:28 pm
From the article...
I sometimes wonder if this is the right way to do things. If the users don't use a new feature, is it because they don't need the feature or is it because the feature doesn't have the needed enhancements?
For example, MS released the STRING_SPLIT() function quite a while back. It's something that I always wanted but I don't use it at all. Why? Because it's not fully developed. It doesn't return the ordinal position of the split-out elements and I almost always need that. If they had released it with the commonly needed functionality, they 1) wouldn't have to do a re-release for people to find use in the "feature" and 2) I'd have started using it the day it was released instead of bitching about the missing functionality.
If you don't make a feature truly useful on the day you release it, you may end up making a serious mistake of thinking that people don't want it because it's simply missing something.
"If it's worth doing, it's worth doing right".
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2018 at 12:31 am
Steve Jones - SSC Editor - Wednesday, November 7, 2018 2:34 PMZZartin - Wednesday, November 7, 2018 12:03 PMHmm... I don't think that dev ops should be used as a way to mitigate feature bloat in projects, that really just sounds like a recipe for projects that never end.That's not the intention. Projects are shorter, and scoped tighter. You should end up with smaller batches of work....
The idea is that projects cease to be. You have deliverables that add value and as long as the ROI keeps coming you proceed with whatever the product owner agrees is the priority. Theoretically there is no end
November 8, 2018 at 2:20 pm
Steve Jones - SSC Editor - Wednesday, November 7, 2018 2:34 PMZZartin - Wednesday, November 7, 2018 12:03 PMHmm... I don't think that dev ops should be used as a way to mitigate feature bloat in projects, that really just sounds like a recipe for projects that never end.That's not the intention. Projects are shorter, and scoped tighter. You should end up with smaller batches of work.
Having a large project is an invitation for something that's never done or doesn't really suit the customer in many cases.
True - but the model only works for some efforts. Disruptive/transformational/discovery type efforts all run into the same issue no matter hat methodology: you have to accumulate a LOT of features wile you try to put together whatever new widget it is (before you can release something complete enough to be useful), and you won't have the crystal ball to determine what it is you need 100% of the time, so waste will work, and frankly SHOULD occur. If you're too aggressive about killing off waste, or rather pre-determining waste, you will likely end up killing the truly innovative aspects.
And I understand that isn't a flaw with the methodology per se, but unless you have an incredibly wise community you can easily end up YAGNI'ing youself out of important items.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply