Other things about SAP (which might block Agile)

To finish off my BPM/BPE/SAP mini-series here are some other things I learned about SAP and BPM. These might be specific to the team I encountered or they might be generic. I think all of them present obstacles to doing SAP implementation Agile. Not impossible, just difficult.

Please, if I have any of this wrong correct me. I’d love to be wrong on most of these things. I’m also acknowledge my dataset is small so anything you can add to these notes would be great.

First a word on TLAs, it gets confusing:

• BPR - Business Process Re-Engineering; where it all began (sort of), comes from a book by Hammer and Champy and was very popular in the 1990’s. Largely discredited now, a blunt instrument used by many consultants which caused a lot of damage
• BPM - Business Process Management; and
• BPE - Business Process Engineering; I don’t know the difference between these two terms, they seem to be the same thing. They describe the thing that rose from the ashes of BPR. Still focused on business processes but removing some the neutron bomb like aspects
• BPM (again) - Business Process Modeling; the activity of examining your business processes, a step in applying BPM (Business Process Management), something you can buy tools for
• CRM - Customer relationship management; and
• ERP - Enterprise resource planning; two of the most common applications for which BPM, and SAP in particular, are used.

As you can see, it get confusing.

OK, things I learned about SAP:

• Actually understanding what SAP does, and does not do, is very difficult. Despite masses of literature very little of it contains hard data. Most of it is hand-waving generalist, marking speak or so focused on outcome that it is impossible to tell which bit SAP did all by itself, and which bit was a custom bit bolted on the side.
• Nobody is a developer, there are lots of designers, even the people who you might think did configuration and table updates are designers. They all expect to have someone below them to actually get their hands dirty.

• SAP culture seems decided un-Agile. There is an expectation that business processes are be defined up front, software design up front, etc. etc.
• At the end of the development everything is rolled out, i.e. change is imposed on others.

• SAP people are plug compatible, well so I was told. Apparently you can give the SAP HR person a week off, call up the consultancy they work for and have another SAP HR consultant for that week.
• SAP consultants have a lot of frequent flyer miles. Don’t expect them to attend a 9am Monday stand-up meting or hang around on Friday afternoons.
• SAP consultants tend to work for big name consultancies. These consultancies seem to have an attachment to waterfall development. Perhaps because it gives them some nice sign-off (i.e. billing) points. Strategy, requirements, design, implementation, testing, change management, ....
• SAP is all encompassing. It is a development environment, a programming system/langauage, a run time environment, a source code control system and many other things too.
• SAP “configrability” seems to be at a GUI level, cannot textualise the configuations. Thus very hard to automate tests, compare differences and version control.
• Similarly code reviews are difficult but pair-programming should work. But given the prices consultancies charge for their consultants I don’t see many takers.
• SAP source code control does not provide for branching or merging - and probably not importing or exporting.
• Some SAP configuration can only be done by hand. So no automated builds or unit tests. (SAP doesn’t even try to support them.).
• SAP has a programming language, ABAP. Its supposed to be a little like Cobol. There is an ABAP Unit test framework. It won’t do you much good because most SAP “programming” is done through configuration and there is no way to do unit testing on that configuration.
• (These and other aspects of the SAP tool set very old. This will make life difficult to Agile teams who may need to create new technology to address these issues.)
• Once you have finished your SAP application you pay SAP to “maintain” it. Or rather, pay them not to break it with a future SAP release.
• Nothing from SAP works out of the box. One of the first things you do in an SAP project is switch on the bits you want and switch off the bits you don’t. Some of these appear to be one time only decisions, you don’t get to change your mind.

Overall I got the impression that when you buy SAP you buy a legacy system. You start from nothing and you move immediately to legacy maintenance. That should be ideal but in buying SAP you buy lots and lots of functionality you don’t need and that imposes an horrendous maintenance burden.

I hope that doesn’t come across as SAP bashing. I’ve spoken to some people this year about other ERP and CRM type systems and it appears they are all largely the same. For example: there is no way to do unit testing in Microsoft Dynamics.

