Dion Stewart

Between 1995-2010-ish it was popular in the agile community to talk about patterns and principals. 15-25 years later we see the industrialized late adopter / laggard version of agile as the norm. I wonder if the "product operating model" (a synthesis of patterns in use for ~20y, similar to how a 2010 agile pattern language represented patterns in use starting in the 80s and 90s) will follow the same trajectory based on the introduction of domain-specific pattern languages? In 2035 will be be talking about the "death of the product operating model"? History would say....yes. The funny part about Agile is that I would say the *core* ideas are perhaps even MORE in demand (or relevant) now, even among the companies that see themselves as high performing product orgs. You can argue that *some* Agile ideas have widespread adoption, but when you look at how few companies have healthy, functioning teams that follow some of the edgier and heretical parts of the agile manifesto, you might view those companies as the "top" 1-2%.

269

81 Comments

I read this amazing blog post over the weekend from Zack Urlocker & thought there were some interesting parallels to empowering decision making on QA teams. My takeaway: Pushing decisions down to the people closest to the work is one of the most powerful ways to increase ownership, accountability, and speed of execution. As QA professionals, we are intimately familiar with the products and systems we test. We understand the requirements, user flows, edge cases, and potential risks better than anyone. By empowering QA teams to make more decisions around testing strategies, prioritization, risk assessment, and quality gates, organizations can unlock several key benefits: Increased Ownership and Accountability - when given autonomy to make decisions, QA teams take greater ownership over the quality of the products they deliver. This drives a sense of accountability and responsibility to ensure thorough testing and high standards. Empowered teams are motivated to proactively identify and mitigate issues. Leveraging Expertise - QA professionals have deep domain knowledge from their hands-on experience with the product. Empowering them to make decisions allows this expertise to be fully leveraged in determining effective testing approaches tailored to the specific product needs. Faster Execution - with the ability to make decisions autonomously, QA teams can streamline testing processes, adapt quickly to changes, and provide timely feedback. This accelerates identification and resolution of issues, enabling faster delivery of high-quality products. Fostering Innovation - when given the freedom to make decisions, QA teams are empowered to get creative and innovative with their testing methodologies. They can experiment with new tools and techniques to continuously improve quality processes. Of course, empowering QA teams requires a foundation of trust from leadership and an investment in training to build decision-making capabilities. But the potential benefits of increased quality, efficiency, and innovation make it well worth the effort. Pushing decisions down cultivates an environment of trust and accountability that unlocks incredible potential. Let's embrace this mindset and empower our QA teams to make more decisions - the quality of our products will be better for it. #QualityAssurance #QATeams #EmployeeEmpowerment #AutonomyAtWork #DecisionMaking

14

2 Comments

What do you do, if you want to hire an Senior C Developer? Do you include a technical test, a trial working day or other IT specialists in the process to ensure they fit the role and skills are at the level needed? And what do you do when hiring a leader? This is a critical decision that can significantly impact your organization's success. How do we ensure our new leader can inspire, guide and elevate their team? Here's are 5 ideas on how to spot the signs early and make informed decisions: ❓Ask behavioural questions: Asking candidates how they have handled situations in the past, might be a good predictor of future behavior, here are some examples: o  “How have you supported the growth and development of your team members in the past?" or o  "Tell me about a difficult decision you made in your previous role. What were your thoughts and your feelings in this situation? What was the outcome? What would you do different the next time?"   🎭 Do a role-Play exercise: Candidates can talk extensively about their experiences but observing their behavior in real-life scenarios is invaluable! Role-playing exercises, such as handling a conflict with an employee, can provide insights into their practical leadership skills. Check on consistency in their answers to the behavioural questions and their behavior in this situation.   💎 Explore their values: Use values cards to let candidates select their top five values. This exercise can speak volumes about their character and alignment with your company’s values. Ask them to sort these values from most to least important, and discuss how they live these values in their leadership role. You might also want to inquire about situations where they found it challenging to uphold their values. This gives insights into their self-awareness.   💭 Challenge your own bias: It's easy to let personal biases influence our judgment, but doing so can lead to poor hiring decisions. Therefore, familiarize yourself with different sorts of bias beforehand, e.g. affinity bias (when we favor someone because they are similar to us or share common interests), confirmation bias (when we seek out information that confirms our preconceptions while ignoring contrary evidence), and halo effect (when one positive trait influences our overall perception of a candidate) to name just three!   👥  Involve the right people in the process: Engage the team and stakeholders who will be working closely with the new leader. Clearly define who holds decision-making power or veto rights. Listen to the feedback from those involved and thus reduce bias and gain a 360 degree view.   Hiring the right leader is not just about filling a position - it's about investing in the future success and well-being of your team and organization. So, the next time you're hiring for a leadership position, reflect: Are you looking BEYOND the resume to truly understand the person who will lead your team?   #LeadershipRecruitment #CompanyCulture #EQLead

