xCrumBan

After 22 years of working in IT and having worked with Agile methodology, waterfall methodology, iQMS
methodology and even with SAFe, it occurred to me to invent a framework that takes the best of other
frameworks according to my personal criteria. I named this new framework XCrumBan since it takes
concepts, practices and events from XP (Beck, 2004), Scrum (Sutherland, 2014) and Kanban (Association,
1986).

Why a new framework?

Because in the world of software you have to evolve daily since the only constant are changes. If you do
not adapt, it is very likely that you will become obsolete and cannot compete in the changing maelstrom
of this beautiful profession that challenges us every day and demands that we be continually updated.

Next, I am going to indicate the practices that were taken from each framework *:

Scrum

 Standup
 Retrospective
 Incremental iterative development

Kanban

 Kanban board
 Pull to production
 Limit W.I.P.

XP

 Refactoring
 Pair programming
 Continuous integration
 40 hour week

1
Why do I take these practices, not others, and what other practices do I take?

Because in my opinion they are the best that serve the purpose of this new framework and therefore
become the most suitable. With the standUp we are aware of everything that is happening and with the
Retrospective we can look back and seek improvement actions.

Being pull like Kanban and not push like Scrum, value can be added and delivered in production quickly
on a daily basis since there is no need to wait for the completion of a Sprint to deploy. Therefore, point
estimates are not made either as there are no Sprints i. By not making estimates, the time dedicated to
estimating is saved, which by the way is a best guess that we can have regarding what may happen and
many times the estimated number of points are not finished, having to finalize the points pending in the
next Sprint. It usually happens that a Senior programmer gives 2 points to a card while for a Junior
programmer gives the same card an effort of 13 points, which takes time since both must agree on the
effort and one must convince the other. Who has the reason? Both, since from their point of view and
knowledge they estimate the effort according to their experience. Instead, to estimate with more real,
probable and with greater certainty scenarios, the Monte Carlo method could be used.

By making constant deliveries in production, you can have early feedback from both the customer and
the end user and correct early those things that need it. If a card is finished, once it has gone through
the respective controls and deploy in the different environments, if the complete functionality is not
ready, a feature toggle can be incorporated to turn it on when it is completely finished. This allows us to
evaluate if the code put into production causes failures in the system, to avoid them early and also
allows us to evaluate the interactions of the different parts of the code.

When making periodic deliveries, you can also use the canary release approach and enable the
functionality by zones or groups and thus have early feedback, detect errors and verify the acceptance
of changes or validate the hypothesis without affecting all users of the system because that the new
functionality is enabled for a small portion of the universe, and as its correct operation is verified, the
universe can be expanded to enable the functionality in its entirety. Testing in production is the actual
mechanism which makes things better. Because it changes how we think about and do QA it upsets a lot
of "status quo" thinking. The cost of incorporating toggles is that when all the functionality is in
production, you have to remove the code of the toggle because it will dead code therefore, you have to
analyze the cost-benefit ratio when implementing them.

A good practice that can be incorporated in those teams in which there is no person to perform QA for
whatever reason, usually because the customer cannot pay it, is to do cross-checking. This means that
once the development is finished and the unit tests have been carried out, another programmer
performs a code review to verify, among other things, that the development is not complicated, has
been optimally carried out using good practices and clean code, and also to verify adherence to the
standard used, and once this review is finished, the developer proceeds to carry out the respective QA.

2
By limiting the W.I.P. and therefore avoiding multitasking things can be finished faster. Imagine that you
have to perform 3 tasks A, B and C, if you multitasked you would do a little A, a little B and a little C, but
by limiting the number of tasks that can be performed at one time; in the time it took to make those
parts of A, B and C, A would have already been completed and therefore it would be closer to reaching
production and therefore delivering value which is precisely one of the things that we proclaim in agility,
the constant delivery of value.

Refactoring and Continuous Integration allow us to improve the code in an evolutionary and
incremental way and to add value throughout the entire process. Another figure to take into account is
the Technical Debt that we will have to pay gradually so that those things that we did in a way in order
to deliver before do not explode in our face for not paying it on time. The 40-hour workweek allows us
to work with people who are awake and not brain-burned from being overworked. From experience the
80/20 rule could be applied since a person cannot be assigned to a project more than 80% of his time
since he has to have adequate rest and recreation times, he has to do paperwork, go to the doctor, etc.
As in life there are always imponderables, people must feel that they have enough time to be able to act
in an emergency without feeling pressured to fulfill the 8 hours a day of work, even more in IT that we
work usually by objectives and while people meet the objective they can do it in the time they stipulate
is correct.