SAP present their product as a suit of unified tools. This seems to be pure marketing. It seems that the system has been developed by so many different companies, teams and at different times its a miracle that any of it works together. The Microsoft and Oracle equivalents seem to be in even more divergent as these have been assembled by buying the components in.

I also learned recently that a lot of these fancy “business process” applications are actually just a series of forms on screen. People fill in forms on the screen and it gets stored in a database. Or it triggers a dispatch. Or some such. Business Process Management is often just forms and workflow. Nowhere near as exciting at as “re-engineering” or the other fancy terms that get used in this space.

For the moment I think “Business Processes” is a very a grand title for what is basically: flow charts.

Whether it is exclusive locking on a source code control systems or flow charts, I kept feeling like I was back in the 1970’s, or maybe the 1980’s. Of course, I’m too young to remember those times in IT so I may be wrong. But this is a very different world from the internet world I’m use to.

In my research, I also learned that SAP have tried Agile, specifically Scrum, internally. However corporate anti-bodies killed most of the attempts. Some infection might remain. Having seen what I saw this year I think SAP corporate culture probably can’t stand the idea of Agile in reality.

Still, my experience of using Agile on SAP projects is limited. As you can see from the list above I think there are many obstacles. I think it can be done but I think you need to go back to basics, values and principles.

Agile approach to BPM / BPE / BPR

Continuing on the Business Process theme I want to think about what an Agile approach to BPM/BPR would be.

For me there are two scenarios: Business Process Management for new processes and the “re-engineering” version which looks improve existing processes.

In the first case the answer is: start small.
Don’t just look to develop a small piece of software;; look at the business you want to enter, look at the product or service you plan to offer. Find small pieces which can exist in their own right. Maybe you can start by offering it in a small geographic area. Maybe you can limit your offering to start off. Maybe you can shave off some of the frills to the offering.

Find the smallest possible product or service that you could enter the smallest possible market with. Build just enough (if any) technology to support that and enter the market. Then set about expanding your offering and you sales. As you do add the bare minimum of technology to do it.

Yes, its incremental growth. Yes, it is bootstrapping yourself to organic growth. That doesn’t look good on a business plan, doesn’t look good when you are GE and you need big new markets and big new products to make any difference to your balance sheet. Sorry about that.

It does mean the risk is less. It does mean you could fund a start-up to do it. It does mean you could make a lot of experiments to see which markets are attractive.

So it does mean you need to change the way you enter new businesses.

Second case: you have some existing processes at the moment.

Here you want to set in place a process of improvement. Not a big bank, sweep everything away but a million small changes that build to big change. Involve the people who are doing the work. Find out what they think would improve matters.

Perhaps you want to leave the IT to one side entirely to get get started with. See what changes and improvements you can make without any IT change. When you’ve made them use IT to cement the changes.

Again it doesn’t have the big bang mega-bucks appeal of the big project but its far more likely to lead to long term success. This is how you create and sustain a continuous improvement culture and a learning organization.

The traditional “Business process” mindset seems to view the business as a gaint state machine. It is the SAP teams job to help the people in that organization move through the states and transitions of that machine. This approach assumes “the big brains know best.” Which is exactly what has been discredited in the software development world but there is still an illusion that this can happen on the business side. Thats why we need an Agile approach to business processes even more than we need it in software development.

I keep thinking of Naked Objects. It seems to the Naked Objects approach could be a great approach to bootstrap a an Agile BPM programme.

Agile and Business Processes

I want to stay with the theme of Business Processes and Agile software development for a couple of entries. I’ll break it up into bite-sized chunks rather than one rambling entry. And they may come in quick succession.

Quite a lot has come out of my last entry (BPM - is it just programming the corporation? (And the SAP Irony)), comments on the entry and conversations I’ve had recently. I’m grateful to Hans for adding some more comments to the entry which I found very interesting.

Hans suggested that the way the term “agile” is used is different between the BPM/SAP type of people and the software development community. He suggests - if I understand him right - that Agile software people value the ability to change so “agile” means “can change (software) to respond to situations”; while BPM/SAP folk consider “agile” to mean “the technology works - and we can do stuff with it quickly - which free us up to think about other (more important) things.”

