Leading the Transformation: Applying Agile and DevOps Principles at Scale Notes

My personal notes from Leading the Transformation by Gary Gruver

  • Additional reading – Many specifics referenced in this book are leveraged from a case study of transformation at HP, detailed in A Practical Approach to Large-Scale Agile Development, by Gary Gruver, Mike Young, andĀ Pat Fulghum.
  • How teams come together to deliver value in large organizations is a first-order effect. How individual teams work is a second-order effect
  • Done means
    • feature is signed off
    • defect free
    • test automation is complete
  • Software development is such a discover process that many assumptions made in planning can quickly become obsolete during development
  • Capacity of an organization to absorb change is the biggest constraint to rolling out improvements
  • Should always set objective and review at the end of each iteration
  • When estimates are off many organizations react by spending more and more in planning instead of focusing on delivering software
  • Instead of scolding people who commit on a red build, create a process that eliminates the problem
    • Usually roll back the last commit
  • Many organizations ask their manual testers to learn to automation what they have been doing manually for years. Some orgs buy tools to record what the manual testers are doing and that’s even worse
    • Record and playback is awful because if any UI changes the whole test is trash
  • An acceptance test should test one thing and one thing only.
  • All configurations should be in version control
    • You can automate checking successful deployments by querying your log management software for a successful deployment
  • Developers want to do a good job, and they assume they have until they get feedback to the contrary
  • ROI on DevOps is substantial but you will never achieve full benefit until you get your automated testing built out and integrated into the development pipeline
  • Applying DevOps principles at scale really requires the executive to drive the cultural and technical changes for improving the stability of trunk. This is vitally important because of the productivity gains that are possible when you eliminate branches and integrate all work across the teams on trunk. To get your code trunk to this level of quality and to keep it there, you need to begin using a CD pipeline with both code and component-level gating. This pipeline must incorporate a robust test automation framework. You will need to have component-based automated tests. Executives will need some simple metrics that are auto-generated each day to understand what is working and what is not so that they can focus resources in the right place every day.


Eric Ries – The Lean Startup Notes

My personal notes fromĀ The Lean Startup by Eric Ries

  • Identify where you’ve made assumptions instead of using facts. Make your assumptions facts by getting customer feedback
  • Early adopters are suspicious of something with too much polish.
    • If it’s ready for everyone to adopt how much advantage can they get?
    • Additional features or polish added is a waste
  • When in doubt simplify.
  • Any additional work beyond what was required to get feedback is a waste
  • Customers don’t care how much time something takes to build they care that it solves their needs
  • Everyone thinks their recent innovation is why the numbers went up. It’s everyone else’s fault when numbers go down.
  • Toyota Andon Cord
    • Defective change is removed immediately and automatically
    • Everyone on the relevant team is notified of the problem
    • Team is blocked from introducing any new changes
    • Root cause analysis performed
  • Dealerships sometimes have just in case inventory which cost a lot of money to keep stock on hand that we never be needed switch to just-in-time inventory and only have a one what you need
  • Use 5 why’s? to answer questions
    • “We didn’t do x”, “Why didn’t you do x?”
    • “We didn’t do x because of y”, “Why didn’t you do y?”
  • LTSE long term stock exchange

Adding java properties to Websphere Liberty

My latest project was moving a bunch of applications from running on WebSphere using Java 6 to running on Liberty running Java 8. For the most part this was pretty straightforward, but one major issue we ran into was a bean defined like so

<bean id="environment" class="org.springframework.jndi.JndiObjectFactoryBean">
  <property name="jndiName" value="java:comp/env/string/nw/environment"/>

What the heck does java:comp/env/string mean?

Turns out it’s pretty obvious once you know. It’s a JNDI Entry in Liberty (Namespace binding in WebSphere). You need to enter a new JNDI entry with a name of string/nw/environment with a value of dev, it, pt, prod, whatever your environment name is. This is generally something you’d add to a properties file, but considering this app is crazy old maybe that wasn’t an option.