Agile: Developing Software at the Pace of Information
With the explosion of technology in our increasingly connected world, product realization processes must to evolve and adapt in meeting customer expectations, and exploit ever-narrowing windows of market opportunity. While traditional software delivery processes have served us well, there is a belief that these predictive methods – known as ‘Waterfall’ – have reached a plateau, and cannot sustain in our adaptive wired future.
Agile software development methods have been increasingly adopted by companies worldwide, often affording a competitive advantage in the process. But what is it about Agile methods that truly resonate, and how do these processes enable product realization in better, faster, and cheaper ways? How can companies be confident they are truly ‘being’ vs. ‘acting’ Agile, and are achieving the benefits promised by industry studies?
In this session, we’ll start with the heartbeat of Agile – the four key values and twelve key principles of the Agile Manifesto. From there, we will introduce the Scrum cycle, demonstrating the lean economics of combining iterative and incremental development through adherence to ceremony and cadence. We will dive into opportunities Agile development creates in the DevOps space – as well as what impedes DevOps from achieving agility in today’s environment. Real world examples will be shared to help foster understanding of how goals were achieved – and how they can be leveraged for your particular business culture or climate.
Agile: Developing Software at the Pace of Information
1. Agile: Developing Software
at the Pace of Information
STEVE NUNZIATA, PMP, ACP, CSM, CSP, SAFE SPC
PRINCIPAL AGILE COACH, BLUE AGILITY
APRIL 9TH, 2015
5. Why Agile?
$1 Billion Dollar Writedown
NO Customer Feedback
“there's no reason to buy the Surface. Between
the confusing Windows 8.1 interface and its lack of
apps, you're much better off with the iPad, Nexus
7, or just about any other Android tablet.”
Quote: http://www.businessinsider.com/surface-2-review-2013-10
6. What is ‘Agile’, Anyway?
Adaptive planning
Evolutionary development
Early delivery
Continuous improvement
Rapid and flexible response
to change
7. The Agile Manifesto – A
Statement of Values
Individuals and
Interactions
Working
Software
Customer
Collaboration
Responding to
Change
Processes and Tools
Comprehensive
Documentation
Contract Negotiation
Following a
Plan
OVER
OVER
OVER
OVER
8. The 12 Agile Principles
Image: http://www.nwizard.ro/programming/12-principles-of-agile-software-development/
10. Agile Adoption & Maturity
“nine women can't make a baby in one month”.
Fred Brooks, “The Mythical Man-Month”
11. And to Prove it - Quotes from ‘The Field’
“We have our Daily Standup every Friday.”
“We demonstrate our work every two weeks,
just without the primary customer.”
“No, really, the project was 90% complete last week.
Now we’re about 60% complete.”
“Our first Sprint was Analysis, our second Sprint
was Design... We hope to Code in our third.”
12. Takeaway: What is Agile?
Image: http://www.agile-minds.com/agile-defined/
16. Value of Small Batches
Reduces Risk & Variability
Shortens Cycle Time – Market & Feedback
Co-Location (Information Exchange)
Good Infrastructure – Critical to Sustain
24. Quotes from ‘The Field’ - Revisited
“We have our Daily Standup every Friday.”
“We demonstrate our work every two weeks,
just without the primary customer.”
“No, really, the project was 90% complete last week.
Now we’re about 60% complete.”
“Our first Sprint was Analysis, our second Sprint
was Design... We hope to Code in our third.”
26. DevOps - Defined
Handshake between Development and
Deployment Operations
Developers are agents of change;
Operations generally averse to change
(system down time, etc…)
Deployment processes may introduce
new defects and incompatibilities
27. DevOps – Impediments to Agility
Operations often involved late in
the product development cycle
Time and effort to configure and
enable Production-like systems
Conflicting Metrics & Measures
….disrupts flow!
28. Opportunities for DevOps
If releasing is expensive
& risky, we release
seldom.
If releasing is cheap & safe, we
release often.
LARGE BATCH
SMALL BATCH
29. Opportunities for DevOps
Utilize Near
Production
Systems -
Frequently
Validate
System
Quality -
Continuously
Deploy
Frequently
with
Repeatable
and Reliable
Processes
Rapid Service
Virtualization
(Cloud)
Collaboration
between
Developers
and
Operations
Teams
31. Alamo Agilistas
Next Meetings:
Thursday, May 14th @ Perico’s I-10
“Scaling Professional Scrum”
Friday, June 19th @ The County Line, I-10
“Developing Software at the Pace of Information”
Sign up on EventBrite - $10 discount code for May –
‘InnoTech’
Sign up for the group on LinkedIn – Alamo Agilistas
32. Alamo Agilistas
Agile Summer Nights Series!
Wednesday Nights @ Geekdom, San Antonio
(see site for details)
5/27 Information Radiators
6/10 Agile Planning
6/24 The Agile Leadership Journey
7/08 Kanban
7/22 Dev Ops
8/05 Agile Engineering Practices
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”.
Q: what have you heard? What words spring to mind when you hear the term?
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.
Very Developer-Centric. Doesn’t speak much towards organizational Agility.
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”!
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.
Summary of section 1.
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!)
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.
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.
Compare – are we on time/ on budget? How do we know?
Q: How many large batches can you see?
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).
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.
The longer the queue, the higher the wait time, and the higher the variability. See: little’s law.
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.
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.
Let’s revisit – what’s the problem with these?
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.
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.
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.
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.
LinkedIn Group – Alamo Agilistas
This presentation will be given again on Friday, June 19th - @ the county line, 11:30 am.
Free Agile Education classes. Sponsored by Tek Systems / supplying pizza.