Responding to change shouldn’t mean teams face continuous change!

The fourth and final statement in the Manifesto for Agile Software Development states that we should value responding to change over following a plan.

The purpose behind this preference is to ensure that while a plan might be created to guide team efforts, there should be openness from the team, product owner and key stakeholders to encourage and incorporate changes which will deliver greater business value for our customers.

But as with everything, moderation is key as on more than one occasion I have seen team members experiencing virtual whiplash from a high frequency of significant requirement changes.

Teams will become more change resilient as they mature but there is a natural limit to the volume of changes that any team can absorb.

Think of Morpheus fighting Agent Smith in The Matrix. Morpheus is an accomplished martial artist and has full confidence in his abilities to hold his own, but at a particular point in their fight the frequency of Agent Smith’s punches is simply too fast for Morpheus to block.

The team remains busy completing work items but it feels like a random walk to nowhere and morale will suffer as they see that they are regularly taking one step forward and two or more steps back.

Even though the eleventh principle in the Manifesto states that the best architectures, requirements, and designs emerge from self-organizing teams, it is impossible to create a quality architecture or design which is capable of incorporating frequent, major shifts in direction. Frequent major changes will also encourage short term thinking by the team which could cause an increase in the level of technical debt.

This is why it is crucial to create genuine shared understanding and buy-in to a product or project vision upfront and then to translate that vision into a product road map or, better still, a story map. Significant changes to these artifacts should be managed through a lean but disciplined review process which might include temporarily halting the team’s efforts until the impacts of such changes can be properly assessed and incorporated.

The Greek philosopher Heraclitus might have said that “The only thing that is constant is change” but that doesn’t mean we should expect constant change!




Categories: Agile, Project Management | Tags: , | 1 Comment

Does knowledge transfer change with agile?

We have all experienced this: a key contributor announces their departure and a mad scramble ensues to transition their knowledge to the rest of the team.

But does this change when the team is using an agile lifecycle?

On the surface, it might appear that there wouldn’t be any significant differences in how it is done regardless of the nature of the work or how it is performed. After all, knowledge transfer is usually a case of a subject matter expert educating others through either a live session or through some sort of persistent record such as a wiki, a video or an audio recording.

While this is true, there are characteristics and specific practices in agile delivery which can impact knowledge transfer.

Traditional delivery usually relies on individual specialists who remain focused on their role and area of expertise. On the other hand, agile delivery encourages the development of generalizing specialists who will develop a broader set of skills and knowledge. Higher levels of collaboration are also expected in such contexts which increases the amount of exposure that individual team members have to each other’s knowledge.

While this won’t translate into full fungibility across a team, there is less likelihood of only one team member possessing critical information. This won’t happen over night. It will take many weeks of working together as well as explicit encouragement by supporting stakeholders such as functional managers for generalizing specialists to develop.

Another enabler is non-solo work – pair programming, hackathons, mob programming and model storming are all practices using this principle. While the primary purpose of these practices is not knowledge transfer but rather quality and speed, it is a valuable side benefit. Rather than having experts share knowledge in an academic manner, demonstrating how their knowledge can be applied towards completing work items is more effective.

Whereas traditional delivery tended to emphasize documentation as the medium for passing work between roles, agile approaches focus on minimal sufficiency. While a newly formed team might require more documentation to facilitate shared understanding, a long lived team might successfully deliver with much less. The challenge becomes when a new or junior team member joins as there may be insufficient reference material to enable self-learning. But this should not cause any major issues if someone on the team volunteers to pair up with the newcomer to help fill in the blanks.

While the need for shared knowledge is there in all contexts, effective agile delivery can reduce the critical of explicit knowledge transfer.





Categories: Agile, Project Management | Tags: , , | 1 Comment

How warm are your stakeholders about Information Radiators?

BrokenRadiatorInformation radiators can help stakeholders remain informed and can reduce effort spent by a team in handling requests for updates but to reap these benefits we must ensure that the information published meets their needs.

As with any type of communication, if the content published cannot be trusted due to obvious inaccuracies or a lack of currency, stakeholders will cease to consult the radiators and will demand that traditional reporting methods are re-established.

Such defects will also reduce the credibility of the team in the eyes of the stakeholders.

This is one more reason to ensure that if Kanban boards or other work visualization views are made accessible to stakeholders outside a delivery team that team members are diligent in updating them while work is being done rather than after the fact.

If an information radiator generates more questions than it answers, it will become a burden for the delivery team. Not only does this mean that legends, titles, and thresholds are clearly presented, but it also requires that any information which could be misinterpreted should be accompanied with some context so that stakeholders get the correct story.

For example, if a sprint burn down chart is being published daily and by the midpoint of the sprint it appears that very little has been completed, a stakeholder might reasonably assume that the team is going to complete significantly less than what had been agreed to during sprint planning. However, if some context is provided that the team’s delivery process includes an independent review by an external inspector who is only available one or two days per sprint, this apparent lack of progress might be perfectly acceptable.

This also means that we should review what is being published to ensure that stakeholders can perceive the forest as well as the trees.

Publishing a sprint burn down chart or Kanban board without providing a team’s Definition of Done is only part of the story. Posting a release burn up chart without indicating what is being delivered in the release will not promote shared understanding.

Finally, it’s important to educate stakeholders so they can effectively pull information from the information radiators and to set expectations that radiators are to be consulted as the first source for updates.

Poor information radiators are a constant reminder of George Bernard Shaw’s caution that “The single biggest problem in communication is the illusion that it has taken place.”



Categories: Agile, Project Management | Tags: , | Leave a comment

Blog at

%d bloggers like this: