This checklist is comprised of 48 items you can use to gauge the maturity of your software delivery competency, and form a baseline to measure your future improvements. It’s not meant to say “you’re failing DevOps” or deprive you of a badge (make yourself a badge just for reading this!), but surface areas of potential improvement.
you can check here
Before introducing this Sonar plugin, here are few funny and relevant quotes on the concept :
Maintaining an application without any unit tests is like borrowing money each time you add or change a line of code
Skipping design phase is like borrowing money to get a very “quick” and “predictable” return of investment
Refactoring is like paying down the principal
Development productivity decreases when interests grow up
Managers don’t care about code quality, just ask them to pay the debt in order get their attention
Bankruptcy is logical extension of technical debt uncontrolled… we call it a system rewrite
Full article is here
The application of the product owner role varies greatly, as products and organisations differ. But Roman Pichler argues in this blog post, there are two key factors that determine the duties of a product owner: the scope and the depth of ownership.
A Great Product Owner…
Embraces the product vision. A great Product Owner represents the customers voice and creates a product vision together with the stakeholders. Every decision is taken with the product vision in mind. This ensures sustainable product development, provides clarity for the development team and increases the chances of product success drastically.
more is available here
I’ve almost forgot the 5th birthday of leanlabs.com
First post was Jack be Agile – Jack be Lean
Must-Read Books on the History of Software Engineering really cool list!
i’ve started with
Complexity is the main hurdle which we need to overcome.
Really great article
• OKRs ! = PRM directly
• Q based
• Good data points.
• OKRs are public; everyone in the company should be able to see what everyone else is working on (and how they did in the past)
• Objectives are ambitious, and should feel somewhat uncomfortable
• Key Results are measurable; they should be easy to grade with a number (at Google we use a 0 – 1.0 scale to grade each key result at the end of a quarter)
• The “sweet spot” for an OKR grade is .6 – .7; if someone consistently gets 1.0, their OKRs aren’t ambitious enough. Low grades shouldn’t be punished; see them as data to help refine the next quarter’s OKRs.