XCrumBan

A Hybrid and Flexible Agile Framework

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

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 . 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.

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 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.

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.

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

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 https://www.linkedin.com/in/leovenuti/?locale=en_US