Agile and ERP: Part II - The Good News
Agile and ERP: Part II - The Good News
This article is the second installment of the investigation into using Agile in ERP environments. It shows which practices will actually work.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
First the good news: there are 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 the 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 have no evidence that it is accurate in this environment but it might be effective at persuading people that 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 environment, 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, and 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 it's 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 expect 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 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 team's 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 unraveling cause and effect is hard.)
And that's the good news, the next post will discuss culture before I turn to the bad news.
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.