Article- The Scrum Idea - JDEtips-Jan2015

128
The JDE Scrum IdeaKnowledgeExpre ss
Copyright © 2015 by JDEtips, Inc. www.JDEtips.com
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
The JDE Scrum Idea
Transforming Away From Waterfall and Embracing Agile Scrum for JDE Enterprise
Portfolios
By Mark Fairbanks
Editor’s Note: Our President, Andy Klee, encountered Mark Fairbanks at a user group
meeting in Carlsbad, California and was intrigued by Mark’s story about being on a two-man
upgrade implementation team. While Mark is certainly not recommending that scenario, he
became an avid fan of Agile Scrum concepts. He is now a man on a mission, strongly encour-
aging companies to make the total transformation to the Scrum team methodology. Quite a
fascinating subject and well worth reading.
Introduction
A remarkable milestone happened to me recently. I now qualify for the senior discount at Denny’s. Yes, I am
truly blessed to have made it to this remarkable and wonderful age. In assessing this stage of my life, as I
think we all do when we meet life’s milestones, I noticed that my taste for entertainment, sports, and music
has changed a lot since my earlier years. Where I once would have enjoyed a story that had a villain and a
superhero, I now find better satisfaction with stories that have a superhero team like “The Wolverines” in Red
Dawn Rising for example. Don’t get me wrong, I still like stories with superheroes; however, for me they just
don’t compare to stories with team work. Beatles songs rocked the world more than Paul McCartney ever did

129
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
as a soloist. I think we all enjoy how a team would “come together” and see the possibilities, even though it is
an impossible situation. That sort of attitude shows faith, encouragement, and seasoned experience. What I see
is a team that faces a giant problem, makes a few advancements and falters with a few failures, struggles, and
setbacks. But just when things are at their worst, just when the enemy mocks and the popular opinion shifts in
favor of the opposition, the team would rise with the determination to prevail. They pull together, learn from their
errors, and then practice their skills until it becomes like clockwork. The team becomes who they are and who they
were designed to be...Superheroes! With a team like this, the enemy doesn’t stand a chance.
The title of this article is the JDE Scrum Idea. The idea is about JDE teamwork. Agile is a concept of lean principles
and dynamics. Scrum is a framework for completing any complex project scope. It falls under the agile umbrella
along with other brands like Lean, Agile, XP and Kanban. The term Scrum comes from the team sport Rugby
because it reminded early Scrum founders of the teamwork involved in that sport. Scrum is not new. It has been
around for over 20 years; however, the idea of applying it to ERP implementations and other projects beyond IT
software development is indeed controversial and revolutionary.
My fellow JDE enthusiast, I am here to challenge you with what I consider a most excellent idea, and that is to
completely scrap traditional JDE project management implementations that follow the old Waterfall method, and
transform to the Agile Scrum idea for enterprise portfolios such as for JDE project implementations and upgrades.
This is not an adaption to Agile Scrum; instead it is a complete transformation because without such a change
you can never expect Agile Scrum to take hold in your organization, any more than you can expect a JDE client to
maximize full JDE potential without having the entire client organization go through its own JDE transformation.
This article introduces how Agile Scrum works and then takes you, the reader, through a fun corporate simulation
exercise where JDE Scrum is applied to an airport food service company. Agile thinking makes sense and Scrum
is easy to grasp. Owners and executive leaders love it. Working professionals and investors love it. So what is the
issue? Scrum opposes the industrial age mindset! For that reason this article will also focus on the Scrum idea
where leaders lead by not managing, but instead empowering teams of professionals to self-organize and win!
Many leaders today are looking for proven pathways of stability, realized profits, and quick implementation
results. Although corporate politics are thicker today than ever, they dream of leading passionate, self-motivating
professionals who are members of high performance teams that deliver with high success rates. If that leader
is you, then fasten your seatbelt, check oxygen settings, helmet visor down, left hand on throttle, right hand on
stick...get ready to blast-off!
Welcome to the Agile/ Scrum Revolution!
Agile Scrum came out of Toyota in the 1950s. Those of us who are fans of Edward Deming know the story where
these strategies are rooted; however, great Japanese ingenuity really took these ideas to the next level. During the
1990s, Agile took hold for software development where Scrum along with eXtreem Programing (XP) made Agile
Scrum believers out of developers; however, going beyond software development and using Scrum for projects like
ERP implementations, is just beginning to take hold. Previously, most project managers were stuck in the certified
Waterfall paradigm. Well, that is changing. Welcome to the revolution!
Remember the dot.com era? Just like Agile Scrum for ERP, the idea of transforming to an online business was
revolutionary only a few decades ago. During this time, pundits had claimed that the Internet would never amount
to anything more than an electric board for geeks to play with. In 1999, I worked for Xerox in San Francisco. I was
principal consultant of e-business for the West Coast including Alaska and Hawaii. They called me Mr. E-Business!
It was a magical time to be in consulting. I was fresh out of graduate school and we were doing great. Many
corporations were early adopters of e-commerce and they were realizing large results. We were helping companies
like Gap, Inc. with stores such as Banana Republic, Old Navy, Gap, and Gap Kids. It felt great to be part of the
online revolution, but not all business owners and executive clients were convinced about the online business
revolution. The concept was too new and for some it was hard to grasp. Yes, like Agile Scrum today, there were
misconceptions and really bad rumors. Some companies experienced serious trouble with adopting e-commerce

