Long before the Agile revolution for software development began, industry had learned that efficient production of goods required intense attention to quality, teamwork, and continuous improvement. These themes of Lean Manufacturing (which was further refined into the Toyota Production System) were never part of the original formulation of the Agile Manifesto, and are rarely mentioned as part of the traditional Agile/Scrum recipe for teams transforming to the new “Agile” mindset.

The reality is that the traditional Agile/Scrum recipe is actually a “dumbed down” version of the Toyota Production System, and makes it easier for organisations to grasp and start from. However, if organisations really want to achieve the goal of producing the software they need in a fashion that leads to High Performance Teams and Sustainable Engineering, they will need to understand the principles of Lean so they can incorporate them into their unique process. This session teaches the basics of Lean, and demonstrates how they apply to Agile development.

 
2 favorite thumb_down thumb_up 7 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

The deck as assembled now contains the following sections:

  • Definition of the problem, both in terms of understanding that development efforts are only one part of the organization's issues (the business of the company is not making software, but creating value for customers, etc.)  [this section takes about 10 minutes to go through comfortably - in SDD2014, the questions started early and this probably took around 15 minutes.  This time around, I think I could trim a couple of minutes, be more presentational (less "and what are your issues in this area?" and do it in 8 minutes]
  • Definition of where Agile adoption is in terms of Moore Chasm crossing, with most organizations that are not "Agile" being in the late majority to laggard space.  How to embrace those harder to reach organizations by a return to Lean principles of the Toyota Production System. [this section is rather quick - around 10 minutes - at SDD2014, I told a bunch of stories and probably took around 20 minutes through this section, but the audience was comfortable jousting with me.  However, this time around, if I adopt a similar "present, but refrain from teaching" approach, I can forcast 8 minutes]
  • Discussion of the seven deadly wastes of Lean  [this is the section where the greatest amount of audience engagement in terms of questions and discussion occurs, and what distinguishes this session from a standard presentation]  [this is the meat of the presentation, and takes around 30 minutes - at SDD2014, we had a lot of side discussions and spent 40 minutes in the section.  This time around, I want to take the 4 sections of each waste and make the first two into just quick reviews.  I think that can get through each waste in 3 minutes, making the total time 20 minutes.  The Vasa story will go.]
    • What the waste is and why it is bad
    • Where the waste occurs in software development
    • How Agile/Scrum attacks the waste
    • What Agile/Scrum misses and what we have to consider to make it work in the audience's organizations
  • Concluding and final remarks [this section takes about 10 minutes to go through - however, at SDD2014, I told around 3 stories behind the slides and engaged heavily in Q&A, which took us about 15 minutes (just finishing within the alloted 90 minute slot at SDD2014).  This time around, I can stay at 10 minutes.]

Learning Outcome

  • Agile/Scrum is having difficulty in reaching late adopters and laggards, and a return to Lean Toyota Production waste reduction princples helps.
  • Agile/Scrum addresses some, but not all of the wastes seen in software development.  Understanding where the missed areas are helps organizations that are currently using Agile/Scrum but are "hitting the wall" with ideas for how to continuously improve
  • Team (and silo) efficiency is good, but organizational effectiveness is better.  Organizational effectiveness is also necessary to reach the business's goals.

Target Audience

Organizations that are having problems making Scrum and other "easy to digest" pre-canned processes work, as well as any organization interested in improving will benefit from understanding the values and principles discussed in this session.

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  3 years ago
    reply Reply

    Thanks for the proposal, Howard. Can you please update your Outline section with the time-wise break-up of the topics? IMHO keeping the audience engaged for a 90 mins talk can be extremely hard.

    • Howard Deiner
      By Howard Deiner  ~  3 years ago
      reply Reply

      Thanks for making me think this through, Naresh!  When I gave this presentation at SDD2014, it filled the full 90 minute slot (and then some - discussions continued into the hall).  However, there may well be a difference in audiences.  The SDD crowd is very engaged and talkative.  I've noticed that many audiences I've seen in the Agile India conferences seem much more reserved.  Thinking about that, and looking carefully at the material, I think I can do this well in a 60 minute segment (assuming that I don't solicit and "bait" the audience into engaging with me).  It wouldn't be too terrible to cull down a few of the examples and stories as well (I put the Vasa story in the SDD presentation because I knew that architects would appreciate it - only one person at the conference had ever heard of the Vasa before, and didn't know the reference).  In any case, shorter might well be better.

      • Naresh Jain
        By Naresh Jain  ~  3 years ago
        reply Reply

        Thanks Howard. Request you to please update your proposals accordingly.

        • Howard Deiner
          By Howard Deiner  ~  3 years ago
          reply Reply

          Hi Naresh!

          I put a tag in for a 60_min session, but when I went to update the length, I realize that there are only 45 minute ones.  Should I cut it down further, or will you be able to fit a 60 minute session in?

          • Naresh Jain
            By Naresh Jain  ~  3 years ago
            reply Reply

            Thanks for accommodating our feedback Howard. Yes we only have 45 mins session, so would request you to bring it down to 45 mins. Also I noticed that the total time (as per your current breakup) comes up to 85 mins. Please have a look.

            • Howard Deiner
              By Howard Deiner  ~  3 years ago
              reply Reply

              SDD2014 was 15+20+40+15 = 90 minutes

              I am comfortable with 10+10+30+10 = 60 minutes.  I believe that the current material can be presented well in that timeframe without losing the essence of the messages.

              To cut it to 45 minutes, I'll have to think for a day or two as to what to leave behind.  Let me think that through before I commit to that.

              • Howard Deiner
                By Howard Deiner  ~  3 years ago
                reply Reply

                Hi Naresh!

                I'm pretty sure that I know where the fat is in the presentation now.  This can be done in 45 minutes and still have the impact that is needed.  I still get to keep my "Drachten" story at the very end ("many times we do better by controlling less").

                Thanks for making me think!  ;-)


  • Liked Howard Deiner
    keyboard_arrow_down

    Howard Deiner - Agility at Scale - Platform versus Product Concerns

    45 mins
    Talk
    Intermediate

    A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood.

    This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.

  • 45 mins
    Experience Report
    Intermediate

    Over the last decade, eXtreme Programming practices like User Stories, Evolutionary Design, Test-Driven Development (TDD), Behavior Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work.

    Having experienced various benefits from XP practices on our J2EE stack, our team started to apply these practices to extract, transform, and load (ETL) and Data Analytics side of our product. Unfortunately, there is very little guidance available in this context, esp. for the SAS Platform. Right from finding the unit testing framework to structuring the code to designing our modules and setting up a Continuous Integration builds, our team had to figure out everything, the hard way.

    Join us to understand the challenges we faced during this process and how we resolved these challenges.

  • Liked srinivas chillara
    keyboard_arrow_down

    srinivas chillara - Architectural hiccups (and you really shouldn't bother with sprint-0)

    45 mins
    Experience Report
    Intermediate

    While design changes can be made as we go, sprint on sprint, the poping up of architectural changes seems insurmountable. It is need not be so.

    In this session, we provide a narrative of an online gaming product developed. This is a massively multi-player online game, for casual as well as professional players (with real sustantial money). Such a product needs to grapple with non-functional imperatives well beyond the run of the mill server-side software. As the project progressed new performance and security imperatives materialised.

    How the  team made adjustments in face of changing non-functional (and some perculiar functional) imperatives is the focus of this talk.

  • Liked Nilotpal Das
    keyboard_arrow_down

    Nilotpal Das - Head First Agile and Organizational Transformation

    45 mins
    Experience Report
    Intermediate

    This is a collection of real time case studies of failed projects. It is an autopsy of these failed projects studying why these projects failed and how application of agie principles could have saved them.

    It is also a study into the organizational culture, behavioral attributes and the people issues and how agile addresses them.

    And finally it is a study of why doing a few projects with agile is not sufficient. How complete organizational transformation into agile practices is necessary for long term success for projects, processes and people.

  • Liked srinivas chillara
    keyboard_arrow_down

    srinivas chillara - Save our Ship, less is more

    20 mins
    Talk
    Advanced

    Scrum of Scrums has a mixed record of effectiveness. The vast majority completly miss the point of stand-ups and Scrum of Scrums. The last few years have seen unscrupulous consultants sell all sorts of pills for the ills of scaling. If a project needs more than 15 people, it is crucial one understands the Central issue of scaling. 

    In this talk I take the audience through the common pitfalls and explain the irrelavance of the question: "How can we scale agile?"