The Good News - Agile & ERP, part 2

First the good news: there is a lot of Agile practices which work just fine in an ERP environment. These are mostly the process practices and some from the demand side (i.e. requirements, “what are we going to build”).

All of the following work just fine and will improve work of teams in ERP:

• Stand-up meetings work just fine, but stand-up meetings alone do not make a team Agile.
• Iterations (Sprints) work just fine; and that includes starting them with a planning meeting and ending them with a retrospective. (You can do estimation with planning poker if you like, I’ve no evidence that it is accurate in this environment but it might be effective at persuading people you are taking estimates seriously.)
• Visual boards work just fine and will improve work.
• User Stories, i.e. small pieces of business valuable work, are fine; you can also use Epics and Tasks too, and you can do Xanpan style urgent-but-unplanned work too.
• Defining acceptance criteria (conditions of satisfaction) works too.
• Pushing authority down, encouraging teams to take on more responsibility is all good too. But note: ERP and big company culture make this a challenge
• Agile Coaching works just fine too.
• Product Owners work; and as usual in a corporate you will probably find a Business Analyst filling the role day to day. However, ERP culture is document centric and added together with authority problems means POs might not have, or at least feel they do not have, the authority to make decisions.
• As always co-located teams work best, pair programming and mob programming work fine too.

Some practices are always more difficult, perhaps in ERP they are more difficult.

Identifying and delivering small, thin, slices of business functionality works, almost. Two problems appear. First because the nature of ERP systems is all encompassing business representatives are even more resistant than usual to accepting anything less than everything. Second, architecturally ERP systems do not lend themselves to working on things piecemeal. You can do some of this but its even more difficult than usual.

Emergent design is hard, largely because refactoring is still a new idea, the tools, techniques and most importantly mindset and understanding for incremental, evolutionary, organic style growth are not there. Therefore all the old arguments about “we must design the big picture” are very much in play.

Multi-skilled individuals and cross-functional teams: as with “normal” software development getting people to work outside their core skill-set helps smooth the flow of work; and as with normal software development there are limits to this both because of the learning curves involved and because of individual preferences and identity questions.

With ERP systems these issues seem to be more difficult partly because the skills involved in ERP work are even more different and - to preview something I will say later - there are greater cultural issues. Many ERP developers come from domains other that software engineering and therefore lack some of the basic understanding that one might expected of them.

Secondly, because ERP is normally done inside a corporate environment people are more conscious of their defined roles. In typical software companies individuals are more prepared to try doing something different because the aim is to ship a something. In all corporate environments people are more prone to limit themselves to their defined job roles and titles.

Corporate environments typically bring another problem too. Not in every case, but in the majority of cases, the quality (depth of skills, ability to learn fast, and such) of people inside corporate IT tends to be lower than that in specialist software development organizations. I tend to believe this is more a function of the organization than the individuals and it is not true in every case but it certainly seems that good technologists tend to gravitate towards specialist organizations.

This might be a function of recruitment practices, it might be a function of expenditure on training and skills, it might be a function of corporate mission, it may well be a function of the corporate environment or the specialist development environment, or something else altogether.

And because the corporate environment limits the teams ability to resolve impediments. Implementing a commitment model is extraordinarily difficult. This doesn’t worry me much because I’m not a keen fan of the commitment model anyway - see my Commitment Considered Harmful post.

The net result is: ERP teams don’t have as many high performing environment or individuals and teams as a specialist IT shop. (Obviously those two things go hand in hand but unravelling cause and effect is hard.)

And thats the good news, the next post will discuss culture before I turn to the bad news.