Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

At2010 lean ideas for agile v5 1

on

  • 628 views

Slides from my presentation on the application of lean ideas for Agile Project Management.

Slides from my presentation on the application of lean ideas for Agile Project Management.

Statistics

Views

Total Views
628
Views on SlideShare
622
Embed Views
6

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 6

http://www.linkedin.com 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 airFor clients and developers Agile was a welcome change for the routine processes aka waterfallIn 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 theBite a constant chunk of scopeDevelopment is timeboxed and is End to EndTime is the trigger for the check pointsUse planning poker to determine the rough velocityUse yesterday’s weather to forecast current progressUse engineering practicesNavigate based on the iteration progress flow?
  • Iterative, more critically IncrementalGetting working software frequentlyGood delivery cadenceAdaptive planningEmpower customers with transparencyFrequent buzz wordsFail 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 fastRedefined 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 blogContinous Delivery of Working softwareWorking software is the primary measure of progressShorter timescale for delivering working softwareTrusted and motivated IndividualsReflects to fine tune their workEngineering practices
  • Story Line – Most of the projects don’t have frequent CadenceStory 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 etcLast 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 completeOr 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 effectiveSmells: anytime when the teams are quoting separate velocity for DEV and QAVelocity 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 progressSometimes 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 groundAlthough this is very intuitive the bigger smell is that the team doesn’t think in terms of constraints or bottleneckAlso 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 Kanbanfocusses 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 themImplication of creating inventory is waiting – akin to low qualityOver processingDefects
  • 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 chainAn 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 chainLimit 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 timeThings get done automatically because of pullFocus on throughputTranslates 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 wastageWait 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 forthWhat 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

At2010 lean ideas for agile v5 1 At2010 lean ideas for agile v5 1 Presentation Transcript

  • Lean Concepts for Managing Agile Projects
    Govindarajan S
    Thoughtworks India
    2010 October
  • www.agiletour.com
    05/05/09
    From the 1994 levels
    100%
    an
    Increase in Project Success Rate
    34%
    Source: Standish Report on project success rate
  • www.agiletour.com
    05/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.”
  • www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
    Elements of Agile Projects
    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
  • www.agiletour.com
    05/05/09
    Game Changer
  • www.agiletour.com
    05/05/09
    Increased Adoption
    35%
  • www.agiletour.com
    05/05/09
  • What do we want to do today ?
    www.agiletour.com
    05/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 !
  • No concept of shippable software
    No adaptive planning
    No concept of capacity or throughput
    No meaningful retrospectives
    Quality Issues
    www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/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
  • www.agiletour.com
    05/05/09
    Cadence
    Ship SW
    DONE
  • www.agiletour.com
    05/05/09
    Adaptive Planning
    Throughput
    Reflect
  • 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.com
    05/05/09
  • www.agiletour.com
    05/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
  • Visualize the Workflow
    Limit Work In Progress
    Measure and Manage Flow
    Make process policies explicit
    Use models to improve
    www.agiletour.com
    05/05/09
    Lean
  • www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
    Purposeful Value Chain
  • Value Chain Clarity
    Backlog
    Analysis
    Ready for Dev
    In Dev
    Dev Done
    In QA
    Atmn Done
    Deployed
    Flow
    In Process
    Represents the process by which a requirement is taken into Production
    Represents the stages where value is added
  • Meaningful Value Chain
    www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
    Limit Requirements processed
  • www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
    WIP Addresses
    Throughput - Guarantees MMF at the end
    of the cycle
    Keeps Inventory Low and guarantees Quality
  • Pull & One Piece Flow
    Fall out to the WIP.
    WIP triggers pull
    Pull based system ensures a balanced work flow
    Push is never ideal as compared to pull
    www.agiletour.com
    05/05/09
  • www.agiletour.com
    05/05/09
    Precise Metrics
  • www.agiletour.com
    05/05/09
    What do you measure ?
  • www.agiletour.com
    05/05/09
  • 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.com
    05/05/09
  • www.agiletour.com
    05/05/09
    Questions ?
    govinds@thoughtworks.com
    Credits: Stock Photos – www.sxc.hu