Other events that can be implemented to achieve a greater understanding of what must be developed
and corroborate that complies with what is requested are KickOff and Desk Check of the stories. The
KickOff of the stories is done before coding to ensure that the developer, QA and BA and PO are aligned
regarding expectations. This allows to avoid wasting time by having to re-develop and re-test what could
have been done well from the beginning if you had had a good understanding of what to do. What one
hears may be interpreted differently by another person. Memory is not always reliable for stories that
were reviewed a few days or weeks before. In the KickOff it is verified that the developer understood
what has to be done, negotiations, arrangements and commitments are made and, above all,
assumptions that could lead to rework are avoided. The idea is to make sure we are all on the same
page, therefore the wording within the story can be modified or additional notes can be added to
provide clarity. In Desk Check, a history check is performed when encoding is complete, but has not yet
been sent to production. Participants include the same people involved in the KickOff. The developer
demonstrates the functionality created and cross-checks the story requirements and mockups if any. If
you are not satisfied with what has been done, this is a opportunity to modify a requirement or correct
the code before hitting production. In summary, to avoid confusion about what to do; Kick Off and Desk
Check can be performed. The Kick Off is done before starting the development, and what is sought is to
reach an understanding of what has to be done. The scope of the card is reviewed, limits and / or out of
scope are set, acceptance criteria are reviewed and concessions are made. In short, the card is reviewed
from top to bottom to avoid misunderstandings and it is ensured that the development is carried out as
specified. The Desk Check is carried out once the card has passed Code Review and QA and we verify
that the development has been carried out as requested. The programmer must show that what is

3
specified has been fulfilled and also depending on whether the case warrants it, the sad path and edge
cases are tested.

Another artifact, so to speak, that can be implemented is the Slicing, which basically consists of playing
Jack the Ripper with the system that we are going to build and chopping it into smaller pieces. Those
pieces have an end. The first piece is called Epic, which would basically be the complete system to be
built, from that piece we start others called Features that would be the different functionalities of the
system and from those smaller pieces we chop them even more and make them smaller and call them
Stories. That are the ones that will finally be developed. To promote rapid development and deliver
value as quickly as possible, these stories should not be very large. In general, a story is very large if it
has more than 4 or 6 Acceptance Criteria and if this happens, that Story should be split in two.

What pains does it address and what benefits does it bring?

In XCrumBan we get rid of the complexity and ambiguity of point estimates since as I explained above in
my experience this generates confusion among programmers. Also, I don't see that something as
relative as points brings great value to the customer. It has happened to me several times that when the
client is told that X functionality will carry Y points, they do not understand what I am talking about and
they often ask for approximate dates.

Limiting the W.I.P. it generates focus on what is being done and allows faster deliveries and therefore
add value to the customer early.

By working 40 hours a week applying the 80/20 rule, people are more committed and enthusiastic about
the project and end up adding much greater value to it and therefore to the client. A person who feels
appreciated will always do more than what is expected.

Doing canary release allows us to carry out tests in production, validate or refute our hypothesis and,
above all, not affect 100% of the universe of users.

Using feature toggles allows us to know and understand the behavior and interdependence of the new
code. Be careful, as I explained, you have to take into account the cost of using them.

While performing Code Review and QA (cross QA) and Kick Off and Desk Check makes us a little slower
when delivering, it also makes us more effective since we take all precautions to not only deliver value
but also to deliver code tested and developed according to specifications and therefore we avoid rework
and errors in production.

4
What is the future of XCrumBan?

As Master Yoda would say: However, the future of XCruBan uncertain is. Proceed with caution we must.
But if this new framework is accepted and well received; in the book that I am preparing I will expand
other concepts such as Roles, Pillars and more.

Note: The XCrumBan framework is not intended to be a magical recipe that must be followed to the
letter, but rather it is a series of activities and events based on years of experience that each team must
analyze to see if it adds value to both the team and above all to the user/client; and therefore those
activities and events that have been considered most convenient in that analysis must be followed.

* I include a glossary in case you do not remember the terms or do not know them.

