Enterprise Geeks Podcast – Agile Development

Can Agile Development bring fun to the Enterprise?

Season 2 Episode 7
Join the guys in this monster of an episode on the great topic of Agile Development in the Enterprise. Thomas and Ed are joined by fellow SAP Mentor, Dagfinn Parnas to discuss their experiences on real world agile projects within the SAP world. Agile is a mindset and requires a cultural shift, so listen in as the gang gives some useful tips and pointers on implementing these methodologies within your own team.

If you have questions, suggestions, or topic ideas for future episodes, give us a shout here. Enjoy!

Running Time: 78 minutes

Talking Points

  • 00:17 – Random Chit Chat with Dagfinn Parnas
  • 06:15SAP TechEd 2009: Dagfinn Parnas – The “Company of the Future”
  • 08:00SAP TechEd 2009: Thomas Jung – Next Generation ABAP
  • 10:15 – Setting up the stage for Agile Development in the Enterprise
  • 12:35 – Agile mandate at SAP
  • 18:00Bacon doughnuts, bacon gum, and candied bacon…yum
  • 19:40Lean Manufacturing and Scrum Principles compared
  • 28:30 – What does Agile look like at your company?
  • 37:00 – Releasing to internal customers and the definition of “production ready” code
  • 43:53 – Why agile development creates hyper-productive teams
  • 47:27 – Why co-location is important when possible
  • 50:00 – Minimize needless meetings and increase transparency
  • 52:32 – Why most companies evolve into a waterfall process
  • 56:02 – Taking points from the Agile Manifesto
  • 59:25 – Is Agile in the Enterprise realistic or is a hybrid model the best way to start your cultural shift?
  • 62:23 – Why corporate champions are important, but the lack thereof is no excuse to not get started on your own
  • 67:00 – Coming back to the redefinition of roles in the project teams
  • 69:57 – What can SAP do to help their customers be agile?