130
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
into their business and the media was split 50/50. Was online business only a fad, or will e-commerce grow?
Online business started with a rise in the late 1990s, a fall in 2000, and just after September 11, 2001 there
was a dot.com crash. But what happened in the aftermath? Early adopters succeeded and late adopters folded!
Companies like Amazon took over majority market share in book sales, while Borders books said goodbye as it is
no longer with us. Today no one questions online business. It is now mainstream and here to stay.
We are in that same type of revolution today with Agile Scrum, and the momentum is picking up! Leaders and
investors are taking note of the remarkable experience and profitability realized as companies transform to Agile
Scrum and gain better profit ratios. With this in mind, Agile Scrum is a perfect fit for ERP delivery. This is not to
over simplify the complexities of any ERP implementation; however, there are five basic components to consider
when implementing any ERP application:
1. Business users
2. Hardware infrastructure
3. Installation of ERP
4. Configuration of ERP
5. Data
Agile Scrum addresses these five ERP areas very well. In Agile Scrum, there is a product that can be demon-
strated at the end of each sprint. Furthermore, an Agile Scrum team can be replicated and scaled to cover an
enterprise portfolio where there are multiple locations. The only challenge I see is where organizations would
need to embrace Agile Scrum 100 percent in order to become successful. It takes full transformation! That is
because implementing JDE with Agile Scrum is radically different than Waterfall. A Scrum Master is not a Project
Manager and Agile Scrum is not SDLC. Agile Scrum best practices are radically different than the Waterfall. It is
not Waterfall…In fact, it opposes industrial age methods.
Agile Scrum vs. Waterfall is a Null Comparison. They Don’t Compare!
I recently read a blog on Agile vs. Waterfall, and in this article it claimed that Agile Scrum projects were nebulous
and unpredictable. It cited that Agile Scrum did not have solid planning with timelines and estimates. When I first
read this, I thought about how greatly misinformed the writer was. It then dawned on me how incomparable Agile
Scrum is to the Waterfall method. It’s like looking at an object from an entirely different viewpoint. Sort of like
an ignorant cat that thinks the dog is angry because it is wagging its tail, when in fact the cat is interpreting the
signal only from what it knows. The writer of Agile vs. Waterfall was only looking at Agile Scrum from a tradition-
al Waterfall management point of view, so of course what seemed to be madness in Agile Scrum, was really its
strength!
The Waterfall is project-based, Agile Scrum is team-based. I can understand putting it down if the comparison of
Agile Scrum and Waterfall is coming from a pure Waterfall point of view. But for those of us who know and have
delivered Agile Scrum projects, this statement sounds like something from way back in the past. Something that
a horse and buggy driver would have said back in the 1840s about the concept of a passenger jetliner, had such
a concept been around back in the 1840s. The buggy driver would have said, “I see no poop scoopers in the jet
aircraft design; thus, this idea is nebulous, not factual and incomplete. Those jetliner plans have no provisions for
the horse. Hey...What about the horse?”
Agile Scrum and Waterfall are not comparable at all. In fact, just as jet power is measured in pounds of thrust,
being that it is way beyond horse power, the Scrum Agile project framework is also a complete paradigm shift.
Traditional Waterfall Management is completely opposed to Agile Scrum! To clarify, in Agile there is indeed a
strategy, a structure, and an end result. That result is to have a finished and proven workable product at the end
of each one- to four-week sprint.

131
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
The One Minute and Ten Second Crash Course on Agile Scrum
If you have no exposure to Agile Scrum, don’t worry! It is very simple. Keep in mind that agile is a concept and
Scrum is a framework. Agile Scrum is fascinating, especially for those who are leadership enthusiasts. It follows
Edward Deming’s Empirical Process for Continuous Improvement: Plan – Do – Check – Act (PDCA). It has time
iterations from one to four weeks. Once the team chooses the iteration cycle, that duration remains constant. The
actions within each iteration are to Plan, Build, Test and Deliver a final product. Agile Scrum also follows lean
ideas inspired by multiple strategists, thinkers and great minds. Its team dynamics follows Tuckman’s Team Devel-
opment Model: Forming – Storming – Norming – Performing. Other characteristics that are present include Lean
Thinking and Pull, as opposed to the Push theory found in traditional management. Let’s see how Scrum works.
Figure 1: The Agile Scrum Framework
Agile Scrum in Action
When the team is in motion, Agile Scrum is cyclical with incremental deliveries. Picture a sine wave of a frequency
(see Figure 1). If you view the chart in Figure 1, top left, you will see the statement “Stakeholders Define
Product”. This happens once the business requirements are identified in terms of understanding its feasibility,
risks, business value, assumptions, and its expected ROI. This kicks off the sprint cycle. Now, let’s set this sprint
cycle in motion. Look at the chart in Figure 1, at the start of the first incremental sprint cycle going from left to
right.

132
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
The first thing the team does in the sprint is PLAN!ggggg
Here the Product Owner builds the product backlog. The yellow sticky notes represent three types of items.
Product Backlog Items
Item-1 Must Have
Item-2 Should Have
Item-3 Could Have
Once the product backlog is complete, the Product Owners tell the team what the top priorities are. The team
then meets to plan the Sprint Backlog. Starting with the top priorities for the sprint, the team has two goals to
accomplish.
Goal A: What? Goal B: How?
What Product Backlog Items (PBI) can we
commit to in our sprint?
How long do we think each item will take to
complete?
The second thing that happens as we move forward with the sprint cycle is we BUILD!
Here developers start building. The team is self-organizing, cross functional, dedicated full time, and clearly un-
derstands the product vision. Team members delegate and divide the tasks among themselves and together they
commit to the sprint cycle to complete, demo, and deliver the first priority product.
Adding strength to the project, some key points about team dynamics in Agile Scrum are as follows:
Scrum Team Dynamics
1. The team is transparent and user/client inclusive
2. Estimates are done quickly by the team
3. Strong communications happen because trust happens
4. Team meetings are daily and under 15 minutes
5. Scrum uses motivators that are very effective
6. Scrum is Value Based so time is spent on creating “value” as a product
7. Team members are empowered to create
8. Individual team members are not called “resources” they are called professionals, or people!
9. Corporate goals are met and team members love coming to work

133
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
The third thing we do as we move forward with the sprint cycle is we TEST!
As opposed to Waterfall where manual, automated and unit testing happens in a separate phase, and where the
philosophy of the Waterfall is to find defects. Agile is quicker and more efficient where testing happens right as
building takes place. The Agile way is to prevent defects from happening in the first place.
Scrum Testing & Validation Dynamics
Test early and often, make improvements, then test again
Goal is to build, test, and demonstrate product value
The fourth and last thing we do as we move forward with the sprint cycle is we DELIVER!
At the end of the cycle, the team delivers a complete product that can be demonstrated to the product owner and
stakeholders. Since the customer is included as a team member and continually knows the status of the product,
there are no surprises!
Scrum Meetings, Artifacts, and Teams
Now let’s go over Agile Scrum meetings, Artifacts, and Team Roles. Please note how very different each of these
are to your experience with Waterfall projects.
Scrum Meetings: In the Agile Scrum framework there are four meeting types: Planning, Building, Review, and
Retrospective.
Four Types of Scrum Meetings
Planning
Meetings
Release Planning happens at project start and Sprint Planning happens at the
beginning of each sprint.
Building Meetings Daily 15-minute Scrum Meeting with three main questions: What was done
yesterday? What needs to be done today? Are there impediments?
Sprint Review At the end of each sprint, the development team demonstrates the completed
product (increment) to stakeholders for feedback. Here the Product Owner has
already approved the product.
Retrospective This is the private team meeting held at the end of the sprint where the team
reflects with the goal of identifying ways to improve.
Scrum Artifacts: There are three main artifacts: Product Backlog, Sprint Backlog, and Product Increment.

134
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Figure 2: The Three Main Scrum Artifacts
Incidentally, eight years ago I built a complete set of project document templates needed for the Waterfall. It
came out to be seven documents for phase one assessments, 24 documents for phase two planning, six more
documents for phase three design, and I’ll stop there. Not to mention meeting minutes and weekly reports. This
is why the Agile Scrum team is much more capable to deliver. Planning, design, and documentation is direct, to
the point, and in the hands of many, not the few. Scrum brings customers onboard as team members. This is next
generation, information age thinking. Compare this with Waterfall! An Agile Scrum team can deliver a finished
product, and prepare for the next Scrum adventure, long before those who work under traditional Waterfall
parameters would have a chance to complete the initiation phase of planning, collecting specifications, estimating
and writing documentations as this is necessary under industrial age thinking.
Agile Scrum Teams: Lastly, there are three team member roles: Product Owner, Scrum Master, and
Developers. All team members are responsible to create a value product at the end of each cycle.
Agile Scrum Team
Product Owner There is one Product Owner. That person is typically a department head from the
business user side. This is a very busy role where the Product Owner must define
the features, achieve ROI, prepare the product backlog, set the vision and priorities,
and accept or reject work.
Scrum Master There is one Scrum Master. That person is a coach, team guide, and servant leader
who is focused on empowering the team.
Developers The ideal team has seven developers; however, depending on the scope, the
acceptable development team has from five to nine members. Developers are
dedicated team members; thus, they are not allowed to have other responsibilities
outside the team.
Why I Started to Think JDE Scrum
My testimony began a few years ago. I am an ERP Project Consultant and I was hired by a high fashion clothing
and apparel company in downtown Los Angeles to help manage its transformation to SAP; however, when I
arrived, I discovered the SAP project had run out of money. So the high fashion company had to stick with the ERP
it had. It was using an expired version of JDE (8.10), so since SAP was on hold, they decided to upgrade it. I have
prior JDE implementation experience, so I was asked to stay on board and manage the JDE project.
This was an Oracle JDE Enterprise One upgrade from 8.10 to 9.1, but there was a catch…For the entire JDE
“enterprise” project involving 1,100 employees, I was given a zero dollar budget, and one fulltime team member
to work with. That’s right! A zero budget and one person to help implement JDE for Accounts Payable, Job Cost,
Fixed Assets, General Ledger, Procurement, and Distribution across the enterprise involving 500 stores worldwide.

135
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
It also involved user training, inbound/outbound integration to EDI, and User Acceptance Test coordination. I was
the JDE project manager and I also wore other hats. Jonnel Tenorio was the JDE developer/ functional expert. He
wore other hats too! That was it…This was my fulltime implementation team!
My instincts told me to run quickly to the parking lot, and keep running! But by nature I am always up for a
challenge. What do they call this? Never mind. As it turns out, Jonnel is seasoned and multitalented, which fits
the profile of a Scrum developer. He knows JDE extremely well as both a technical and functional professional.
While working for Accenture Consulting, Jonnel gained expertise in CNC, OMW, JDE development, retrofits, UBE
and financials, procurement and distribution as well as RPG, MSSQL, data conversions, and more. In addition, he
has a strong passion for JDE. As we worked together, Jonnel would always practice certain aspects of Agile Scrum
including team dynamics, transparency, collaboration, and motivation.
Because our implementation project was so lean, we both had to step up to the plate and get very creative and
innovative. We wore multiple hats and we discussed strategies, timelines and goals, building out the project in
increments. We both understand business processes well and even though a Scrum team is five to nine profession-
als, not two workers, we always were seeking to strategize and improve just as if we were performing Agile Scrum
in our JDE implementation. It is a rare thing to find this sort of teamwork.
Sure we had our share of challenges. For instance we ran into snags with those early E1 9.1 defects; however,
with Jonnel’s can-do attitude, he was able to quickly sort out and solve those JDE issues. We also had a strong
circle of extremely friendly and collaborative JDE experts to reach out to and get advice. Such is common in JDE.
These folks were from our JDE Southern California User Group and included JDE consulting firms like ZTNet
Solutions of Irvine, California who we are so grateful for. They helped us a lot! These experts have a true passion
for JDE, so knowledge is shared openly. What is even more impressive is the sincere desire these folks had for our
plight. It was late 2012, early 2013 and JDE E1, 9.1 was brand spanking new! They knew our zero budget, two
man team story and they were rooting us on! Although our team was small, it was strong. To work with Jonnel
was like being on the Lakers basketball court with Magic Johnson, who plays all five positions! Together, we were
a JDE team made up of multitalented team members. Again, this is the profile of a JDE Scrum team. One special
thing to point out about Agile Scrum: Its team members must be seasoned and multitalented. Under the tradition-
al management mindset, Human Resource managers do not quite know what to do with the resumes of seasoned
multitalented professionals. Agile Scrum welcomes and utilizes multitalented business and technical professionals.
So if you are one, please apply here!
In spite of our zero dollar budget and our two-man team, we got JDE up and running in PY (JDE test environ-
ment) so fast that old man time did not even have a chance to shake a stick at it. Of course we gained some part
time help with two top notch BCBG relational managers and some exceptional EDI experts as we went through
integration. We also had expert, over the shoulder JDE help from ZTNet Solutions. But Jonnel and I delivered
the majority of the project including UBE development, customization, and retrofit, JDE user training and user
acceptance testing through to delivery.
In the end, we left our JDE business users and super users very happy with the JDE product. JDE delivered very
well. Top executives and users began to question the sanity of going through SAP transformation as they come to
love the stability and usability of Oracle JDE E1 9.1. As for me, I was amazed that the JDE implementation project
went so great in spite of a two-man team. I not only fell in love with the new JDE Enterprise One product, I began
to think about how we did it and how quickly the project would have delivered had we had a full Scrum team!
I discovered how JDE product increments can deliver well within the short iterations of Scrum sprints. With this
successful implementation, I got a glimpse of how Agile Scrum would fit in an enterprise wide portfolio.

136
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
JDE Scrum
Now let’s have some fun and learn the steps of an enterprise wide JDE implementation through role play. We are
going to use a simulated company that is in the fine foods industry.
Simulated Implementation of JDE Scrum
The simulated company that we have created for this exercise is called 747Jet Gourmet. 747Jet Gourmet fulfills
a huge void for domestic business travelers by providing delicious hot and freshly prepared carry-on meals that
fit those onboard backseat trays. Just like the old days of air travel, they provide combination meals with Beef,
Chicken, Fish, or Veggies. Each main course is prepared with delicious side dishes and a sweet dessert. These
hot takeout meals come in thermo boxes that keep food warm for up to six hours. 747JetGourmet has cafes at
every major airport in the U.S. Passengers can purchase a meal, carry it onboard, annoy other starving passengers
who have no meal, enjoy the meal while flying and return the recyclable patented thermo dishes at any of
747JetGourmet kiosk locations for a $5.00 coupon toward their next meal. Takeout meals are prepared fresh and
reasonably priced. Travelers love it. Market share is growing sharply as its popularity is catching on; thus, business
is very good and daily volume is high. Well, it is a steal because there are no good places to eat at airports.
747Jet Gourmet fills a gap. Now meals on the road can be planned, families with children no longer need to
worry about having no food available on a six-hour flight.
747Jet Gourmet is headquartered in Las Vegas, Nevada. This is also where the manufacturing plant for the thermo
boxes is located. In addition, 747Jet Gourmet has six operational processing plants in business friendly states like
Alaska, Washington, Wyoming, South Dakota, Texas and Florida. Each of these locations has different work flow
challenges and processes. The budget is $12 million; however, such as it is with innovative food services ideas,
747Jet Gourmet can experience a flood of competition during its early success; therefore, it needs to move quickly
so that it can rapidly conquer market share. 747Jet Gourmet began its Agile Scrum transformation back in 2012.
Today the transformation is fully stabilized and the executive board wants JDE to be an Agile Scrum implementa-
tion only.
How will this be accomplished? Let’s start with the Scrum team.
JDE Scrum Teams
Introducing the JDE Scrum Team. Notice the happy faces? Here, professionals are free to be professionals, as they
are no longer bound by industrial age thinking!

137
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Figure 3: Introducing the Scrum Team
The JDE Scrum Team shown in Figure 3 reflects the same JDE Teams that will be rolled out to each of 747Jet
Gourmet’s locations. Each member is highly seasoned and multitalented. This is what is needed at 747Jet
Gourmet. Since 747Jet Gourmet has seven locations, the Scrum team will be replicated into multiple teams in
order to cover the entire JDE enterprise portfolio (see Figure 4).

138
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Figure 4: 747Jet Gourmet – Our Simulated Company for JDE
Implementation takes place across the entire 747Jet Gourmet enterprise. The JDE Scrum implementation team will
be spearheaded by one Product Owner, who will be located at the Las Vegas headquarters. There will be seven
JDE Scrum Masters and 35 Scrum developers on site. An area Scrum Team will be dedicated to each location. In
Scum, multitalented professionals are referred to as “developers”. It is not exactly the same as we all know a JDE
developer to be. JDE Scrum developers on the team would have different skillsets; for example, technical CNC or
DBA, and functional finance or business analysis. Together the Scrum development teams will co-locate, collabo-
rate, and cover the entire JDE enterprise implementations.
The job of a Product Owner is extremely busy, especially if it is a large JDE enterprise-wide implementation. As the
product backlog gets built, it is quickly realized that there are way too many components to think about. In order
to accomplish Release Planning for Oracle JDE, the Product Owner needs to rely heavily on the Scrum Masters of
each area location. In the Scrum certification training, Product Owners learn to focus on the product and avoid
the micro-details. They also should not become overburdened with large deliveries. It is the Scrum Masters’ job to
keep the Product Owner, Scrum Developers, and other stakeholders on track within the parameters of the Scrum
Framework.
For the 747Jet Gourmet simulation, each site has business and operational processes that are unique; therefore,
each of the seven sites will have Scrum teams consisting of one Scrum Master and from five to nine developers
depending on tasks that need to be completed.
Below is an outline plan for how communications will take place. There are several Scrum application tools that
can be used for building the product backlog, the sprint backlog, tracking, and for daily scrums. Scrum is highly
visible. Scrum team members often use whiteboards and lots of sticky notes, so for an enterprise wide portfolio
it would be good to invest in screen projectors and/or dedicated large flat screen displays that show the Product
Burndown List.

139
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Figure 5: Communications Strategy for Multi-Located JDE Scrum Teams
Again the process of Agile Scrum is simple; however, this does not diminish the complexity of a JDE implementa-
tion; therefore, as one should for any project, tasks need to be broken down into manageable, bite-size pieces. For
this, the Scrum framework offers the Product Backlog, but instead of just listing tasks, a Product Backlog task is
more descriptive with User Stories that go like this: As a/ an . . . (User, Provider, Administrator) I want to . . .
(Do something) So that . . . (I can help others). It looks like this:
Product Backlog
Task
I.D.
Task User Story Primary
Workflow
Secondary
Workflow
Task
Type
Estimate
Hours
Task
Priority
021 As a Procurement Manager I want to create a
Purchase Order and have it approved by my manager
in JDE, so that I can order inventory.
Procurement N/A Feature 30 Must
Have
022 As Procurement Manager I want to have the P.O.
status displayed in full colors on my living room TV.
Procurement N/A Feature 10 Won’t
Have
Item task priorities are expressed as: Must Have, Should Have, Could Have and Won’t Have. The “Must
Have” tasks are first priority. They are built first. The “Won’t Have” tasks will be removed completely, or saved on
an enhancement list for another project at another time in the future.

