February 14, 2017 at 12:07 am
Comments posted to this topic are about the item Quality Provides Traction/Velocity
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 14, 2017 at 3:59 am
Another developer here but I'll agree wholeheartedly. Especially as I am currently working on a system with little quality - nothing like a bit of that to encourage you to appreciate working on a system where everything is properly tied down and you can see exactly how one action causes another.
February 14, 2017 at 6:19 am
Here, here.
I think part of the problem has always been defining "productivity". Too often it's measured in lines of code or some other facile method that means absolutely nothing.
If productivity means getting product X out the door soonest, full stop, then there's way too much pressure to cut corners. Switching to the dreaded car analogy, do you want a Toyota (good, solid, boring) or do you want a Jaguar (exciting, tempermental, fast, unreliable)?
Documentation, testing, automated testing, all that takes time and serious development resources. With QA departments going the way of the dodo and proponents of the insane, constant, release cadence gaining C-level ears they're the ones getting to define productivity.
And that isn't Toyota style, that's for damn sure.
February 14, 2017 at 7:24 am
DBAs like the safe bet. In direct opposition to the mantra of "if its going to be late it might as well never turn up", many lean more towards "late is better than not getting there".
Most IT development projects are about return on investment, and whether a late deliverable still has value depends on how narrow the window of opportunity for ROI. For example, if you're scrambling to pull together an advertisement campaign in time for the Super Bowl 2017 game, then yes, an expensive add that doesn't make the cut in time is probably a total write-off. However, if you're working on the next release of SQL Server, then whether it gets released in Q2 or Q3 may not be of great significance.
I've worked for organizations in the past where payroll was occasionally late. For me personally, a late paycheck is certainly better than no paycheck.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 14, 2017 at 7:51 am
I stumbled across this concept last year, and have found it very helpful in formalizing application of the old adage "haste makes waste" specifically to software.
https://en.wikipedia.org/wiki/Technical_debt
February 14, 2017 at 9:28 am
I continue to be amazed that my fellow IT professionals can take a revolutionary concept like agile and use it to deliver the same old garbage.
Rapid delivery of working software. There is only one way to do it. Quality must be intrinsic.
February 14, 2017 at 9:37 am
GeorgeCopeland - Tuesday, February 14, 2017 9:28 AMI continue to be amazed that my fellow IT professionals can take a revolutionary concept like agile and use it to deliver the same old garbage.Rapid delivery of working software. There is only one way to do it. Quality must be intrinsic.
How do you ensure intrinsic quality? Is that built into the methodology?
February 14, 2017 at 9:45 am
February 14, 2017 at 9:45 am
john.brooking - Tuesday, February 14, 2017 9:37 AMGeorgeCopeland - Tuesday, February 14, 2017 9:28 AMI continue to be amazed that my fellow IT professionals can take a revolutionary concept like agile and use it to deliver the same old garbage.Rapid delivery of working software. There is only one way to do it. Quality must be intrinsic.
How do you ensure intrinsic quality? Is that built into the methodology?
Yes. By being part of the process; automation, testing, reviews, etc. Must be a cultural thing too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 14, 2017 at 10:03 am
GeorgeCopeland - Tuesday, February 14, 2017 9:45 AM
Thanks for that link; very helpful.
I notice that it does actually mention "technical debt", in the "Common Agile Pitfalls" section:
Allowing technical debt to build up
Focusing on delivering new functionality may result in increased technical debt. The team must allow themselves time for defect remediation and refactoring. Technical debt hinders planning abilities by increasing the amount of unscheduled work as production defects distract the team from further progress.
As the system evolves it is important to refactor as entropy of the system naturally increases. Over time the lack of constant maintenance causes increasing defects and development costs.
February 14, 2017 at 4:41 pm
Agile is evolutionary, not revolutionary. A fair few precursors are mentioned in "The mythical man month" which was written in 1975 and was observations gained over 25 years of experience.
If you adopt the disciplines it works well. If you cherry pick the bits that can be manipulated to justify short cuts aka filthy hacks, then it won't take you forward.
A great deal of releasing value early is in careful planning and design. To give an example, I am working on a project that requires a complex JSON object to be shredded out and conformed to a dimensional model. I quickly realised that I couldn't deliver the entire thing in the required time scales. Talking directly to the stakeholders gained agreement that certain facts and dimensions were required that would have near instant payback. These could be delivered relatively quickly. Other aspects required a more detailed discussion as to what would add value and why. By breaking the deliverables down into discreet items we have actually reached the point where certain items that would have been complicated to engineer are of relatively low value. These are likely to be descoped.
Compare that to pre-agile methods where we would have delayed the delivery due to the struggle with the stuff no-one really put much value on. Instead of being months late we've released value early, eliminated costs and not compromised quality.
Working in an Agile team empowers me to improve processes and approaches. It's a virtuous circle. It's not about being a cabinet maker in a flat pack world
July 15, 2019 at 5:17 pm
Having seen what a disaster pseudo-Agile can be I agree with most of the earlier comments. I have discovered though that even when a development team and a QA team are both on the same side the sales team, the marketeers, and the accountants will generally do their best to make it difficult, if not actually impossible, for any decent procedures such as proper requirements reviews, reducing release content so that the remainder is feasible with the available resources, mending the existing software rather than trying to hide its bugs behind layers of recovery attempts, and all the other common sense stuff that any real engineer with a reasonable amount of experience knows is essential for successful development and release. When all the common sense stuff is part of normal day to day operations is when real Agile development and release are happening - anything else is just not Agile. And it's that common sense stuff that ensures quality - so you can't have agile if you don't ensure both quality and flexibility (and handle the flexibility properly - to be flexible, the desired features must be separable and individually fairly small).
Tom
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply