I think that software development can learn from things like LEAN and Six Sigma. But the concepts have to be applied/mapped to the right thing.
For example, in software "keeping your area clean" does not mean keeping your desk clean. Your desk isn't the "manufacturing floor" of software. The source code is the "manufacturing floor" of software. So keeping your area clean means keeping the software clean.
James Coplien restated 5S mapped to software development:
5S for Software
Seiri (organization) - Proper naming helps you find things easily.
Seiton (tidiness) - Everything has its appropriate place. Code should be where it is expected to be, and if not, refactor to get it there.
Seiso (clean) - Leaving in commented-out code and inappropriate comments increases mental clutter that has to be overcome. Remove that cruft. Rely on version control for historical record.
Seiketso (standardize) - The group agrees on how to keep the code base clean. Consistent coding standards and patterns apply here.
Shutsuke (self-discipline) - Having the internal discipline to follow the practices and to reflect on one’s work.
Technical Debt
The biggest problem with accrued technical debt when faced with Scrum is the focus on customer value.
Since architecture has little externally visible "customer value", and iteration planning of the backlog is driven by "customer value", architectural activities such as addressing technical debt are often not given sufficient attention. (Props to Philippe Kruchten.)
The only way to avoid accruing technical debt is being willing to say "we're not done" and/or stringently following best practices of Clean Code and strong team discipline.
In the meantime, I'll pick up Donald Reinertsen's book. Thanks for the recommendation!
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Great comments and the slides from Philippe Kruchten are excellent. Thanks for sharing.
Let us know what you think of Reinertsen. I'm planning a series of posts on his book but it's such a big area, that there is plenty of room for multiple views.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
LEAN and Six Sigma
I think that software development can learn from things like LEAN and Six Sigma. But the concepts have to be applied/mapped to the right thing.
For example, in software "keeping your area clean" does not mean keeping your desk clean. Your desk isn't the "manufacturing floor" of software. The source code is the "manufacturing floor" of software. So keeping your area clean means keeping the software clean.
James Coplien restated 5S mapped to software development:
5S for Software
Technical Debt
The biggest problem with accrued technical debt when faced with Scrum is the focus on customer value.
Since architecture has little externally visible "customer value", and iteration planning of the backlog is driven by "customer value", architectural activities such as addressing technical debt are often not given sufficient attention. (Props to Philippe Kruchten.)
The only way to avoid accruing technical debt is being willing to say "we're not done" and/or stringently following best practices of Clean Code and strong team discipline.
In the meantime, I'll pick up Donald Reinertsen's book. Thanks for the recommendation!
Great comments and the slides from Philippe Kruchten are excellent. Thanks for sharing.
Let us know what you think of Reinertsen. I'm planning a series of posts on his book but it's such a big area, that there is plenty of room for multiple views.