Standup: the purpose is to inspect the progress towards the goal and adapt the Sprint setback as
needed, adjusting the next planned work. It is a short instance of synchronization that lasts no more
than 15 minutes and for that time to be fulfilled and not lengthen, people are standing and hence their
name.

Retrospective: the purpose is to plan ways to increase quality and effectiveness. What the team did well
is reviewed to continue doing it and action items are sought on those things that can be improved.

Incremental iterative development: the project is planned in different time blocks (in the case of Scrum
maximum of one month or up to two weeks) called iterations. These iterations can be understood as
mini projects and in all the iterations a similar work process is repeated to provide a complete result on
the final product so that the client can obtain the benefits of the project incrementally.

Kanban board: is an agile project management tool designed to help visualize work, limit work in
progress, and maximize flow efficiency.

Pull to production: the Kanban pull system is a way to synchronize the flow of material and information
from disconnected processes to enable just-in-time delivery to production. It is called a pull system
because resources are into pull the pipeline only as they are needed or requested.

Limit W.I.P.: WIP stands for Work In Progress, the number of tasks a team is actively working on is
limited. It is a fixed restriction on a Kanban board that allows teams to finish tasks already in the system
before introducing more work.

5
Refactoring: is the technique of improving the code without changing the functionality. It's an ongoing
process of simplification that applies to code, design, testing, and XP itself. Instead of just saying "You
must keep trying to improve your code," you'll need a repeatable process to guide the refactoring.
Somehow some kind of refactoring has always been done as you go through the code and make changes
and improvements. The problem is that it is random and remains until the team has free time. In XP,
developers will refactor throughout the development process.

Pair programming: means that all production software is developed by two people sitting on the same
machine. The idea behind this practice is that two brains and four eyes are better than one brain and
two eyes. Effectively, you get continuous code review and faster response to persistent issues that can
stop a person in their tracks. Teams that have used pair programming have found that it improves
quality and doesn't actually take twice as long because they can solve problems faster and stay more
focused on the task at hand, thus creating less code to accomplish the same thing.

Continuous integration: is a practice where code changes are tested immediately when added to a
larger code base. The benefit of this practice is that you can detect and fix integration problems sooner.
Most teams fear the code integration step due to the inherent discovery of conflicts and problems that
result. Most teams take the "If it hurts, avoid it as long as possible" approach. XP practitioners suggest
"if it hurts, do it more often." The reasoning behind that approach is that if you experience problems
every time you integrate code, and it takes a while to find where the problems are, maybe you should
integrate more often so that if there are problems they are much easier to find because there are fewer
built-in changes to the build.

40-hour week: the concept is that programmers should not work more than 40 hours, and if there is
overtime one week, then the next week should not include more overtime. I add 40 hours or less. Why?
Our work is exhausting since our raw material for work is our brain and a burning brain does not
produce or produces badly and in general, extra expenses are incurred by having to redo the code
written in a state of burn out.

Bibliography

Kent Beck, Extreme Programming Explained: Embrace Change, 2nd Edition, O'Reilly, 2004

Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, Currency, 2014

Japan Management Association, Kanban Just in Time at Toyota, Productivity Press, 1986

Jonathan Rasmusson, The Agile Samurai, Pragmatic Bookshelf, 2010

Daniel S. Vacanti, The Kanban Guide, Orderly Disruption Limited, 2020

6
About the Author:

Venuti, Leonardo Daniel graduated in 2008 from the Technological Institute ORT Argentina as a Systems
Analyst, graduated in 2010 as a Bachelor of Computer Science from the University of Palermo and in
2014 as an MBA from the Pontifical Catholic University of Ecuador. He currently works as Scrum Master,
Agile Coach and Project Manager at Globant. He previously served as CRM Senior Consultant for ORACLE,
Business Analyst for ThoughtWorks, CTO for Pryffer and Project Manager and Business Analyst for IOET,
among other renowned companies. He has more than 25 years of experience in highly complex and
mission critical Information Systems.

You can contact Leonardo at [Link]

i
The concept of point estimation was introduced by Ron Jeffries and based on my experience I do not see them
useful, even Jeffries himself in his book Story Points Revisited says “I am sorry now”. Even Jeff Sutherland, inventor
and co-creator of Scrum said, “Estimating tasks will slow you down. Don’t do it. We gave up 10 years ago”.