16

1 Comment

Learning about, becoming aware of, TDD is easy (30 seconds or less). Building proficiency in it is/can be complicated. Gaining fluency, well that takes time and actually using it. One question that I've been thinking about lately, with TDD, is inspired by a talk I watched by Llewellyn Falco where he mentioned that TDD is challenging to learning because it incorporates about 18 different skills . Trying to get more proficient at 18 different skills at one time is most certainly a challenge. I've been doing different breakdowns of the different skills that TDD incorporates to better develop practices that target those individual skills hoping that will boost TDD proficiency. What individual skills do you think make up TDD? I bring up three different sub-topics that I can talk about more if folks want (or I can post about them separately too). 1. Awareness -> Proficiency -> Mastery/Fluency and skill acquisition 2. Benefits of fluency/mastery over just being proficient 3. Optimizing becoming more proficient with a skill

24

8 Comments

Have you noticed that LeSS has removed "FRAMEWORK" from the main page? The LeSS Company describes LeSS now as: "an organizational system for product development aimed at maximizing an organization’s adaptiveness." - see https://lnkd.in/erAAUr-5 Leaving the market of scaling frameworks is perhaps the right move for wider adoption.

231

21 Comments

I've scheduled an online instance of my "Building and Using Shared Libraries" course. Topics include library versioning, the operation of the dynamic linker, dynamically loaded libraries, controlling symbol visibility, and symbol versioning. The course is scheduled as five half days on 7-12 October and in such a way that it should suit most people in Americas and Europe timezones. All going well, we even have time to look at the use of the GOT and PLT during lazy binding (see the picture). More info at https://lnkd.in/eX_JS93.

90

2 Comments

Many non-technical people involved in product development and close to the technical teams are unaware that all developers are not created equal. In addition to the obvious skills differences that occur there are different developer archetypes. You need to ensure when creating a team that you have the right mix of archetypes for the team to be successful. It’s yet another challenge when creating high-performance teams. Some companies, such as Facebook, do this formally. Many companies do it informally, and then some don’t do it at all (much to their detriment).

9

Hey LinkedIn, a gap I consistently see in the world of test automation is managers understanding how to hold automation folks accountable. Particularly in startups or non-traditional software companies, QA automation falls under the CTO/Director of Engineering and they have enough other priorities where they just tell the automation engineer to go off and do their thing. I've tried to lay out some very basic questions/checkpoints for managers to quickly touch base on: Before starting, 30 days in, 90 days in & 180 days in. The article provides a 6-month strategy to prevent automation projects from failing. It outlines key questions to ask, expectations at different stages, and common pitfalls to avoid. This guide aims to help technical leaders ensure their test automation initiatives deliver real value and don't become abandoned projects. Hope it is helpful! Check out the full article here: https://lnkd.in/gSyPAmwE #TestAutomation #QualityAssurance #TechLeadership

53

15 Comments