Skip to Content


At SAPTechEd 2009 I (@dparnas) sat down with SAP Chief Community Evangelist Mark Finnern to discuss how Lean, Agile and Scrum adoption will shape the company of the future. This is a part of a broader debate the @sapmentors have done internally.


Key talking points:

  • Brief introduction to Lean, Agile and Scrum
    I really don’t do them justice in the short time frame, so if interested check out more thorough sources on Lean,Agile and Scrum 
  • Bringing Waste to the surface
  • The waste of projects
  • Focus on business value by looking at business processes and the tools that support them as a whole
  • Empower the Scrum team as a whole
  • Individuals using the power of their network outside the enterprise
  • Avoiding “projects” with only technical success: Great landing, wrong airport


PS If the video for some reason isn’t embedded into this blog, go to, select “Wednesday, October14” and select Dagfinn Parnas on the Company of the future.


PSS Sorry about the intro music, I can assure you it was not my choice 🙂

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    I enjoyed the interview. It was great meeting you at teched. I am doing my new project in an agile method, and will reach out to you for some advice pretty soon
  2. Mark Finnern
    Hi Dagfinn,
    Next to seeing all the SAP Mentors in the blue rugby shirts, the interview with you about scrum and agile was the highlight of my TechEd in Phoenix.
    I really think you brought out the implications of using that methodology.
    Thanks Zia for challenging the SAP Mentors to think about the company of the future, which lead to this crystallization.
    After we were done you said to me, that we didn’t talk a lot about the company of the future.
    Actually I think that lean and agile is a wave that will in one form or another tough every company if they want to stay competitive.
    You made it really concrete of what the future will bring and what to look out for when implementing lean in an enterprise.
    Thanks, Mark.
  3. Rüdiger Plantiko
    Nice prospective – I am looking forward when “agile” finally will land in my company. But this may take many years yet.

    Does anybody know a good link on “How to convince my manager to switch to agile”? Is there a solid analysis on profitability of agile compared to classical project-centric management?

  4. Former Member

    Great interview and could not agree more. I like the focus on business value with technology only being a means to an end.

    One thing I wonder about is whether agile with its bi-weekly releases is 100% suited for a normally business critical productive SAP system that is used across various business lines? What do you think?

    I still think Agile is valid for these type SAP projects, but I would bundle them with a structured release model and a quarterly or bi-monthly release calendar. That way you can work iteratively and agile in your pre-release phases, but at one point all code gets funneled into a common test environment for functional and regression testing. This helps ensure that parallel projects – whether agile or not – do not conflict with each other.

    What are your thoughts on that?


    PS Was great meeting you at TechEd … how is your new project coming along?

    1. Dagfinn Parnas
      Hi Swen,

      An important clarification is that Scrum says that in order for a user story to be completely done, it has to be potentially shippable code. In addition, each scrum product will typically define what their “definition of done” includes. It may include code quality mechanisms such as code review, user documentation, test documentation, ITIL changemanagement approvals etc.

      There is therefore no requirement that the user story is actually transported to production and relased to the user every sprint, and in real life very few scrum teams release every sprint. Though it is often a goal to significantly reduce the time to market from what we experience today in non-agile projects.

      The rationale behind being very strict on if a user story is completly done, is to reduce work in progress (ref. Lean) (lot of empirical evidence backing this up)

      Repetative Manual testing is very often early identified through the scrum process as the main barrier for increasing velocity (efficiency of the team). Therefore, most scrum teams quickly investigate automated test framework and use Test Driven Development (TDD). This mean that for each change in code thousands and thousands of automated tests (mainly unit) run automatically. Manual testing is performed, but then focusing on ad-hoc tests, not full regression tests.

      In order for SAP development to truely be agile, support for automated tests must be built into the platform. If the vendor also provides the customer with their own automated test, it can gain a huge competitive advantage. SAP will in the near futures see RFPs from potential customers that have adapted Agile methods asking what support SAP has.

      The relation between scrum projects and ITIL change process is also important. They are not in conflict at all, and scrum can help make visible impediments that can be improved through the ITIL continous improvement loop.

      PS Again thanks for the great discussions at TechEd. Project is going along nicely and I hope we can take the next step soon.

    2. Former Member

      Great, I was never sure about that point. But with your explanation our two models are in sync; thanks 🙂

      Only question mark that I see is behind automated regression testing. Having been a ww test manager myself during my IT career, I always said that nobody tests better than a curious human when he “explores” the sofware in order to find the corner case situations that may not be properly implemented. In opposite, automated regression test scripts tend to follow the beaten path and won’t randomly explore. … So at a minimum, you need a very good strategy around automated regression; I am just not sure how to build it?

      Any insight on that challenge?


      1. Dagfinn Parnas
        You are totally right.
        Nobody does better explorative testing than informed human testers, and agile mindset strongly encourages this.

        By automating the boring, repetative test, human testers have more time to do what they are best at.

        It is a common mistake in Scrum to not include any testers in the Scrum teams, but assume the developers can handle that part themselves. In general, developers do not initially have the testing skills required and by placing them in a team with testers they start to understand the trade better and the team can then take full responsibility of the user story; from start to protentially shipable code.

        Another too common organisation is to have a separate scrum test team that serves several scrum developer team. IMHO, this is not a good organisation as it pulverizes the total ownership of a scrum team has for a user story and introduces more work in progress (ie. waste).

        Test driven development is quite different from traditional automated regression test script. Basically, the developer is not allowed to write a method before he has written a unit test which covers it. Frameworks such as JUnit or AbapUnit are commonly used. 

        Once the code is commited (with a few hundred unit tests), a central build server usually kicks in and runs all the unit tests. If the build or some unit test fails, the developer who last committed is immidiately alerted and normally drops everything in order to fix it.

        For more info see

        Automated regression test for UI layer have also had a lot of progress lately.



Leave a Reply