3. www.agiletour.com05/05/09
“The primary reason is the projects have gotten a lot
Smaller.
Doing projects with
Iterative processing
as opposed to the waterfall method,
which called for all project requirements
to be defined up front, is a major step forward.”
5. www.agiletour.com05/05/09
1 Iterative, more critically Incremental
2 Releasing Working Software frequently
3 Good Delivery Cadence
4 Adaptive Planning
5 Empowers Customers with Transparency
6 Fail Fast
Elements of Agile Projects
9. What do we want to do today ?
www.agiletour.com05/05/09
Smells That We See in Agile Projects
Analysis of the Root Causes
Foundation for Lean
How Lean can help us in our Quest !
10. • No concept of
shippable software
• No adaptive planning
• No concept of capacity
or throughput
• No meaningful
retrospectives
• Quality Issues
www.agiletour.com05/05/09
11. www.agiletour.com05/05/09
Working Software frequently
Working Software as a
measure of Progress
Shorter Time scale
Trusted & Motivated Individuals
Reflects & Fine tune work
Source: Survey by Prof Laurie Williams North Carolina University, quoting from Mike Cohn’s blog
14. Theory Of Constraints
• Focus on throughput, rather than improving
individual processes
• Enables one to look at the process in terms
of the weakest link
• Manage the constraint to get a grip on the
throughput
• Enables you to have a good measure on the
Capacity
www.agiletour.com05/05/09
15. www.agiletour.com05/05/09
“Kanban to promotes flow and reduced cycle-time by
limiting WIP and pulling value through in a visible manner.”
“Kanban helps our team contribute to the business by promoting flow and
reducing cycle-time through a limited WIP and a fully
transparent value pulling system.”
“Value Pull, Limited WIP, and Visibility can create an ecosystem where
teams have the opportunity to
improve.”
Source: www.limitedwipsociety.org
16. • Visualize the Workflow
• Limit Work In Progress
• Measure and Manage Flow
• Make process policies explicit
• Use models to improve
www.agiletour.com05/05/09
Lean
19. Value Chain Clarity
• Represents the process by which a requirement is taken
into Production
• Represents the stages where value is added
Backlog Analysis Ready for Dev In Dev Dev Done In QA Atmn Done Deployed
Flow
In Process
24. Pull & One Piece Flow
• Fall out to the WIP.
oWIP triggers pull
• Pull based system ensures a
balanced work flow
• Push is never ideal as compared
to pull
www.agiletour.com05/05/09
28. Finally….
• Start slowly
• Focus on Your Value Chain
• Accurately Measure Progress
• Retrospect
• Use Stand ups to pull and adapt
• Inculcate a culture of continuous
improvement
www.agiletour.com05/05/09
Story - Start off by setting the perspective of Increasing project success Rates.
Mainly attributed to: iterative projects
Story Line: Given the dismal record Agile promised to rescue by putting the control straight with the customers.
Given the failure rates of projects, the familiar success to failure percentage Agile was a fresh breeze of air
For clients and developers Agile was a welcome change for the routine processes aka waterfall
In a era of failing project Agile promised to rescue them
Diving slightly into the basics, we would probably see some kind of iterative development. This a very familiar flow that you will come across when you talk about agile.
A process flow diagram here? Explaining the
Bite a constant chunk of scope
Development is timeboxed and is End to End
Time is the trigger for the check points
Use planning poker to determine the rough velocity
Use yesterday’s weather to forecast current progress
Use engineering practices
Navigate based on the iteration progress
flow?
Iterative, more critically Incremental
Getting working software frequently
Good delivery cadence
Adaptive planning
Empower customers with transparency
Frequent buzz words
Fail fast; No death march; Transparency; Shippable software
Clearly this marks the entry of iterative development and Agile methodologies. Agile in the scene now is a game changer.
Game changer essentially because it created a lot of transparency and gave the customer control.
Stressed mainly on incremental with iterative & the Concept of Fail fast
Redefined the entire PDCA cycle.
Story Line – Last few years have seen a tremendous increase in people’s enthusiasm to adopt Agile.
The results have been encouraging and people are jumping taking it like fish into water.
Many a times you would see folks using a variety of flavors from SCRUM to an hybrid version
Story Line – In the mad rush have we really understood the corner stones of the Agile methodology?
Initial enthusiasm slowly gives way to bitter realizations because of wrong expectations.
Sit back and ask ourselves: Is agile being done correctly? Is it just a silver bullet in all scenarios?
Wrong ideas such as: faster turn around, teams not understanding the importance of locking the scope, missing the engineering practices or not backed up with sound engineering practices, longer iterations with mini waterfall inside them.
Refer professor Laurie Williams’s Agile success criteria – Refer from Feeddemon on MikeCohn’s blog.
Mental models, single loop and double loop learning
North Carolina university survey from Mike Cohns blog
Continous Delivery of Working software
Working software is the primary
measure of progress
Shorter timescale for delivering working software
Trusted and motivated Individuals
Reflects to fine tune their work
Engineering practices
Story Line – Most of the projects don’t have frequent Cadence
Story Line – Concept of shippable software. Is the product ready to be shipped on an iteration basis?
Story Line – What constitutes Done? IS it just QA done or is it DEV and Automation.
Iterations become a mechanism to reset what has been done but doesn’t portray any meaningful cadence.
Cadence here is incremental functionality, MMFs. Velocity should portray incremental MMFs. To that extent showcases need to be rigorous and show real progress. Sometimes being dogmatic about certain practices isnt bad after all!!
Many iterations on and we still don’t see a working code. Many times the team wouldn’t spend considerable time conquering some of the basic setup activities and would have postponed them. Ex include setting up the CI, getting automation done etc
Last mile work is still pending.
Ex: On an integration project every team will do its work and the integration last mile work wouldn’t be complete
Or not being able to get a basic working copy of a build on a routine basis.
Some problems might go as deep as engineering practices – what is being done in a showcase etc?
Many a times this results in not knowing the exact quantum of work to be done for the last mile.
A follow up to the Shippable software problem:
Quote examples of projects counting velocity as a team, but as a final criteria its not effective
Smells: anytime when the teams are quoting separate velocity for DEV and QA
Velocity as throughput – do we like to see our cars shipped half done?
Have we modeled the value chain appropriately to reflect this reality?
Story Line – Team sticks to the original plan but does not revise them based on the progress
Sometimes targets that were estimated earlier would start to become targets that needs to be achieved. The idea is good, but when the whole concept of bottlenecks and constraints are missed it misses the whole point.
Team fixated to the original planned velocity without any apparent sense of actual throughput on the ground
Although this is very intuitive the bigger smell is that the team doesn’t think in terms of constraints or bottleneck
Also no one thinks in terms of teams capacity. This has wider implications in terms of quality and taking in additional inventory. We will talk about restricting inventory as one of the key benefits.
Story Line - No apparent knowledge of what a team can achieve in a time boxed iteration.
The team doesn’t think in terms of what can be achieved.
Implications include taking in more inventory. Inventory as we will see later is a form of waste. Causes more wastages.
Throughput is also influenced to a larger extent by the definition of DONE.
Story Line - Teams don’t get to do meaningful retrospectives.
They become a ritual and there is no culture of joint retrospection to learn from mistakes and put them into action.
Culture of stop the line and fix the issue from TPS
What concepts of ToC applies here?
Story Line – Promote flow, focus on value and continously improve. Don’t be dogmatic. Are there processes that will weave very smoothly into our daily routine that will make us work better?
Story Line – Lean or Kanban focusses on what typical is Waste.
Laying the foundations for the various Lean principles. For ex inventory is a waste. Anything that cant be completed, throughput resulting in lower quality is a waste.
Over production – pulling in additional work when you clearly know that you cant finish them
Implication of creating inventory is waiting – akin to low quality
Over processing
Defects
Story Line – Have a purposeful value chain that helps your realize the project benefit.
A meaningful value chain should mimic your process model. Consider examples of process flows not being complete and teams reporting velocity.
How about QA done but not deployed? Consider this as a pre-cursor for getting working software on a consistent basis.
What does DONE really signify?
DONE models your value chain
An accurate value chain modeling guarantees working software
Value chains to be meaningful needs to model the project’s reality.
As in the case above: a maintenance situation where automation was key. We were confused in our minds on how to model this. But a successful modeling to include automation mimics the reality. We started to take the app into production every month with good automation coverage.
What you see here is that the DEVs swarming to fix automation and we did not pull in additional work. This is a cultural change that you get to see very often.
Limit of 7 for a value chain
Limit reached – triggers a call for action for the team to swarm and push a story out into QA
WIP translates into action.
Team positively motivated enough to finish.
What you get is a reliable way to quickly indicate the required action at this point of time
Things get done automatically because of pull
Focus on throughput
Translates very quickly to working software.
Story Line – WIP tries to keep the Inventory low and focusses on throughput and a whole some optimization rather than individual specialization
Story Line – WIP ensures throughput thereby focussing on pull. Along with a good value chain ensures a balanced flow.
Compare this with Push which is always pre planned and doesn’t take into account variations in the system. Main reason as to why push causes lots of inventory and thereby quality issues.
Story Line – Measure accurately and various process parameters.
What do you want to measure – Does your velocity accurately portray your throughput?
Is there accurate data representing individual process performances?
Can you clearly identify where there is a wastage
Wait time vs Lead Time vs Cycle time?
Quote examples of how a long wait time coupled with the lead time helped us identify the bottleneck?
Measuring cycle time might give you instances of stories moving back and forth
What does your metrics tell you?
Do you know your capacity and throughput?
A capacity / throughput allows the team from not taking in too much to work on.
Big visible walls helps to clarify your value chain and processes. Portrays bottlenecks
