home.social

Search

4 results for “mlevison”

  1. Mark Levison @[email protected]

    🛠️ A code smell is a hint that something might be wrong in your codebase. A smell isn't always a problem, rather it's a hint that a further look is warranted.

    I've built Claude Skills for finding code smells, and they're free on GitHub. When the skill detects a smell, it also gives you reasons against doing the refactoring. If you're new to code smells, the tool is also designed to help you learn and develop your own sense of taste. This means you can look at GenAI generated code and know whether or not you're looking at quality.

    github.com/mlevison/refactorin

    Building that taste is hands-on work, and it's what the Certified Scrum Developer course practises. Starting with something classically messy, we practice taking code that is an antiquated mess and bring it into a modern age, and along the way wrestle with the real challenges of dealing with legacy code, poor acceptance criteria, and questions of good design.

    Prerequisites: coding experience in one of Java, C#, JavaScript, Typescript.

    Certified Scrum Developer (CSD): November 4-6, live online, 11:30 AM to 5:00 PM Eastern.

    #Scrum #TechnicalDebt

    agilepainrelief.com/courses/ce

    #scrum #technicaldebt
  2. Mark Levison @mlevison

    🤖 Agile teams and coaching are especially hard subjects for AI tools because the subject area is so vast. In my office, I have two shelves of books related to Agile and according to DevonThink, another 20GB on my laptop. The more I learn about this subject, the more I realize most answers to questions should be "it depends" and "tell me more".

    Alaska's court system is developing an AI chatbot to assist with all the forms involved in probate. From all accounts, they're doing the hard work to make it happen. Yet an activity estimated to take 3 months has already taken 15 months and is being scaled back. I would expect that dealing with probate is easier than dealing with the complexity of Agile teams.

    Even Air Canada's chatbot, which is just a glorified FAQ, has epic-fail moments that result in a lawsuit. It told a grieving family member that they needed to pay full fare, when in fact Air Canada has bereavement fares.

    There are many effective ways to use GenAI in Agile teams, but a chatbot on a professional website to give advice is not one of them. Can you afford for your clients to get subtly wrong advice? Agile is focused on people and relationships, let's keep it that way.

    agilepainrelief.com/blog/ai-ch

    #aiinsoftwaredevelopment #agile
  3. Mark Levison @mlevison

    🗣️ A familiar story:

    "Great Retro. ... All was well until we reconvened for sprint planning when the most senior and definitely more vocal team member announced that we should not spend any time on the process improvements until we were finished our other sprint tasks."

    In theory the team has already committed to an improvement and now a senior person is saying: "We tried that before."

    Don't tell someone they're off topic or wrong. This will just force them into a corner and may get them to repeat themselves because they don't feel heard. Instead:
    - Ask: "How does this link back to what we already agreed to do?"
    - Ask: "What has changed from the last time?"
    - Parking Lot: "Can we put this in the parking lot and revisit it at the end of the meeting?"
    - Engage the group: "Who else has something to say on this?"

    After the meeting is over, I always start with a one-on-one conversation. Don't try to change the person; the goal is to understand what's going on for them. Surfacing dissent early makes an ambush like this one less likely, which is why I invite dissent when a change is first discussed and actively ask for contrarian voices.

    In the moment: ask questions instead of confronting. (Being mindful of this is my biggest weakness.)

    What do you say when someone tells you "we tried that before"?

    agilepainrelief.com/blog/diffi

    #scrum #scrummaster
  4. Mark Levison @mlevison

    🤝 Grouping individuals together doesn't make them a team. It takes more than just a label to turn a collection of people into an Effective Team.

    In 1993, Jon Katzenbach and Douglas Smith published The Wisdom of Teams, which highlighted the difference between Working Groups and Real Teams. 30 years later, it's still a good place to start:
    - Small number of people
    - Complementary skills
    - Common purpose
    - Have a specific and challenging performance goal
    - Mutual accountability
    - Common approach

    The ones I see missed the most often: A specific and challenging performance goal, and mutual accountability. Plenty of groups share a manager, a backlog and a standup without ever sharing either of those. Any time a functional department with team members who work on unrelated projects is called a team, it's probably a working group.

    When Katzenbach and Smith published their work, Scrum didn't yet exist. So their description is a good start, but too abstract for Scrum Teams.

    The blog post continues with a longer list of fifteen characteristics, more focused on Scrum (or Kanban) Teams.

    agilepainrelief.com/blog/chara

    #scrum #teamwork
Share on Mastodon

Enter the server where you have an account.