There is a subtle distinction here, I wouldn’t say it is two meanings of the word, I’d say it is two ways of looking at the problem. Two different aspects view, or opportunities to exploit.

The Agile software folk say: “look how quickly we can change this software, look how quickly you can get results, now think of the business opportunities that opens up.” In other words: being Agile in your software technology opens business opportunities itself.

To the BPM/SAP folk “agile software development” means: better.
So: software will be delivered sooner, with the features we actually asked for, within the budget we first thought of an maybe with less bugs. “With the hassle of software development out of the way we can use all the free time to think about other business opportunities.”

To me this is the difference in:

• Agile software development as a better way of developing software

and

• Agile software development as a way of creating new business opportunities

Ultimately its a question of perspective and what you want.

For me the first sees IT, and development in particular, as a cost and neglects the benefits. For some business that will be true. The ones that interest me are the ones that use technology to change the way they do business and gain advantage.

BPM - is it just programming the corporation? (And the SAP Irony)

On and off I’ve run across Business Process Management - the descendent of Business Process Re-Engineering. Earlier this year I did a little work with a SAP team who wanted to be Agile, and a few weeks I was at the BPM conference in London.

What was noticeable at the BPM conference was both how dependent on IT it is, and how many of the techniques used by BPM practitioners look like IT techniques, specifically, the practices in software development.

Whenever I encounter BPM - or when I looked at BPR years ago - I get this feeling that it is an attempt to apply software development methodologies to the corporation. The BPM folks seem to regard the corporation as a machine to be programmed.

Processes are the sub-routines. These are programmed and linked together. Processes are re-usable - at least in theory. Under taking BPM seems to involve analysis, design and implementation (but no testing, strangely.) It sounds like Waterfall software development.

BPM folks want to create “the agile business.” They are talking the language of Agile and borrowing a few techniques. I even met a company at the BPM conference who have their own proprietary BPM process which looks, sounds and smells like Scrum.

Which leads me to ask: Is BPM just programming at the corporate level?

I think BPM folk would reject this suggestion simply because they view “programming” as dirty, cheap, low-end work for unwashed young people. What they do is expensive, strategic and practiced by ex-programmers (who would prefer not to talk about the past).

The other reason I think BPM people would rush to reject the idea of programming is because - as they are always keen to tell you - the software systems they use are not programmed. They may be configured or they may be customized. In the extreme you might write a customer module (or rather pay someone else to).

But, as all programmers know: programming is not just about code and its not just procedural. The configuration and customization are a form of programming. Some of the configuration tables in SAP look like table driven programming to me - not unlike a Turning machine, actually.

Now the BIG irony....

BPM folk are keen to talk about end-to-end activities and processes. Yet getting BPM tools - I’m thinking of SAP specifically - to do something means working with functional specialists who know their module and little else. An SAP Finance person would never think of working on SAP HR, an SAP HR person would never work on SAP Logistics.

A standard techniques in Agile teams is to have people work on difference parts of the system to do end-to-end. But this seems to be one thing SAP people can’t do. Ironic isn’t it, the people who advocate end-to-end processes can’t do it themselves.

Is Kanban complicated? Is Kanban Agile?

An interesting comment from Rob Bowley to my “Hardest part of Agile” blog entry. Rob asked “A lot of this discussion around Lean and Kanban Software Development seems complicated and is getting quite scientific. Does that mean it's probably not agile?”

Lets try and answer that.

When I have introduced Kanban to teams I’ve actually found it easier to get the team started on Kanban than other Agile approaches. I definately think it is easier to get started with Kanban than say Scrum.

I say this because Scrum asks you adopt Scrum perfectly before you change it. Even if you don’t adopt Scrum perfectly you need to make a lot of changes to get close to Scrum. Many teams which claim to be doing Scrum would not pass the Nokia test or any checklist of Scrum practices.

Kanban on the other hand isn’t so much a software development method but a method for process improvement. When I introduce Kanban I start by mapping out the teams process and using that to create a Kanban board. The Kanban board shows were the issues are and we work to improve them.