140
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Once Stakeholders define the business strategy, it moves to the JDE enterprise portfolio. From there the project
starts and Release Planning begins. The Product Backlog above is the first artifact built, as seen in the bottom left
of Figure 6 below.
Figure 6: JDE Scrum Framework for Multiple Team Locations
For the purpose of this simulation, let us assume the infrastructure at 747Jet Gourmet is fully operational and
the server environment is ready for JDE to be installed. Let us also assume that each location is unique where
the customer requires teams to implement on location. The next step would be to install JDE throughout the
enterprise and to configure each functional module. Each co-located JDE Scrum team will build their Sprint
Backlog from the Product Backlog. For each task item, the JDE Scrum team will consider how much effort is
required, how long it will take, and how much can be accomplished within the sprint cycle. Each team will go
through the iteration cycles simultaneously. For this example, timing will be set at four-week sprint cycles. In
Scrum, once the team decides the sprint duration, it will remain constant.
Once all the teams are set in motion, they will begin to perform incremental deliveries as shown in Figure 7
below. Here the iterations are relative to its location. For example, the Nevada headquarters has the Thermo
Hotbox manufacturing plant. The Nevada site also is the main distribution route for the West Coast. Therefore, in
addition to needing JDE Finance application modules, the 747Jet Gourmet Nevada HQ will also need to install JDE
Manufacturing and JDE Distribution.

141
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Figure 7: From Multiple Locations, JDE Scrum Teams Build Product Iterations Toward Final Delivery
Actions within each iteration and for each of the JDE Scrum teams are to: Plan, Build, Test, and Deliver a final
product with each sprint. So picture each area with a dedicated JDE Scrum team delivering a working demonstra-
ble product at the end of each four-week sprint, starting with JDE installation, then moving to the configuration
of a functional module like Finance, then Distribution, and then Manufacturing in each area.
With a dedicated JDE Scrum team, implementations stay focused. Most traditionally managed implementa-
tion teams are not focused. Instead they are scattered on other programs and other projects. This is not what
will happen on a JDE Scrum project. It has been proven time and time again that efficiency breaks down when
workers are required to multitask. It takes more time to shift focus between two tasks. Certified Agile Scrum team
members learn this in training. Scrum teams remain focused!
Agile Scrum is Catching On!
More and more organizations are transforming to Agile Scrum. According to the Scrum Alliance website, (scrum-
alliance.org) Scrum is the leading agile development methodology, used by Fortune 500 companies around
the world. Great Japanese companies like Fuji-Xerox, Honda, and Canon all follow the best practices of Agile
Scrum. Companies such as Amazon, Siemens Healthcare, Yahoo, Intel, PayPal, Microsoft, and even SAP have all
undergone Scrum organizational transformation. So has Salesforce.com. In fact there is an excellent write-up
on Scrum in Forbes magazine. It’s titled Six Common Mistakes That Salesforce.com “Didn’t” Make! This
article discusses six common mistakes that Salesforce didn’t make with its transformation to Agile Scrum. Mistake
one and six are the most common and serious errors: That is “Mistake #1: Introduce the change as just another
business process” and, “Mistake #6: Skimp on training and coaching”. If you read the article in Forbes magazine,
you will discover why other companies that attempted to adopt Agile Scrum have failed. As I paraphrase, the
article goes on to mention that the CEO of Salesforce.com, Mr. Marc Benioff was evaluated by Forbes to be the
highest value CEO on the planet. You see, the transformation to Scrum, “helped deliver a 41% annual return to
shareholders over a sustained period”. (http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mis-
takes-that-salesforce-com-didnt-make/)

