An important part of being agile is to be in a near constant state of being ready to ship working software that delivers value to customers.
This means we must have very efficient mechanisms to put the software in peoples hands and just as importantly to verify it is working as intended.
In reality the only way this is achievable is via the effective use of automation, you need talented people to collaborate to construct great software, you need automation to ship great product.
Don't Rely People For Quality
Any production pipeline needs to ensure the quality of the product its producing, first and foremost this comes from employing good people, but even good people can make mistakes and any form of collaboration can result in misunderstanding or differences in approach.
For this reason our pipeline needs certain quality gates to ensure any sub-optimal changes are routed out and fixed and that certain standards are maintained. Traditionally this has been provided manually by things like code reviews and QA testing, if these are your only quality gates you will find it very difficult to be agile and you will ship defects.
Software is complicated, people will make mistakes when their implementing it and people will miss things when they review and test code.
Defects are very often subtle, performing a code review is not like checking someone's spelling or grammar it can be very difficult to truly asses how software will perform purely by reading the source.
What we need is the cold calculating eye of automation, automated testing and analysis will never miss something because it needs another coffee or because its being distracted by a Product Owner.
Automated quality gates will apply the same rules every time and always take the same amount of time to give code a clean bill of health or point out its failings.
Don't Rely On People For Output
The only way we can be ready to ship at a moments notice is by not needing to be given notice that a build of our code is needed.
Within an agile team their should be no concept of needing to ask someone to put together a build.
Pulling together changes from multiple work streams, coalescing it into one unified body of code and getting it ready to ship is a complicated and potentially time consuming process.
If left up to individuals mistakes will be made and you will find yourself having to ask "is the build ready yet, we need to ship!".
Instead builds and output should just happen, when new code is available it should be incorporated into the product, built, tested and put into peoples hands without anyone lifting a finger.
Once again the machinery of automation will ensure the same unwavering processes are being applied to every single build, all the time.
Let People Be People
So if we shouldn't rely on people to ensure quality or to produce output what should we rely on them for?
Their a certain things we can't automate, we can't automate creativity, we can't automate problem solving and we can't automate enthusiasm to produce value for customers.
We need developers to come up with the engineering that will make our product vision a reality.
We need testers to explore our product, to be the people asking the "What if" questions and be striving to make improvements that will increase the value we're delivering.
In an agile team tasks that are mundane, repetitive and time consuming should be automated, machines are better and faster at these types of tasks and their output will be reliable and unwavering.
For everything else we need to utilise the skills that only people can bring and make sure they can spend the majority of their time utilising these skills.
No comments:
Post a Comment