Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by William Krebs
Making the Most of Team Differences
| Some teams crash when there are differing personalities -- especially those teams that transition to agile methods. The adaptive mindset is different than what many people are used to, and different than what some personalities may prefer by nature. Team members come in with different skills, work styles and views of the world. When teams don't understand this, fights can erupt over simple issues. But when these differences are recognized, the team can leverage the diverse perspectives for better results. People often view situations through a combination of four basic personalities, according to David Keirsey's temperament sorter: Artisans prefer to use their skills to adapt to the situation at hand. These are all legitimate approaches to situations. But strife may occur in teams that don't understand people are born with different inclinations. What happens, for example, when someone asks a guardian to change a plan? What happens when one asks an artisan to plan too far ahead? Can the facts-based view of the rational inadvertently miss something or trigger some discord? Can an idealist's sensitivity miss a key fact? All these scenarios are valid, as change, schedule, facts and feelings play out in a business situation. Everyone must realize their teammates may start at a different position when working problems together. Rather than being a source of friction, though, these different positions can be an asset, bringing all the options to light. |
Kanban Creates Buzz Among Agile Crowd
Categories:
Agile
Categories: Agile
| Like its predecessors, the Agile 2010 conference will go down as a key event in agile project management. This year, I and 1,400 other attendees learned about everything from innovation to Kanban. The conference was held in Orlando, Florida, USA from 9-13 August. Several sessions were particularly notable. Kenny Rubin, Laurie Williams and Mike Cohn shared the Comparative Agility assessment. Using data from 1,600 teams, users can see how their team's agility compares with others. Ron Jeffries and Chet Hendrickson, famous as original extreme programmer proponents, made a case for a less dogmatic approach to methodologies and suggested using the hybrid best suited to your needs and circumstance. For me, the most striking part of the conference was the large interest in Kanban, a project management methodology from Japan that emphasizes cycle time instead of utilization of resources. There were seven presentations on it -- all standing room only and overflowing into the halls. In Kanban, work is purposefully limited so teams are forced to finish items to high quality before moving on. This can yield the same or more output, but reduces the risk that too many half-done items in progress won't get done. Work is tracked on a board with a few simple columns, such as waiting, working and testing done. Each item, or "ticket," is moved from column to column to reflect its state. Have you ever used Kanban methodology? |
Lessons Learned About Lessons Learned
Categories:
Agile
Categories: Agile
| Many teams benefit from reflecting on their process after they complete their project. Any errors in the process, however, have already had their impact. Agile software development includes ways we can improve our lessons learned - not just for software, but for any project. These lessons from agile projects may help your projects too. Lesson 1: Perform lessons learned sessions during the project. This lets you benefit from your ideas in time to make a difference. Lesson 2: Smaller, more frequent meetings flow better. There aren't as many items to discuss and it becomes easier to focus on observations. Lesson 3: Don't whine, refine. Avoid spending a lot of time digging into why problems happened. There won't be enough time to plan for positive changes. Lesson 4: Follow the cadence of change. Sometimes we forget the team will be busy with work. Try limiting the changes to two actions. But nail those actions! And don't start new process improvements until the other ideas have been deployed. Lesson 5: Changes should be by the team, for the team. Lessons learned should not be viewed as a scorecard -- it will make all the metrics climb to suspiciously good levels. Management should have visibility into the process used and some lessons learned, and anonymous examples of triggers that led to their discovery. But the retrospective itself has to be a judgment-free zone where all problems can be discussed. If you're using scrum or another agile method, this might sound familiar. Lessons learned or retrospectives are built into your iteration cycle. How do these tips fit with your project's life cycle model? |
Power Scrum: Secrets to a Good Meeting
Categories:
Agile
Categories: Agile
| This is a guest post from Bill Krebs, owner of Agile Dimensions LLC The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way. The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more. So what goes wrong? And how can you get back the benefits? Here are some ideas. Focus There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates? Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear. Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem. The scrum meeting is not about status. It's about completion. Control the Number of Participants Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen. If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together. Go Offline Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?) In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting." Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement. Remember My Three A's: Awareness: The meeting is about knowing what your teammates are up to. Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day. Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion. Those tips will cut the fluff--and speed up your work! |