142
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
A more notable organization that transformed to Agile Scrum is the Department of Defense (DoD). The DoD
completely scrapped Waterfall in favor of Agile after citing the continual failures of the Waterfall. I worked many
years as a consultant for DoD. I know the culture. This was not just a tippy toe approach, it was a complete trans-
formation. In fact, what is even more remarkable is the fact that the Agile transformation began in 2010. Read
OSD_Sec_804_Report. Section 804 of the National Defense Authorization Act for Fiscal Year 2010 (FYIO NDAA,
PLlll-84). (http://www.scruminc.com/dod-goes-agile/).
As government organizations and private industry transform to Agile Scrum, they will eventually be calling on ERP
solutions and services. Will there be any JDE Scrum providers available to answer that call?
Seven Profitable Reasons to Consider Agile Scrum Transformation
Shall we give ourselves permission to question the sanity of an industrial age mindset in management, when we
see the same old setbacks happening over and over, in place of moving forward and prospering on the job? Let’s
take into account the following questions:
Are we currently maximizing our job performance to the betterment of all?
Are workers empowered to innovate?
Are corporate politics so overbearing that they harm profitability and crush innovation?
Traditional “Industrial Age” thinking is self-imploding. It does not know how to plant seeds and cultivate. It
refers to intelligent people as a “Resource”. It sees skilled workers as a price-based commodity. Sure, business is
business and at times cold decisions are necessary. But corporations do not need to be blinded toward finding the
gold in its skilled professionals, and its potential candidates. Agile Scrum taps into the ingenuity of people. It is
value-based! Here are ten profitable reasons to transform:
1. You get to work directly with the customers, who are also key Scrum team members.
2. Work happens quickly and products deliver sooner than later.
3. Your voice gets heard.
4. You get your life back! Professionals are once again seen as being human. Good riddance to those 70- to
90-hour work weeks and Helter Skelter implementations.
5. Value that drives organizations toward sustained profitability.
6. Trust. Team member roles complement each other. Team members stay onboard!
7. Short, precise and profitable meetings.
8. Project documentation trimmed down by as much as 90 percent.
9. Innovation. The possibilities are endless!
10. Happy workers! Teams build, grow, and mature as team members perfect their skills.
Excellent ideas rise above the rest, they have continuing profitable futures for all, and they consider value-based
leadership, over price-based management. It takes absolutely no brains to manage price-based thinking because
it only seeks to minimize cost and maximize profits, no matter the consequences. Value-based leadership takes
ingenuity, strategy, and skilled leadership. Agile Scrum is a forerunner of value-based ideas.

143
Project
Management
JANUARY
2015
VOLUMEIII
ISSUE1
Final Thoughts about Agile Scrum JDE Implementations
In this article we learned that in order to successfully change to an Agile Scrum organization, it takes complete
organizational transformation to Agile Scrum and away from the traditional management that came from the
industrial age 100 years ago. We also went through a JDE Scrum simulation where we learned how Agile Scrum
can fit very well for JDE implementations. Finally, we learned that there are high rewards, strong benefits, and
teamwork longevity that happens when JDE implementation teams transform to JDE Scrum. I challenge you to
research Agile Scrum and investigate even further. You know the old quote:
“There is a principle which is a bar against all information, which is proof against all
argument, and which cannot fail to keep a man in everlasting ignorance. That principle is
condemnation before investigation.”By Herbert Spencer (1820-1903)
Agile Scrum is an excellent idea for ERP implementations. Such excellent ideas challenge us to think more openly
and question what we do. For instance, why SAP for large scale enterprise portfolios? Why not Oracle JDE?
It is here within the team of “superheroes”. That is where the ingenuity and value of each JDE implementation
practice applies. I have my own trade secrets and in time, those of you who transform to the JDE Scrum idea will
also develop your own secret sauce. Keep in mind that by nature, Agile Scrum is very adaptable and flexible. It
also involves continuous learning where teams inspect and adapt; therefore, there are a lot of different ways to
apply JDE installations and tweak its implementations for optimization within the Agile Scrum framework. This is
possible because it is a highly innovative environment. Of course the 747Jet Gourmet simulation presented in this
article is a more extreme scenario than an average JDE implementation for a small to medium business would be;
however, is shows how JDE can scale up and grow even larger…Think of the possibilities!
Mark Fairbanks (CSM, MS, MBA) is an Agilist and Oracle JDE Enthusiast. He works as an ERP Implementation
Consultant, Project Manager, Scrum Master and Business Developer. He is also an Adjunct Professor at Ashford
University, and the University of Phoenix where he administers courses in Business, Project Leadership, Operations
Management and Software Applications Development. Mark is a member of JDE Southern California User Group
(SCUG) and a member of Agile Coffee, (Scrum Agile User Group) in Irvine, CA. You may contact the author at
JDEtips.Authors@JDEtips.com. Be sure to mention the author’s name and/or the article title.
Reference Links:
http://www.agilecrossing.com/index.php/resources/
www.scrumalliance.org
http://www.scruminc.com/dod-goes-agile/
http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-that-salesforce-com-didnt-make/
http://quotes.liberty-tree.ca/quote/herbert_spencer_quote_30e4
Visit www.JDEtips.com for information on JDEtips University schedule, on-site training and consulting, and our
Journal Document Library.

Article- The Scrum Idea - JDEtips-Jan2015

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Article- The Scrum Idea - JDEtips-Jan2015

Ähnlich wie Article- The Scrum Idea - JDEtips-Jan2015 (20)

Article- The Scrum Idea - JDEtips-Jan2015