KCDC - Live & Breath Agile
23
Shahzad Zafar Manager, Cerner Corporation @m_shahzad_z, @CernerEng
-
Upload
shahzad-zafar -
Category
Software
-
view
127 -
download
0
description
It is very easy for teams to claim that they are practicing Agile development. This talk will focus on the differences of simply practicing Agile ceremonies and living and breathing Agile. The best way to learn Agile principles is to jump into the deep end and to start practicing it. However, a common issue teams run into is where there is too much focus on the Agile Ceremonies and not enough on whether the team’s practices support Agile principles. Practices such as too many capabilities in progress, not meeting iteration commitments, long release cycle, number of defects, technical debt and lack of planning are some of the red flags that teams can look at to gauge themselves. In this talk, we will go over how to identify these red flags and also go over ideas of how to fix them for your teams. At the end of this talk, you will be able to walk out with a roadmap of changes you can implement, to take your team from simply practicing Agile to living it.
Transcript of KCDC - Live & Breath Agile
Shahzad ZafarManager, Cerner Corporation
@m_shahzad_z, @CernerEng
Individuals and interactions
over processes and toolsand we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact
Working software
over comprehensive documentationas long as that software is comprehensively documented
Customer collaboration
over contract negotiationwithin the boundaries of strict contracts, of course, and subject to
rigorous change control
Responding to change
over following a planprovided a detailed plan is in place to respond to the change, and it is
followed precisely
http://www.halfarsedagilemanifesto.org/
We have 2 week iterations…
But have not released anything major in 6 months/1 year/ 2 years…
We work on capabilities…
But all of them are in progress
Because they all have deadlines
And everything is #1 priority
And process requires us to finalize requirements w/ our clients
And scope is constantly changing
Lack of Communication
Undefined Scope
Poor Quality
Technical Debt
The most efficient and effective method of communication is face-to-face conversation.
Working software is the primary only measure of progress.
Deliver working software frequently
Whenever possible, value = user adoption
Definition of done = released, even deployed
Release cycle should be in days and weeks
Starts with effective quality◦ Track defect trends and keep them in control
◦ Root cause for defects
◦ Automated testing
Continuous integration
Unit, integration, black box
Deployment validation
Starts with effective quality◦ Software half-life
Refactor half of your software in x amount of time
Hardening software over time.
Limiting work-in-progress (WIP)
Limiting WIP is done by effective planning
Review Roadmap frequently ◦ Stop projects not top in the list
◦ Adjust priority based on perceived adoption
◦ Force the priority discussion
◦ Have product owners involved to define the high level scope
Let the teams work out the details
Track changes to the plan◦ Do root cause on frequent changes
Have a short and long term plan◦ ~3 months details
◦ 3 to 6 months more high level
◦ Beyond that just placeholders
That is process, focus on principles
http://doodlealley.com/2011/08/27/pr
inciple-vs-process/