Why Kanban sounds so difficult is because is because people are still working out why it works, what works best and how to implement it. You need this kind of understanding to validate the approach and to apply it widely. But most people don’t. They can delve into the Kanban toolbox as and when they need to.

For example: visualizing the process on the board will help you improve flow. You don’t need to know the word flow or what’s behind it.

But, and this is the big But with Kanban, and its my big fear with it....

Kanban can be badly or poorly applied even more easily than Scrum. You do need someone on the team, or available to the team, to get the process improvement process going. It is easy to map out the board and leave it at that. Getting the process improvement bit going is the difficult bit. Whether you are doing Scrum, Kanban or anything else creating a culture of improvement is hard.

And a Kanban board shows up your problems more quickly than anything else. Which means things might look like trouble very quickly. If you don’t have someone who knows what the board is telling you, and someone who can help the team address the core problems then it can look scary.

So even more than Scrum I advise Kanban teams to have a coach. Someone who’s been there before and someone who can drive team based improvement.

Back Rob’s question. “Is Kanban Agile?”. Well hopefully I’ve explained why it is simple enough to be considered Agile so on that basis I think it is. Whether the Kanban folk want it to be considered Agile is another question. I think many of them would prefer it was considered Lean not Agile.

As I’ve said before, I consider Agile to be a form of Lean or even exactly the same (see Agile and Lean - the same but different). Kanban’s roots are more clearly in Lean than other Agile methods. I also wonder if we would have had Kanban without 10 years of learning from XP, Scrum, etc. So Kanban might be the first “post Agile” method, thats why I put it on the side of my triangle:



See Agile and Lean - the same but different for an explanation of the triangle.

More Business Strategy patterns for software companies

As you might guess, I’m lightly loaded this week so I’m catching up with a number of writing projects.

The latest set of patterns in my Business Strategy Patterns for Software Companies series are now online.

This set were reviewed at EuroPLoP 2009 and describe a Pattern Language for Product Distribution. The patterns are:

• Branded Shops
• Named Sales People
• Internet Store
• Independent Retail
• Local Guide
• White Label
• Wholesaler

And while we are talking about patterns, did you know: there is a Google Pattern Search engine? Thanks Gregor.

FAQ: What is the hardest part getting Agile?

I made a passing comment in the last blog entry to “the hardest bit” of Agile. I keep feeling I should elaborate rather than leaving the comment hanging.

A couple of weeks ago I was teaching an Agile class for DevelopMentor in London and someone asked “What is the hardest part of learning Agile?” It was a natural question and one I realised I‘d heard several times before in different forms.

So it is a frequently asked question. And the answer is...

Its not so much what you have to learn to do Agile its what you have to unlearn.

Most Agile methods are fairly easy to learn, remember they were originally termed “lightweight” and emphasis simplicity. Any method that gets overly complicated and difficult to learn probably isn’t Agile.

(One of the reasons I don’t consider RUP to be an Agile method is the complexity and size. Although you can make RUP work Agile that doesn’t make it an Agile method, but we digress...)

Generally I deliver an Agile training class in two days. We cover a lot of ground but we can’t cover all the corner cases, rough edges and unexpected situations you come across. When I work embedded in a team, as an Agile Coach, I brief the team as we go along. I might start with a couple of hours teaching to lay out some basics but thats about it. Since I’m there for longer I can teach team what they need to know when they need to know it. Or better still, I can help them find their own solutions.

(In both cases I like to use plenty of exercises. Its one thing to talk about something, its another to experience it. But we digress again...)

But what is more difficult is not what you need to learn, but what you need to unlearn. People need to unlearn previous beliefs and the behaviors that are rooted in those beliefs. For example:

