Best Agile Articles of 2019

Take a break and read 'em All

By

StandUps offer the most benefit when they sustain communication about the state of the work. They work best when team members keep their responses succinct. Strive for brief (30-60 seconds per team member), frequent, and to the point. It helps when team members know the questions ahead of time and come prepared. I shared a suggestion I learned from James Shore; each person can write their answer on an index card to bring to the meeting.

By

This article came about by talking to various Agile people; Scrum Masters, Product Owners and Agile Coaches in a number of organizations, both public and private and of course my own colleagues. What you will find below are the challenges they mentioned most, coupled with some of my own thoughts on the subject.

By

One of the pernicious problems in large-scale software development is cross-team coordination. Most large-scale Agile methods focus on product and portfolio coordination, but there’s a harder problem out there: coordinating the engineering work.
Poor engineering coordination leads to major problems: bugs, delays, production outages. Cross-team inefficiencies creep in, leading to Ron Jeffries’ description: “a hundred-person project is a ten-person project, with overhead.” One of my large-scale clients had teams that were taking three months to deliver five days of work—all due to cross-team coordination challenges.

By

The aircraft carrier displaced 94,000 tons of water as it separated the Atlantic Ocean in two halves, going far in excess of the 30 knots where the top speed becomes classified information. We went as fast as we could, and then turned as sharp as we could, to see if the ship would break. A torrent of water roared over the forward, top-side of our steel coffin. Some of my fellow sailors turned a greenish pale, and the wax on the deck began to strip in the places where they vomited. We all held on to some fixture that was welded or bolted firmly in place.

By

Scrum is a simple, yet sufficient framework for complex product delivery. It helps organizations thrive on complexity. Scrum provides the minimal boundaries for teams to self-organize and solve complex problems with an empirical approach.
However, we’ve noticed that although many organizations use Scrum, the majority struggle to grasp both the purpose of Scrum as well as its benefits. Instead of increasing their organizational agility and delivering value to customers sooner, they achieve the opposite. We’ve come to call this Zombie Scrum; something that looks like Scrum from a distance, but you quickly notice that things are amiss when you move closer. There is no beating heart of valuable and working software, customers are not involved, and there is no drive to improve nor room for self-organization.

By

Many organizations implement measurements that unwittingly encourage or elicit poor practices and behaviors. As they become more Agile, the pillars of Empiricism allow for increased transparency which can easily be abused. This transparency can provide a wealth of information on how scrum teams are performing and allows for identification of improvement areas. Metrics that are put into place without consideration of the desired outcome result in a change in behavior and practice which may not lead to Agility. Metrics that elicit and encourage appropriate practices and values such as: Commitment, Courage, Focus, Openness and Respect will propel teams to higher performing states.

By

In order to build trust, we need to show vulnerability, we need to have trying experiences together, and maybe even get into trouble together (that is what my dad says about why my brother is still close to his high school friends). Vulnerability, however is hard to produce in a work environment without a real moment that causes it. We are taught that emotions are not supposed to be in the workplace, but let’s face it, we’re emotional people. We work for huge parts of our day and sometimes see our co-workers more than our families. So doesn’t that mean we should have plenty of opportunities to build trust? Most of the time new teams, or even teams that have been together for a long time, that trust can be really hard to build or regain if lost.

By

This post is the second in a series related to product management and product teams. Like the previous post, this one is partly influenced by Marty Cagan’s article on “Product Teams” vs “Feature Teams”. Marty seems to see the role of Product Manager different than we do, but the difference is probably more about the team than about the Product Manager. That said, this post is especially influenced by the frequent recurring question, “Should a Product Manager be on the Team?”

4 / 71234567