"What Agile replaces ontologically is plans (what we will build) with artifacts (what we built)." - Jabe Bloom

It's strange when people want specific outcomes to happen and think they have to install a new process to achieve them. I see it as a bit of not understanding complex systems mixed with the planning fallacy. It also does lasting damage to the organic, social aspects of work.

"Peer-wise conversations are the most important part of transformations." - Jabe Bloom

The teams I've worked with where working cross-functionally was the most natural has been when they were about nine people big. It could be encouraged in bigger teams, but I've always seen smaller Product and Development "groups" form within the team and in their language.

I'm constantly impressed at the serious effort fighting game players make in improving. They invest their time into training, studying, practicing their games and reviewing their lost matches. They also frequently read to learn about developing a competitive and growth mindset.

"A Wardley map is working when we are creating more interesting questions." - Jabe Bloom

Some fake Kanban: People tell you what your process is and how to work; Radical change is pushed onto teams; Management behaviour doesn't change; Trust is replaced by more planning, reviews and status updates.

Successful Agile teams require more than just the things you can see or touch: Job titles, cross-functional team members, a kanban board or a backlog. The elements I often see missing are the intangibles like direction, accountability, the ability to learn, and personal growth.

The shift to remote has meant that so many more training options have become accessible to me than they have been in the past. In the last two years, I've been able to attend many classes that would have required a lot more capital to attend.

When teams perform poorly, focusing too much on processes as solutions ignores the complicated or complex problems they face. "What processes should we introduce or reinforce?" is too linear and sounds a lot like scientific management. More processes can make the problems worse.

When Agile teams get too big, and their scope expands, work has a habit of becoming much more incremental and a lot less iterative because of planning and deadline pressure. When teams stop working iteratively, batch size and complexity increase, and flow slows down.

Yesterday, people discussed the benefits of virtual presence apps and how they bring back elements of working in a physical office. It feels like people are coming up with ideas that try to preserve old metaphors while the world shifts into a new era (Skeuomorphism?).

Malcolm boosted

⚠️ IMPORTANT: Users of Element Desktop/Web/Android, FluffyChat & Nheko should upgrade immediately to address a critical encryption vulnerability.

We are not aware of this being exploited in the wild yet, but as the bug is now disclosed please upgrade now. matrix.org/blog/2021/09/13/vul

The consulting catchphrase of "It depends" is a bit cliche, but in a world where people are obsessed with methodologies and frameworks, it's worth repeating: There are no absolutes. The goal is seldom to make everything look the same.

If asked, I think people would generally get that planning in software development is challenging because of variability and complexity. Unfortunately, I tend to see lots of new waste get created to try and make the planning process work.

How many successful continuous improvement efforts started with directors making decisions about what teams should be doing? How many successful Agile transformations started with managers believing that Agile was only something for their teams to deal with?

When a team is slow, and WIP is high, don't assume introducing new processes is the way to improve. You are increasing the team's WIP, adding stress, and so could make the improvement you're looking for harder to achieve.

A frustrating issue I often deal with is having someone attend a short training session, gain a superficial understanding of a topic, and embeds their poor practice in a team. In these cases, training (and a push to standardize practices) has just created another obstacle.

It frustrates me when managers solely point their fingers at teams when they don't meet performance targets. So much of a team's performance comes from elements outside the team: How they were formed, their structure, their interactions with other teams, their constraints, etc...

I get a sense of risk by how many times the statement "We've never done X before" applies. The more of those that exist that teams need to land successfully, the more risk there is. The thing is, plans typically show those things succeeding with artificial certainty.

Show older

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!