A developers review and small changes to the 12 principles of agile.
Feel free to disagree with my opinions in the comments.
Working Software
Working software is the primary measure of progress.
This might sound incredibly obvious at first glance, but it is very common to see developers and managers alike try and add other measurements.
Anything along the lines of...
- It's almost done just a small bug left
- I have it locally but I just have to upload it
- It is like 90% done so almost there
- My work is done but waiting on another group
Do not count, unless our users can actually use the feature or bug fix it does not mean anything.
Revised
Working software our customers can use is the primary measure of progress.
My only change was to add our customers can use which is to prevent comparing to alternate instances of your product that is not available to the general public. An example would be running a stage instance of your app and counting that as progress.
There are huge benefits to having these stage or review copies so I do encourage them, but until your customers can take advantage of your work you have not progressed your product.
Sustainable
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Agile is all about long term development, we are iterating, polishing, refactoring and collaborating for extended periods of time. None of that would be possible if we burned out or quit.
The manifesto or principles of agile do not mention any tips or tricks to accomplish this, so it will have to be up to your team on how we go about keeping a steady but sustainable pace.
Scrum and Kanban both have rules to try and accomplish this. Although, I think both fail to truly create a sustainable pace and instead try and squeeze out every bit of work possible.
Revised
Agile processes require sustainable development.
The sponsors and developers should be able
to maintain a constant pace indefinitely.
Just two changes on this one, first swapping promote for require.
Promote to me is a little too relaxed for what I believe to be an absolute requirement.
Second, I removed users from the second sentence. It just felt a little strange including users in the principle about sustainable work.
Quality
Continuous attention to technical excellence
and good design enhances agility.
I shortened this principle to simply quality as it just that. By building the best product we have the ability to change focus, design or feature set easier than if we wrote bad code.
Or on the opposite end of the spectrum, if you write bad code ( or have a bad design, etc ) it will be much harder for your team to transition to different features. Typically, teams will opt for rewriting large portions to not have to deal with the bad code.
Revised
No changes, I agree with this one fully. If anything I would simply add more points as to why this is true. But as the principles themselves are typically very high-level concepts I would only make it more complex.
That is all for the third chapter. Thank you for reading.
Top comments (0)