15 responses to “Enterprise Geeks Podcast – Agile Development”

  1. Jon Reed says :

    Guys –

    excellent podcast. I got a clearer sense of the actual real-life agile experience from this podcast than I have in just about anything else.

    Maybe the only thing I didn’t like about the podcast was the several apologies for the podcast going long. If the conversation is quality, in my opinion, there is no such thing as too long – though at a certain point, releasing in two parts can make sense, though I don’t think you had quite reached that point. I may be in the minority but I like in-depth honest SAP related discussions and having produced longer and shorter podcasts I find my longer SAP podcasts almost always have more meat on the bone. Just give me a timestamp so I can find the part I want to listen or relisten to and I’m good to go.

    That’s not to say throw caution to the wind….

    Anyhow, onto the topic –

    Four big takeaways for me:

    1. Dagfinn getting across the power of the agile approach to unite a team in a more vivid and productive way. Ed you got this across also.

    2. Ed, your point on managing user expectations and not holding back on showing users unfinished functionality to keep the coding cycles faster – a major distinction between waterfall approach.

    3. Thomas getting his first-ever dedicated training on this topic inside SAP – shows the importance SAP is placing on this.

    4. Ed’s classic quote: “be agile within yourself.” An excellent eGhead motto, no?

    Personally I love hearing Dagfinn talk on this topic and would be neat to have him back to go through the steps in more details and/or talk about test-driven development. @tbroek also adds a lot to these topics.



  2. Matt Harding says :

    Great podcast guys with some great input from Dagfinn…

    Just wanted to add a little more to my input around Agile in the Enterprise and the use of Rational Unified Process as a viable option.

    Many medium to large organisations are exposed to consulting organisations which may offer less than ideal resources to deliver custom functionality. These consulting companies are not software companies, and depending on the skill level of your “experienced consultants fresh out of university”; you’re really dependent on them building the right thing.

    In a traditional world; as a governance architect, you review the design before they build the software which allows you to redesign the solution with minimal impact before it’s too late. It works, but is a poor approach to custom development where we expect requirements to change as the application takes shape.

    In an agile world where we take a Scrum approach, a governance architect is not exposed to the design sessions; and the trick for the consulting organisation is to work out how to deal with that as the first time they will possibly get to review the design is near final delivery of each iteration. That could be up to 4 weeks of work that is completely wrong and we don’t really want to refactor for the next iteration to get things right!

    What is the solution? Well involving the Governance Architect during the design sessions sounds like a great idea, but what Ed described in terms of ad-hoc meetings around a whiteboard doesn’t really allow their inclusion, and if you wait for this architect to free up, then you’ll probably add days to your sprint. Other ideas?

    The way it worked for me on a recent project was to use RUP which was very effective. In short, it is a risk based iterative approach which allows you to get the bulk of high level requirements set into iterations just like Scrum, but you produce requirements and design documents before delivering production code. This also allowed us to go with a fixed price but does require you to have a good relationship with the customer as requirements are not 100% locked down.

    On a different but important aspect: Something that is same same but different with Scrum and RUP is the focus on classifying requirements. With RUP, I’m very passionate about the ideas pushed there. Basically, high level requirements are categorised by:
    . Architectural Significance – How important is this requirement to the architecture?
    . Complexity – How hard is it to develop this?
    . Customer Priority – How important is this to the main stakeholders?
    . Stability – How stable is this requirement? Is it likely to change?

    If you rank your high level requirements like this, firstly you make sure that any Architectural Significant requirement that has a low stabilty – that you DO NOT PROCEED until you stabilise the requirement!!!! This can kill your project delivery date in any methodology. Next, build your first iteration to build your foundation (architectural significant requirements); plus for complex scenarios – prototype solutions so you have the answers when it comes time to develop the solution. Then of course, make sure you also deliver value to the customer regularly, or be ready to explain what you are doing and why it is important.

    Anyway, if you have a customer, or you are an enterprise that supports Scrum…Awesome (I heard of a medium company in Queensland that has support from Scrum from CEO downwards and the buzz there is meant to be awesome).

    If not, maybe you can get away with a RUP approach which with a bit of selling is pretty easy to sell and can work in larger consulting organisations.

    BTW – Thomas led a great session on Agile at Inside Track last week; and it was good to see there are a few companies looking at how to do this properly. Unfortunately I diid’t get anytime to record a mini-podcast but there was definitely lots of eGhead swag going around! Hoping next year Ed makes it down-under!

    On a slightly different topic; I’d be interested if anyone else has been looking at the business process modelling (as apposed to business process management) space which is all the rage at the moment. It seems that Agile methodologies and BPM efforts are not really aligned in terms of methodologies today.

    Anyway, verging on a rant there but hope that explains my case for RUP a little more if you cannot get Scrum.


  3. Leonardo De Araujo says :

    Hi Guys,
    Great Podcast.
    Let me add to what Matt just said.
    I work on consulting and I go to customers to implement SAP and its customizations. I agree there is a lot of mediocre people in this business but I need to make a distinction:
    SAP implementations often mean 40-100 (average) different developments. These could be simple enhancements to complex dialogue transactions.
    ASAP methodology (if implemented correctly, and I agree we could go months discussing this) means a good “blueprint” at the end of Blueprint phase. That means that we should be able to tell what needs to be done, in detail then. That is very important for budgeting. Even if you say that is often is not the case, that is case often the work is not done properly then.
    Let me focus on what is my point. I love change and look forward to seeing a way to have agile in SAP projects. The problem I see are 2 fold:
    1 – The agile methodology seems a better fit for continuous improvement, production support and software development, but not as much for a tight budget, high risk VERY STRUCTURED projects like a typical SAP implementation. Not saying it won’t fly, but surely a very difficult sell. Much easier to say you asked for this report, I estimated 20 total days of work and that is it, the rest is my responsibility to deliver. I never had a problem doing so. Agile is named that way to allow development to be agile and respond faster to changes in the business. That is typically not required in a SAP implementation where we take a snapshot of a point in time and implement it based on the design. After go live, I see a HUGE potential for AGILE, during the initial implementation, I have difficulties.
    2 – The types of changes we need to implement in SAP for customers are minor. SAP offers 95% of what the customers want. What is left is peanuts. (we could discuss hours here, but very large developments like new modules etc are rather exception). So often what we deal with are reports, forms and enhancements on SAP transactions. All these being deliverable of less than a couple of weeks. The Agile cycle would be longer than that anyway. (point taken that if you build a solution that would take months, better would be to have successive partial releases like agile proposes)

    Guys, please don’t crucify me here. If you see me as a negative of resistant to accept change, well, maybe I got my message wrong. My point is, I am a SAP consulting company. I manage developments in SAP implementation projects. HELP ME see a manageable way to implement Agile in projects. I am currently not seeing it.



  4. Ed Herrmann says :

    The first thing that everyone ponders, is how to apply these principles to their own experiences. Listening to the podcast, you can see that being the vendor like SAP, an SAP partner, a consulting company, a customer doing implementations, or a mature customer doing larger custom projects all are different environments where there is no one-size-fits-all solution. As Matt mentions in an above comment, he has found out that RUP works best for his situation. This is why I always stress that the attitude and concepts of being agile are more important than being “rigid with your agility”, especially in an Enterprise context.

    So for you Leo, I would say that it’s up to you to explore the best ways to be agile in your own experiences. The most important things are to foster and promote open and constant communication (scrum), including the right people (stakeholders), quick turnaround (iterations), real work as a measure of progress (working code vs needless documentation and analysis paralysis), and perhaps most importantly, the ability to embrace change (continuous feedback and backlog prioritization based on current needs vs. a ton of signed off specifications for pointing finger pointing later on).

    The more you apply these principles, the more you will find yourself and team will gain motivation and momentum throughout the project. In other words, to repeat my podcast quote that Jon loves so much: “Be Agile within Yourself”.


  5. Dagfinn Parnas says :

    Great input from the above comments, I’ll try my best to give some feedback based on my experiences.

    First both Matt and Leo bring up the topic of consulting companies and their responsibility within a project. In such scenarios there is an added complexity of introducing Agile methodologies such as Scrum, in that they are supposed to deliver a solution based on a set of requirements. Therefore, a contract is signed specifying what to be delivered and who has what responsibility. This cause a lot of overhead and pre-mature focus on defining a complete set of requirements for the solution. Significant change will happen to any IT project and this will cause much fricition when the contract contains the economic terms. Two of the Agile manifesto principles are relevant “Customer collaboration over contract negotiation” and “Responding to change over following a plan”. There are specialized contracts for agile projects (PS2000 in Norway), but they are no silver bullet. From my experiences the best results come when the customer takes control of the project and if needed hires the right consultants on an hourly basis to be part of the scrum team.

    With regards to Rational Unified Process brought up by Matt, I believe many will meet agile within such a framework. My major problem with RUP is that it is originally designed for very structured and mostly waterfall-based projects, and then monkey-patched to support an agile mindset. My view is that it is best to use Scrum as a basis framework for being agile, and then bring in elements from RUP, XP and other frameworks when needed. Scrum doesn’t try to cover all the aspects of RUP or XP. It is designed to get a self-organizing team productive and take ownership, focus on business needs and make waste/dysfunctionality in the organisation visible. A common pitfall in Scrum is that you have an analyse requirements sprint, a build sprint and a test sprint. For a user story representing real business value, you should be able to cover all those in a single sprint (if not, you need to identify why you are unable to do it, and see what you can do to remove that obstacle). Often it is the business which is not clear enough on what they want to achieve; it is therefore important to make sure all user stories have reached a certain maturity from the business before the scrum teams picks them up.

    Matt mentions the story about a governance architect, which I think many can relate to. My view is that we have way too many powerpoint architects which function more as police than as mentors for projects. They need to get more involved in spreading the message of good architecture and the guidelines the company works by. If architectual decisions are to be made which the scrum team cannot make themselves, it is an impediment that must be handled. Only when such impediments are made visible, will the organisation change for the better.

    It is also common to early focus on user stories which are cross-cutting through most of the layers of the solution and therefore require significant work architecturally. If bringing in elements from RUP to aid in architecture development helps you, then by all means proceed as long as you take account the agile principles and make sure you are able to communicate with the customer why this is important and how it delivers value to him/her.

    Leo says: “not as much for a tight budget, high risk VERY STRUCTURED projects like a typical SAP implementation”. If your project is highly structured with little or no changes, by all means use the waterfall approach in the same way as the construction business. Agile provides added value because it allows us to handle the changes that empirically occurs in almost all IT projects, but if these changes will not happen then you might as well stick to the waterfall approach. However, you should question if there is no changing requirements or if it only looks like this because it is too expensive to change anything after the requirements have been set (and that the customer would be better of with changes late in the progress as he/she learns more).

    Cheers Dagifnn

  6. Matt Harding says :

    Hi All,

    I tend to agree with Dagfinn that doing Scrum and introducing RUP components could be an excellent approach to “be agile within yourself” like Ed’s catch phrase. I also think that provided you can quote to high level requirements, then it should be possible to minimise the waterfall limitations that larger consulting companies need to do and have proven this on prior engagements (not quite an SAP implementation, but something of reasonable effort/size).
    I had a discussion with @alisdair73 today about this topic (he’s a big Scrum supporter but exposed to the issues such as what I explained above) and we believe the only way to get past this is to get individuals you trust within the consultant company to act as decision makers (with approved authority). The catch22 is that how you get this trust probably requires a traditional waterfall style of project to begin with!
    BTW – Both him and I are extremely hands-on in terms of mentoring with Al being one of the most proficient developers I know in terms of expertise hence not even coming close to even looking like a PowerPoint Architect – I believe they are Enterprise Architects ;-), but in companies where we’ve worked, you are one technical architect accountable for multiple concurrent projects, with at least a couple being in the vicinity of $1 million plus style projects. You can mentor key projects well (especially if they have real expertise in their teams); but beyond that; you need process to catch the poor design decisions that some (less than mature) project teams make. You could obviously hire more of us to put on projects but most companies prefer to avoid too much internal headcount and don’t realise the value of this. The usual expectation is that contracts should be met by the consulting companies and just pass internal controls.
    Anyway, as John Mayer says “One day our generation is gonna rule the population” and then we’ll demand this going forward.

    Good discussion,

  7. Ed Herrmann says :

    @Vijay, as promised on my reply to your post, I will try to give a more in depth response during an upcoming episode. I think it’s important to clear up a lot of the misconceptions and to discuss what an agile attitude can do for a project.


  8. Ed Herrmann says :

    For anyone following the Agile v Waterfall conversations between Vijay, myself, and others, we have decided to have a roundtable discussion at SAPPHIRE Orlando. If you will be there, please join us.


  9. Vijay says :

    Looking forward to it. Too bad we won’t have Dagfinn there in Orlando

  10. Graham Robinson says :

    For those of you interested in Agile topics you might find this article by @mkrigsman – and especially the presentation by Mitch Lacey – contains some useful information.


    Graham Robbo

  11. Dagfinn Parnas says :

    Watching the video of Mitch now, very good.

    So far I must say I agree with @mkrigsman ‘s conclusion:
    “This failure has nothing to do with Agile, waterfall, or any other methodology. The real culprit was hidden agendas, politics, inexperience, and greed.”

    @analytical_mind has a four-part article series on “What consultants don’t tell you before you begin an agile transition” which I found very interesting. It is available at http://analytical-mind.com/2010/03/01/what-consultants-don%E2%80%99t-tell-you-before-you-begin-an-agile-transition-part-1-impact-on-the-organization/ (view related post for part 2-4).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: