Abdelrhman Elsherbiny l DBA’s Post

✨ 𝗦𝗮𝗻𝘁𝗮 𝗖𝗹𝗮𝘂𝘀𝗲 𝗼𝗿 𝘁𝗵𝗲 𝗨𝗹𝘁𝗶𝗺𝗮𝘁𝗶𝘃𝗲 𝗜𝗻𝗻𝗼𝘃𝗮𝘁𝗼𝗿✨ Innovation and Santa Claus 🧑🎄 with his hardworking elves at the North Pole – it may sound like a fairy tale, but on closer inspection, it becomes clear that Santa is a true master of innovation: 🎁 1. Supply Chain Innovation: Delivering Gifts for Billions in One Night Santa is the undisputed logistics pro. Delivering billions of gifts on time for Christmas requires an almost flawless supply chain. The elves at the North Pole can be seen as the ultimative Fulfillment Center in magical form. 🧑🎄2. Agile Project Management in the Elf Team The elves are the epitome of an agile team. They work in small, specialized groups and possibly use Scrum or Kanban methods to ensure all gifts are ready on time. Flexibility is key: if a child suddenly changes their wish, the team can immediately react. 🎄3. Sustainability Santa Claus and his elves could be role models for sustainable innovation. The North Pole likely runs on green energy—wind, solar, and perhaps even magical polar lights power the workshop. The reindeer sleigh, an emission-free transportation solution, is another example of sustainable mobility. Rudolph and his friends could even be considered the predecessors of modern e-mobility—but without the battery issues! 🎀 4. Personalization Through Data Analysis Santa knows exactly who has been naughty or nice—a clear indication that he has access to a massive database. With advanced data analysis, he not only understands children’s wishes but can also predict them. Santa is a pioneer of personalized gifting, as every package is tailored to the recipient’s preferences. 🎇 5. Innovation Culture at the North Pole The elves not only work hard but also seem to foster a culture of continuous improvement. Every year, new trends and technologies flow into the production of gifts. Creativity and a willingness to experiment are top priorities for the elves. 🚀 6. Co-Creation with the Community Santa actively involves children in the innovation process: through letters and wish lists that allow kids to send their wishes directly to the North Pole headquarters. This dialogue between Santa and children is a prime example of co-creation and customer-centric work. 🌌 7. Inspiration and Vision For centuries, Santa Clause has inspired generations of children and adults with his message of joy, generosity, and hope. His ability to combine magic with efficiency demonstrates that innovation is not just about technology but also about the ability to inspire and connect people. Perhaps Santa Claus is the ultimate innovator, reminding us that, with the right team, progress and joy can go hand in hand. 🎄✨ Uwe Kirschner Luisa Wagner Levent Hikmet Sürer Sara Carvalho Manuel Krauß Martin Hoffmann Lukas Julius Elena Zehnder Stefan Jungmayr Dr. Andrea Bräuning Scarlett Hickey Jennifer Orani Frederic Redmann Lara Wildermuth

