home.social

Search

8 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

    📦 How often should you release? For a long time the answer was: only when we had a large batch of features to sell. In the 1990s, when our software was shipped on floppy disks or CD-ROMs, this made some sense.

    We did what we called big bang releases, where we waited until the end of the quarter or the end of the year to release our software. We would spend months working on features, doing light testing along the way, then cram much of the real testing and other efforts into the last few weeks. This led to a lot of stress and overtime. In addition, products always went out the door with a lot of bugs. The question was not how many bugs, but how severe they were.

    Every release is a batch of changes. The bigger the batch, the worse each of these problems gets:
    - Testing cost grows faster than the scope of the release, because we need to test not just the new features, but also their interactions.
    - The more changes there are, the harder it is to find where the defects are so we can fix them.
    - The longer it has been since we last worked on a piece of code, the harder it is to understand, and therefore fix, a defect.

    Here's a rule of thumb the agile community has spent years learning: if something hurts or is hard to do, do it more often. If it's hard to release, then release more often.

    How often does your team release today?

    agilepainrelief.com/glossary/r

    #agile
  3. Mark Levison @mlevison

    😐 Generative AI is helping people be more productive (sometimes). So, yes, it's (sometimes) helping people be more productive and there are (some) places where it does make (some) things get done faster.

    But forget about speed for a minute, which is what all the focus seems to be on, and let's put some thought into the consequences of all this so-called productivity. The human cost.

    Research reported in the Harvard Business Review noticed that, people who used GenAI for tasks like writing emails, social media posts, and brainstorming were more productive. But this productivity came at a cost. As GenAI takes over the demanding tasks, people report lower intrinsic motivation and increased boredom. This leads to disengagement and dissatisfaction with work and, if unchecked, burnout.

    Using the ARC Motivational model, we know that we need to feel competence in doing our work. The use of GenAI is taking away from that sense of effectiveness and confidence, leaving people to ask: Why am I here?

    (Caveat: the research in this area is new and will evolve.)

    Have you noticed this? Have you talked about it with your team?

    agilepainrelief.com/blog/the-h

    #aiinsoftwaredevelopment
  4. Mark Levison @mlevison

    The irony is that I bought this book in the year after I graduated because I was fascinated by RISC and architecture. I was using SPARC and MIPs chips at the time.

  5. Mark Levison @mlevison

    I just tried to save my daughter $120+ for next term’s computer architecture course. She’s not buying it. What’s changed? The book is only 36yrs old. Only six editions since. RISC is still RISC.

  6. 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
  7. 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
  8. 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.