• Unlearn the belief that work can be specified up front. Instead learn that needs emerge, evolve and change.
• Unlearn the idea that work can be planned in advance, specifically unlearn the idea that Gantt, Pert or CPA charts hold the solution. Learn that work is planned reviewed and replanned with blinkers on so we only look at the near future.
• Unlearn that estimates should be padded and schedules include slack time to buffer. Learn that estimates are just estimated, not commitments, and schedule slack hides problems.
• Unlearn that bugs are inevitable and we needs lots and lots of testing to find them and remove them. Learn that quality is free and we can eliminate most rework by prevention.
• Unlearn a faith in tools to solve our problems. Learn that problems are solved by people and our own initiative.
• Unlearn that “thats the way we do it around here, you can’t change the system”. Learn that if things are going to get better thing have to change around here.

I could go on but it would be a very long list. Maybe you’d like to add some of your own.

(I wrote about unlearning in a guest editorial for ACCU Overload a few years back, The Need to Unlearn.)

Unlearning means we stop doing things. We take things away from the way we work today. In the short run we might make some compromises and add Agile practices before we remove current ones, but that can only be a short lived situation otherwise we drown in contradictory practices and excessive work.

The implications are quite scary for some people. For example:

• Adopting Agile project management means you need to change the way you plan at the moment. Continuing your PRINCE2 based project management while running an Agile project management process in tandem is self defeating. Yes you can use the two together but you need to change your current practices not just add more.
• Agile development work can, and should, start before requirements are fully defined. Work is goal and value driven rather than document and feature driven. Again, you can start your transition to Agile with a big requirements document in place but if you maintain strong resistance to change you will not see the benefits of Agile working and you will not really be Agile.
• You need to trust your staff, your developers, testers, business analysts and everyone else to do the right thing. If you can’t trust them why do you employ them?

Again I could go on.

A few months ago I took a stab at guess-stimating how many people are “doing Agile” (How many people are doing Agile?). Since then I’ve come to the conclusion that a far higher number of organizations and teams claim to be Agile - after all who wouldn’t? Agile is good for you, like Apple-pie. But I think most of these places are taking the additive approach. They are applying some elements of Agile to what they have already. They are not unlearning and they are therefore not seeing the improvements they hoped for.

Magic Agile Fairy Dust and the hardest bit of Agile

There is no such thing as Magic Agile Fairy Dust. Neither me or anyone else can come to your company and sprinkle my magic dust and fix all your problems. There, I said it.

Its more complicated than that, there is no out-of-the-box solution. I can help you, you can use some tools, some methods but it involves change.

That change involves not doing some things. Changing to Agile involves subtraction as well as addition. It is not enough to just add Sprints, stand-up meetings and what not, you have to stop doing some things.

And thats the hard bit. I can teach you the basics of “Agile” in a few hours if I need to. But it takes a lot longer to help you unlearn what you did before. Unlearn behaviors, assumptions, ideas and ways of working. You can’t do that in a few hours in a classroom, it has to be done in the workplace and over time. Thats what Agile Coaching is for.

The only thing that comes close to Agile Fairy Dust is Test Driven Development (automated) and Automated Acceptance Testing. You can add those things and start to see a difference. Not immediately but in less time than you think.

Memo to self: things I learned at the UK Lean Conference

A few of points I picked up at the UK Lean Conference the other week I made a note of and think are worth recording.

Point 1: There are two kinds of Kanban limits, i.e. or work in progress limits.

The first is what we usually think of when we talk about work limits: how many tasks are we working on at any one time. This might be an limitation of the machinery and process we are using or it might be a limit we impose to manage the work.

The second type of limit is a limit on events. For example, you may decide the supply truck is only going to visit the factory once a day.

Or, to put it another way: decide what you are optimising. What is it you see to minimise? Maximise? or optimise some other way?

Point 2: Sometimes, flow trumps waste, and sometimes, value trumps flow. Or, to put it another way: Value > Flow > Waste

This was mentioned several times, and someone gave the original reference but it was too quick and I didn’t note it down. If anyone has it please let me know, I’d like to read it. Until then, here is my understanding.

When people learn about Lean there is a lot of focus on Waste. The Waste idea is easy to get and clearly makes sense. Then there are seven wastes to think about reducing - or eight if you read Liker in “The Toyota Way” and some talk about a ninth waste and I’ve even heard talk of ten. Anyway, 7, 8, 9 or 10 wastes, its something to get your teeth into and start doing.

But a more important concept in lean is flow. The idea that the path work takes through a system needs to be uninterrupted, smooth, and we should work to reduce the time it takes for work to move from one end of the system to the other.

So, sometimes, waste is acceptable if having waste improves flow through a system.

Then there is value. The idea that all work should deliver value to customers. And sometimes, we can deliver more value if we break flow.

For example: There was once a software development team who would throw away all their most recent work if the company made a new sale. The team worked in short iterations so they were never throwing away more than a couple of weeks work but, if they could make a sale by promising a quick delivery then the team reasoned they would add more value by just aborting the current iteration and starting over on the customers work.

Point 3: Waste breaks down in knowledge work
There seemed to be an emerging consensus that while the waste idea made a lot of sense that it could be carried too far; and in software work, and perhaps knowledge work in general, it lead us down some dead-ends and got in the way sometimes.

Because: knowledge work requires some experimentation and exploration, from a production point of view this could be seen as waste. However in this context it is knowledge creation.

I’m sure I learned other things at the conference but right now these are the things that stick in my mind.

As usual at conferences these points were made and learned more between sessions than in sessions. That said you need the sessions not only to give the conference form but to attract the kind of people with whom you will have these conversations. The sessions and speakers act as a kind of filter (Point 4).

A tale of two conferences (Lean & BA)

I spent the first part of the week attending the UK Lean conference swiftly followed by the IRM BA conference. Heres a rough cut at some thoughts from the two conferences.

The first day of the Lean conference was my favorite - and not just because I was speaking. It was “practitioners day” which means it was light on big names. The second day was packed full of big name speakers and oddly that was a downside. While the first day was a two way conversation the second day felt more corporate.

I didn’t make it to the third day of the Lean conference because I was at the BA conference. Now this was a corporate conference. Yet the speaker line up was not so strong. OK, thats unfair, most of those at the Lean conference were already pretty advanced at practicing some form of Lean or Agile and the conference was about improving these activities. The BA conference seemed to contain more introductory material. So perhaps I’m not the right person to comment.

Actually, although I was officially attending, and speaking at, the BA conference I actually attended several sessions at the Business Process Management (BPM) conference. The two conference were running in parallel at the same location and on the same schedule.

Although I was a little unsure how I would be received by the Business Analysis community I need to report the reception was very positive. I was talking about Agile and I found that most Business Analysts were both interested in Agile and welcoming Agile way of working.

I’m happy to report that on Twit on Twitter declared I was the highlight of the conference!

As I said in my last blog entry, the presentation is now online - More important than ever, the role of the Business Analyst in Agile transition.

So what did I learn? What were my highlights?

John Seddon at the Lean conference. He took a few pot shots at Lean and raised some valid concerns. His alternative is systems thinking. Personally I think the two approaches are complementary. I am always keen to relate Agile and Lean back or organizational learning, and I believe that system thinking is an essential element of such learning.

John introduced me to a new term: “Failure demand” - that is the demand created on a organization or system because of earlier failure. He sited examples of companies and organization where the apparent demand was 60, 70 or even 80% related to earlier failures.

One common theme that seemed to span both conferences was the dangers of using inappropriate tools. Whether it was Lean in service organizations (from John) or using Six Sigma black-belt tools when simply asking users what the problem was everyone seemed to warn against excessive reliance on a tools.

One insight that will stick with me came from Jeff Patton (at the Lean conference) who pointed out that a Minimally Marketable Feature (MMF) is not the same as a marketable product. He introduced the expression “Minimally Viable Product” (MVP), an MVP is a collection of MMFs.

Over at the BA/BPM conference I was exposed to the Business Process Management world - speakers, exhibitors, attendees. It seemed to me that BPM far more intwined IT and technology than I ever imagined.

Mary Poppendieck (at Lean) was, as ever, a very entertaining speak. She introduced a new case study: the Empire State building. Built between 1929 and 1931 the main building was completed in 8 months, end to end it was a little over 18 months.

My notebook is crowded with ideas and comments but I don’t have time to document them all here. I am sure the ideas will find there way here eventually.