What should we say in our next book, 𝘛𝘩𝘦 𝘖𝘱𝘦𝘯 𝘌𝘹𝘦𝘤𝘶𝘵𝘪𝘷𝘦? I'm well into writing it, with lots of content from Dr. Cherry Vu. Those of you who have followed our writing journey may have recognised the progression: First we wrote 𝘛𝘩𝘦 𝘢𝘨𝘪𝘭𝘦 𝘔𝘢𝘯𝘢𝘨𝘦𝘳 (𝘴𝘮𝘢𝘭𝘭 𝘢), to capture all we had learned from global theory and our own practical experiences with the emerging better ways of working and managing. We succumbed to putting the word "agile" in the title to attract readership, although even back then we prefered the word "open". It currently rates 4.8 stars from 25 reviews on Amazon, so people liked it. Then we wrote 𝘖𝘱𝘦𝘯 𝘔𝘢𝘯𝘢𝘨𝘦𝘮𝘦𝘯𝘵. 𝘛𝘩𝘦 𝘢𝘨𝘪𝘭𝘦 𝘔𝘢𝘯𝘢𝘨𝘦𝘳 was about how. 𝘖𝘱𝘦𝘯 𝘔𝘢𝘯𝘢𝘨𝘦𝘮𝘦𝘯𝘵 was about why: a more passionate ideological book, as well as updating some of our ideas, and ditching "agile" for "open", a much better word. It rates five stars from 9 reviews (if you've read it, we would really appreciate more reviews please). We regard it as our flagship book right now. Then we realised we really have to write 𝘛𝘩𝘦 𝘖𝘱𝘦𝘯 𝘌𝘹𝘦𝘤𝘶𝘵𝘪𝘷𝘦. It has become apparent from our work that the personal journey of the top bosses, the executives, is pivotal to a genuine transformation of an organisation. If they don't change their individual personal behaviours, the organisation won't change how it manages and works. So that's where we are now. In the future, I can see that our next book in this cycle (we do write other books as well) will be 𝘖𝘱𝘦𝘯 𝘞𝘰𝘳𝘬, the magnum opus to try to sum it all up and update it all, as we constantly learn and the global thinking advances. We are already laying the groundwork for that book. There are a bunch of links in the comments if you are interested in learning more. What do 𝐲𝐨𝐮 think we should say to executives about their personal journey to better ways?

𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 𝐭𝐡𝐞 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐁𝐞𝐭𝐰𝐞𝐞𝐧 𝐃𝐚𝐭𝐚, 𝐂𝐨𝐧𝐭𝐞𝐧𝐭, 𝐚𝐧𝐝 𝐈𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧 A startup launched a project management tool, creating all the usual content—demos, tutorials, and feature lists. Soon, they were swamped with feedback, but it was mostly negative. Another startup released a similar tool but received almost no feedback at all. Who’s actually doing better? The one with lots of negative feedback or the one with none? Here's where understanding the difference between data, content, and information is crucial. The startup with negative feedback has valuable data on what users don’t like, providing clear direction for improvement. The startup with no feedback faces a different problem—lack of user engagement. The silence itself is important information indicating possible disinterest or misalignment with user needs. Information isn’t a new concept from the information age; it’s as old as language itself. Information isn’t objective; it’s what people interpret from the data they see. 𝐄𝐱𝐚𝐦𝐩𝐥𝐞: Imagine you're at a concert. The seats in one section are empty, while another section is packed. You might assume the full section has a better view or better acoustics. Alternatively, you could interpret that the empty section has higher-priced tickets or obstructed views. These assumptions are the information you’ve interpreted from the seating arrangement. When we create products or content, we’re arranging data in a way we hope will communicate specific information. However, the users ultimately create the information through their interpretations. 𝐊𝐞𝐲 𝐈𝐧𝐬𝐢𝐠𝐡𝐭: Understanding and analyzing the absence of feedback can be as powerful as interpreting negative feedback. Both give critical insights into user behavior and preferences, guiding us toward better product development and user engagement.

