Agile: Developing Software at the Pace of Information

Editor's Notes

• #5: Greenland's Jakobshavn Glacier is Moving 10 Miles Per Year, Recording-Breaking Speed (February 2014) Inherent problem – the PACE of information is far greater than 10 miles per year. Talk about the finite end to the product life cycle. By the time you get to production – the market opportunity has passed you by… “Achieving Failure”.
• #7: Q: what have you heard? What words spring to mind when you hear the term?
• #8: That is – we value those on the left side more than the right side. Shift from a prescriptive (waterfall) to adaptive (agile) perspective. At NASA - The requirement of minimizing risks and errors was believed to have more business value than increasing quality, productivity, and flexibility. Ultimately – Apollo 13 – had to work in small batches to solve unanticipated problems/opportunities.
• #9: Very Developer-Centric. Doesn’t speak much towards organizational Agility.
• #10: The collection of Agile methodologies make up the Agile umbrella. Any methodology that supports the principles stated in the manifesto could be considered ‘Agile’. Scrum is the most widely adopted Agile methodology out there today. Kanban, XP, Scrumban, are also showing up on the radar. The Scaled Agile framework is also gathering steam, but it is not a methodology, per se, but employs several Agile methodologies to achieve its organizational objectives. Note – NONE of these methodologies are ‘complete’! Therefore – recognizing Agile principles and understanding the heart and intent of Agile is critical to help organizations “fill in the blanks”!
• #11: Management – very impatient with Agile adoption. Expensive to change; impatience. Need nurturing to grow – like a child. Shu/ha/ri – steps towards mastery. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. No deviation. Obey tradition. In ha, once we have disciplined ourselves to acquire the forms, we make innovations. in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws. Separate and transcend.
• #13: Summary of section 1.
• #16: Knowledge – is also a batch. Communication. Echoed in Manifesto. Q: What’s the value of the Daily Standup? (A: small (daily) batch of information exchanged!)
• #17: Common large batch sizes: 1) Project Funding; 2) Project Phases (Trad. Waterfall); 3) Requirements Definition; 4) Project Planning 5) Testing Shortens cycle time –Netscape example. Eric Ries – Lean startups – try to work with smallest batches possible, with the goal of gathering feedback to determine future direction.
• #18: Q: How do you know what the appropriate batch size should be? There are economics behind those types of decisions. The larger the batch, the higher the cost – to hold, warehouse, etc.. Like too much WIP in software development. At risk for going stale before completion. Realize batch size should be set optimally – NOT just ‘smallest’. Factor the economics into the optimal batch size. Problem is – especially in DevOps – processes along the software development continuum are established and optimized for LARGE batches to come through.
• #19: Compare – are we on time/ on budget? How do we know? Q: How many large batches can you see?
• #20: Scrum – 3 core roles (SM/PO/Team), and 4 ceremonies (Sprint Planning, Daily Standup, Demonstration, Retrospective). Very easy to understand – but very difficult to master. Key: not just working software (small batch), but LEARNING CYCLES (small batch info re: product).
• #21: From Oosterwald’s “The Lean Machine”. The more learning cycles you go through, better the chance at success. Problem with waterfall – test and fix loops happen way too late – QA. Cause for failure. Death march projects – causes collateral damage across the organization. Companies move into ‘firefighting’ mode – and often never get out. Becomes a death spiral.
• #22: The longer the queue, the higher the wait time, and the higher the variability. See: little’s law.
• #23: Our processes are set up to support long queues, and potentially miss market opportunity by an inability or slow response to ‘jump them’. A backlog is NOT supposed to be a queue, but a list that can be drawn from quickly as opportunities arise.
• #24: Optimization – compounds the problem. Even adding a single project to your workload is profoundly debilitating by Weinberg's calculation. You lose 20% of your time. By the time you add a third project to the mix, nearly half your time is wasted in task switching.
• #25: Let’s revisit – what’s the problem with these?
• #28: Involved late – lack of collaboration - two fold problem. People, in that DevOps is just getting wind of changes. Second, they are receiving a large batch to implement. And, we know large batches introduce variability. Large batches also create queues, which may impede other efforts from implementing.
• #29: Kniberg showed the vicious cycle of most release processes in place. Releasing is hard, so you release seldom. Because you pile up so much stuff to release, releasing it becomes hard, of course, and this is where the vicious cycle closes. On the other hand, if you make releasing easy, you release more often automatically. One way Spotify achieves this is by decoupling as much as possible.
• #30: 1 (Shift Left) Develop & Test against systems that behave like production. short batches mitigate variability. 2 System Quality – have a set of automated tests to execute against the systems to ensure integrity. 3 Have automated deploy scripts and use them frequently – keep batch sizes small, and prevents queues from building. Also validates the deploy process. 4 service virtualization (cloud). Stand up systems rapidly and on-demand. 5 (Team Level) – have Operations resources sit with, and work with, development teams to shorten the communication loop! Drive towards collaboration towards a common goal of enabling business success.
• #31: Key to success with Agile – break down big batches wherever you see them – legal, MX, UI, DevOps. Enable product flow. Employ lean economics in decisioning. Agile is a journey, not a destination. Shu, Ha, Ri – learn the basics – but don’t be afraid to move towards mastery and evolve Agile in your space.
• #32: LinkedIn Group – Alamo Agilistas This presentation will be given again on Friday, June 19th - @ the county line, 11:30 am.
• #33: Free Agile Education classes. Sponsored by Tek Systems / supplying pizza.