Acklen Avenue’s Post

As I wrote this user story(see attached image), it got me thinking about why Documentation is non-negotiable for cross-functional teams. 👇 1.) Provides easy and quick reference for business, product, and feature requirements during times of uncertainty. 2.) Facilitates smooth onboarding of new team members. Especially for developers, who usually settle in quickly with good documentation. 3.) Helps avoid unnecessary virtual meetings.😅 In many cases, alignment meetings become quicker when a reference document exists. Consequently, engineers can ship more code because they have more time for actual work. All things being equal, more code should translate into revenue for the business.😁 4.) Using tools like JIRA, you can easily track product decisions and tasks that were documented. Francis Val-Neboh the CEO of Dobande Technologies Inc. always say “Documentation will save your life”. - Its a valuabe advise for every cross functional team. Cheers!🥂 #productdevelooment #teams #documentation #software #productivity

This presentation address one principle I'm pursuing in all code that I wrote / change: make the right thing the easy thing (and the converse one, making the wrong thing hard to accomplish) but this quote from Jason Lengstorf is really insightful on the role of accumulated experiences, including failures, to provide learning and evolution. "I don't want anybody to see me on my team as infallible and as a lead developer, the worst thing you can be is someone who appears infallible. If your team doesn't feel like you make mistakes, that puts you on a weird pedestal. [...] You should be failing constantly in from of your team, showing how you learn from your mistakes because that is how you got to where you are." And besides those two points, the central thesis of Jason is to create process that support the team to be productive (rather than a process suited to a small group or to a individual, usually the one who wrote the process). #softwareengineering #softwaredevelopment #processimprovement #developerexperience https://lnkd.in/d5WFjpPf

Gathering context around the implementation before jumping into the code is crucial. It saves your: • Time • Effort • Credibility If you jump into implementation without fully understanding the context of what you are implementing, you risk jeopardizing your credibility within the team. Implementing things prematurely may lead to redoing the work. Therefore, be cautious: • Ask questions. • Read documentation and discussions. • Share your thoughts before beginning the implementation. #softwareengineering #softwaredevelopment

#LeSS continues to evolve without the need of versioning (i.e. 3.0 or 6.0). You start using #LeSS as the kickstarter engine of your product organization, which then you tweak & evolve yourself, fitting -your- organization needs. Not the pre descriptive thoughts of a group of people who think they know -your- organization 🤦♂️ #lessworks

Does it seem to take a long time for your company to get a feature out the door? Have you done a “Five Whys” on the problem? Does one of the root causes seem to be the number of dependencies between teams, or “steps” that it takes to get something out the door? Chances are that it has something to do with the way your teams are structured.

Story Points & overthinking ⁃ Development is 3 SP and testing is 2 SP, does it mean the work is 5 SP? ⁃ Our velocity is 30 SP, why do we have spillovers when we had (8 + 5 + 8 + 3 + 5) SP? Is there something wrong with our estimation? No, it doesn't work like this. And SP is not a replacement of hours. The only purpose of SP is to make planning easier and faster by comparing work items. Instead of estimating each part of the work and building a precise plan of who does what and when, you can estimate amount of work compared to what you already did. Basically, 5 means it is more work than 3, 8 means it is more work than 5, as simple as that. When it comes to planning, SP is not enough. You still need to facilitate commitment and you still need inspection to manage the work, it is not enough to select items with sum of SP close to team's velocity.

🔧 Elevate Your Knowledge: Explore OpenBOM Change Management this Weekend! 🔧 Weekends are perfect for expanding your skill set! Dive into the world of OpenBOM Change Management with our insightful infographic. Learn how to streamline processes, enhance collaboration, and drive efficiency in product development. Ready to discover the power of effective change management? Let's make this weekend productive together. Let me know if you have questions and I'd be happy to give you more information about what you can do using OpenBOM💡 #OpenBOM #ChangeManagement #ProductDevelopment #Infographic

Recently I came across this concept of ‘The Eisenhower Matrix’ . It is a clever way to manage your tasks by sorting them into four boxes based on urgency and importance. Imagine a grid with two axes: one for urgency and one for importance.  It's a practical way to make decisions about where to direct your efforts for maximum impact!🙌 Here's a concise breakdown of the four boxes in the Eisenhower Matrix: 1. Top-Left (Urgent and Important): Tasks requiring immediate attention.              2. Bottom-Left (Urgent but Not Important): Tasks that are urgent but may not contribute significantly to long-term goals.         3. Top-Right (Important but Not Urgent): Crucial tasks for long-term success but not requiring immediate action. 4. Bottom-Right (Not Urgent and Not Important): Tasks neither urgent nor important. Consider reassessing their inclusion on your to-do list. Take 10-minutes of your time, create your own Eisenhower Matrix, simply list your tasks, evaluate their urgency and importance, and strategically place them into the corresponding quadrants. This quick exercise can be a game-changer, providing a visual roadmap for efficient task management and helping you prioritize with purpose💫 #eisenhowermatrix  #productivity #timemanagement #prioritization #productivityhacks 

New video out today! In this one I discuss a simple model to help you prioritize your work and make sure you're delivering what your customers want. https://lnkd.in/dqJWsTeE

Reflecting on the evolving role of documentation during the development process. In my view, there seems to be two schools of thought: document everything, or "what documentation". There is a fine line that developers and product teams need to walk when being asked to document a process, a feature, or a workflow. Documentation is necessary when passing along key information critical to becoming a subject matter expert, but no one wants to ready a novel or attempt to navigate through 200 Confluence documents. Finding that balance within a team or organization is key to being able to adequately communicate and not creating so much noise that nothing can be found when searching for clarity. There is no perfect solution, but each team, so long as they have clear and open communication, can find a path forward. What are your thoughts? Let's share ideas and insights! 💭💻 #ThoughtLeadership #TechInsights #SoftwareEngineering