"I’m only referring to projects with a clear scope where stakeholders have rightful expectations for a fixed budget and deadline." In front of everyday business challenges and market dynamics, organizations can make a mistake trying to solve all types of them by using the same practice or method. Some business problems are simply complicated, others somehow complex. Using a practice that works very well on one type of problems (let's say on deterministic and time constrained problems) doesn't mean that practice will work well on business situations in which it is better to build iterations according to market feedback. The same in reverse way. Something that works well on iterative solutions may not work on deterministic and time constrained situations. Organizations must be flexible to adopt either a product approach or a project approach for building digital solutions, but not be rigid on one type only. That can be the ruin for some type of business problem in which the method or practice is not the best option, not only for building but in realizing business benefits. This flexibility must be declared as a business strategy. https://lnkd.in/eZBVNbaN

When I was told I would be overseeing a project at my current company to replace the technology in our 4,000+ trucks on the road, I was thrilled. Not everyone would be, but complex and big projects is where I shine. But then, when I told the company that I wasn't involving Operations in the implementation, I got a lot of strange looks and questions. Don't misunderstand me - I didn't say "no one from Operations would be involved in the project.". I simply said I'm not involving ALL of Operations. They didn't understand how that would work, but eventually, they agreed to let me proceed and the project began. As a project manager, why would one do this? First, pen to paper decisions for enterprise-level software changes are typically made at the top. Therefore, this group doesn't have any initial "buy-in" on the implementation, they've just been "voluntold" (one of my favorite mashup words 🙂 ). When given the chance, they will always try to make the new system look like the old system because they don't understand the benefit or difference of the new technology - yet. Second, Operations will also require EVERYTHING to be in place before they will sign off on go-live, and that is simply not required. This is especially true if it's an older system which, in our case, had been in place and developed over 20+ years time. There was just no way to move all of that to the new tech in the timeline given. So, the next question is... HOW does one do this? Understanding MVP (minimum viable product) is key! The requirements of your people and the processes you want to maintain or reform should be influential factors - it's NOT about the technology. We operated in the development space alone for 4 full months before ever involving anyone else. Decide on the basic functionality needed day 1, get that place, and start the pilot. Then, following Agile principles, fix the issues that are found, and then keep developing and adding new features as you're continuing to roll out on the front end at the same time, making sure that key features for key groups are ready when they need them. And the proof was in the outcome - we implemented this tech in 4,300 trucks in 11 months, beating our required timeline. As a project manager, don't be afraid to fully own your areas and ask for what you think is best, even if people find it risky. It only takes one big project like this with a good outcome to prove the process works.

𝐓𝐡𝐞 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐁𝐞𝐭𝐰𝐞𝐞𝐧 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 𝐌𝐢𝐧𝐝𝐬𝐞𝐭𝐬 𝐟𝐨𝐫 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐏𝐫𝐨𝐣𝐞𝐜𝐭𝐬 𝐚𝐧𝐝 𝐏𝐫𝐨𝐝𝐮𝐜𝐭 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 There is a big difference in mindset and development approach when it comes to service project development versus product development. What are the key differences? Why do they exist? Is it possible to work on both types of development with a single mindset and approach? Here are a few differences I've noticed while working on both types of projects: 𝐒𝐮𝐬𝐭𝐚𝐢𝐧𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐯𝐬. 𝐒𝐩𝐞𝐜𝐢𝐟𝐢𝐜𝐢𝐭𝐲:  Product development focuses on sustainability, considering future requirements, while service projects prioritize specific client requirements. 𝐃𝐞𝐚𝐝𝐥𝐢𝐧𝐞𝐬: In product development, there's more bandwidth for analysis, design, and implementation. We can deliver new feature as per timeline decided internally. In service projects, we work according to the client's priorities and deadlines. 𝐍𝐞𝐰 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬: In product development new features and improvements comes through internal discussions and based on feedbacks. In service project development, change requests come directly from the client based on their business requirements. 𝐇𝐚𝐫𝐝 𝐂𝐨𝐝𝐢𝐧𝐠: In product development, hard coding or pre-assumed values are avoided, while in project development, we sometimes hard code values due to the limited scope. 𝐖𝐨𝐫𝐤 𝐇𝐨𝐮𝐫𝐬 𝐋𝐨𝐠𝐠𝐢𝐧𝐠: In product development, work logging may be skipped (though not recommended), while in project development, it's mandatory to log work for client billing. 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐀𝐥𝐥𝐨𝐜𝐚𝐭𝐢𝐨𝐧: In product development, any suitable/available resource can be allocated, while in client projects, resource allocation requires confirmation and approval. What are your thoughts? Have you experienced similar differences? Can we effectively manage both types of development with a single approach? #ProductDevelopment #ProjectManagement #DevelopmentMindset

How do you measure if a company transformation is leading its decision making capabilities in a better direction than it was in before? was a company's ability to change a decisions direction quickly known before the transformation even started? measuring how fast widgets are made is useful in some context but not all, in knowledge work and with startups trying to figuring out what customers need, decision making velocity based on new information is what needs to be measured, how fast are we learning the feedback loop from when a decision was made compared to it's impact or influence on some end point of perceived value exchange with an end user or customer. who is measuring the transformation process to see if it's any better than a system was before it's transformation? did they establish a baseline that had a clear idea on how long a companies decision feedback loops were taking before starting to implement a new way to measure what 'success' looks like? Who watches (or measures) the watcher?

After 9 Months of planning, research and development, DocuCRED.Ai is Live! I’m now proud to introduce DocuCRED.Ai—a tool designed to help organisations across healthcare, finance, education, and more compare their documentation against compliance standards, guidelines, and specific requirements. DocuCRED.Ai streamlines the compliance process, saving time and increasing accuracy by analysing guideline documents, segmenting content into focused sections for improved alignment, and generating detailed reports that clearly indicate where documents comply (or fall short). What DocuCRED.Ai Can Do (and what I’ve been working tirelessly to bring to life): 1. Identify Relevant Guidelines or Standards; DocuCRED.Ai analyses guideline documents, identifying specific requirements and subcategories. Imagine a safety standard with multiple safety measures—DocuCRED.Ai breaks down each measure, recognising sub-guidelines for structured, clear analysis. 2. Break Down Information for Quality Output; Next, DocuCRED.Ai focuses on the content document, breaking it down into smaller sections. This step allows the generative model to give more precise, quality outputs that align accurately with the guidelines. 3. Generate a Comprehensive Compliance Report; Finally, DocuCRED.Ai compares the guidelines and content documents, highlighting aligned sections and areas for improvement. It even offers a report showing covered vs. uncovered guidelines, for anyone focused on achieving full compliance. Throughout this journey, I wore many hats. I started as a Business Analyst, defining requirements and solving complex flows. But as development progressed, I took on the Product Manager role, leading agile sprints, aligning the team, and keeping a clear vision for our end goal. This hands-on experience taught me more about Agile, Scrum, and real-world project management than any course could. DocuCRED.Ai is more than a project—it’s my first venture into generative AI with a real-world use case. And it’s just the beginning. The potential for generative AI to address unexplored challenges excites me, and I can’t wait to dive into new applications. If you’re curious, try DocuCRED.Ai for free (supports information as text in PDFs only, for now). Your feedback is invaluable—feel free to share your thoughts, good or bad, in my LinkedIn DMs.

Related: "HR-Related Experiments, Deciphered" (https://lnkd.in/eWUNVrRS) Many people are familiar with the complete picture of #largescalescrum (LeSS) that describes LeSS Principles, Rules, Guides and Experiments, graphically illustrated as “LeSS onion”, because its concentric circles (https://lnkd.in/ermAXC78). In sum, there are ten LeSS Principles, based on which, there are twenty eight LeSS Rules that have been defined. LeSS Guides are discussed in the latest LeSS book: Large-Scale Scrum: More with LeSS (2015) – and their purpose is to provide guidance for LeSS rules’ implementation. Lastly, there are 600+ LeSS Experiments, covered in the earlier LeSS book: Scaling Lean & Agile Development (2009) – and their purpose is to provide some Try/Avoid recommendations during LeSS implementations. LeSS evolution journey is more than 20 years old. During this time, a lot of learning has been collected and documented, and there are many LeSS adoption case studies that have been published. After doing another thorough review of the above references, I have identified for myself a few super-critical organizational enablers that seem to create a very strong dependency for success of a LeSS adoption. It does not mean that other principles, rules, guidelines and experiments are not important. It just means that what is listed below, has always been the main guarantor of LeSS adoption success, at least, in my experience. #hr #budgeting #finance #morewithless Bastiaan van Hamersveld Frans Meuwissen