Posted on

Agile Adoption Patterns: 6 Common Breaking Points and How To Fix Them

A few years ago, when companies started embracing Agile, they would bring in a consultancy firm to help come up with a strategy for the shift. They would hire some Scrum Masters, provide basic training to their teams, and proudly declare: “We are Agile now.”

But that statement couldn’t be further from the truth. More than a methodology, Agile is a philosophy, and adopting it means that everyone involved should get on board with a complete and profound transformation. A transformation that, oftentimes, fails.

Posted on

Antipattern of the Month: Too Busy

Often, the very people whose involvement is most critical to an initiative are those who are least "available." Senior managers, for example, can have a deep level of domain experience which they have built up over years, and they can exert authority over important decisions. Enterprise architects and Product Owners, in particular, may have accumulated responsibilities over sweeping areas of organizational concern. Such people are notoriously time-poor, and can be unable or unwilling to focus on a single product or team. This means that they often fail to make the appropriate commitment to an Agile role, and do not demonstrate the quality of involvement expected of them.

One symptom is that they might see themselves as being "too busy" to fulfill the role and its responsibilities. A Product Owner, for example, may be "too busy" to attend Product Backlog refinement sessions, or perhaps even Sprint Planning, Sprint Reviews, and Sprint Retrospectives. They may allege that they "trust" the Development Team to make an appropriate delivery without their participation. This is unsatisfactory, as it means abdicating their collaborative responsibilities, and the inspection and adaptation of progress are compromised.

Posted on

Pattern of the Month: Peer

In Agile practice, the completion of work is seen as being the responsibility of the team. Although individual team members may action a particular backlog item in whole or in part, it will be the team which owns it. This principle is ingrained to the point that — in the Scrum framework — it shapes the way in which roles are defined. Hence, you will find a role in Scrum called "Development Team," but not one filled by an individual "Developer."

Each Agile team member is considered to be a peer to the others. For this to hold true, there must be a shared sense of commitment to team goals, and an ability for those people to work together. In an efficient team, the various members will "go to where the work is," rather than waiting for work to come to them. This implies that a degree of cross-skilling and cross-training ought to be in evidence, and which is sufficient to overcome the waste that would otherwise be accrued through bottlenecks and skill-silos. Efficient peers will collaborate with regard to who performs certain tasks at certain times. Any scheduling that they agree amongst themselves will thus become orthogonal to the flow of work.

Posted on

Antipattern of the Month: Micromanagement

Micromanagement commonly occurs when an old organization tries to establish Agile practice. Agility requires the empowerment of largely autonomous teams, and some managers can find it hard to let go of the authority they have traditionally held. They will involve themselves in the details of the work and how it is conducted, rather than letting an Agile team get on with the job. There is a desire, for one reason or another, to retain control.

Micromanagement can result in the inability of a team to inspect and adapt product and process. The manager takes action instead. Waste is then incurred since team focus and collaborative potential cannot be fully brought to bear. A micromanager can often become a bottleneck. Sometimes a micromanager will "dip in and out" of work, leading to inconsistencies in team approach and productivity.

Posted on

Pattern of the Month: Timebox

A timebox is a period of fixed maximum duration in which team activities may be carried out. In Scrum, there are five timeboxed events: Sprint Planning, the Daily Scrum, the Sprint Review, the Sprint Retrospective, and the Sprint itself which is a timebox containing all other events. In Agile practice, the delivery of value should not be put in unnecessary delay. Brisk timeboxing can help, since events are often subject to the law of diminishing returns.

For example, it’s unlikely that spending two working days on Sprint Planning will be twice as effective as one working day. It is believed that the purposes of Sprint Planning may be reasonably accomplished in 8 hours or less. Any longer is not likely to improve the quality of the activity, and it would be better to commence work and learn from actual experience, inspecting and adapting the Sprint Backlog accordingly.