Running agile programs (without losing your mind)


Dan Radigan Dan Radigan


This is not without its challenges. But that doesn't mean it can't be done! 




Waterfall release example | Atlassian agile coach


Let's contrast that with an agile project management style, which takes an iterative approach to development with regular feedback intervals. These iterations allow for the team to be diverted to (and productive in) another area of the project while a blocking issue is resolved.

Agile project management example | Atlassian agile coach



An even greater benefit is shared skill sets among the software team. The team's overlapping skill sets add flexibility to the work in all parts of the team's code base. This way, work and time isn't wasted if the project direction changes. (For more on that, see our article on building great agile teams.)


When a program transitions from traditional project management to agile, the team and the stakeholders must embrace two important concepts:

  • プロダクトオーナーは、開発チームの成果の価値を最適化することに集中します。開発チームは、最も重要な作業を最優先に位置付けるプロダクトオーナーを信頼します。
  • 開発チームは余裕がある場合にのみ作業を受け入れることができます。プロダクトオーナーがチームに作業を強いたり、独断的な締め切りを課すことはありません。開発チームは、新しい作業の受け入れが可能になったとき、プログラムのバックログから作業を取り出します。



roadmap outlines how a product or solution develops over time. Roadmaps are composed of initiatives, which are large areas of functionality, and include timelines that communicate when a feature will be available. As the program develops, it's accepted that the roadmap will change–sometimes subtly, sometimes broadly. The goal is to keep the roadmap focused on current market conditions and long-term goals. 


Each initiative in the roadmap breaks down into a set of requirements. Agile requirements are lightweight descriptions of required functionality, rather than the 100-page documents associated with traditional projects. They evolve over time and capitalize on the team's shared understanding of the customer and the desired product. Agile requirements remain lean while everyone on the team develops a shared understanding via ongoing conversation and collaboration. Only when implementation is about to begin are they are fleshed out with full details. 


The backlog sets the priorities for the agile program. The team includes all work items in the backlog: new features, bugs, enhancements, technical or architectural tasks, etc. The product owner prioritizes the work on the backlog for the engineering team. The development team then uses the prioritized backlog as its single source of truth for what work needs to be done. 


Agile can be implemented using various frameworks (like scrum and kanban) to deliver software. Scrum teams use sprints to guide development, and kanban teams often work without fixed work intervals. Both frameworks, however, use large delivery vehicles like epics and versions to structure development for a synchronized release cadence out to production.

Agile metrics

Agile teams thrive on metricsWork in progress (WIP) limits keep the team, and the business, focused on delivering the highest priority work. Graphs like burndown and control charts help the team predict their delivery cadence, and continuous flow diagrams help identify bottlenecks. These metrics and artifacts keep everyone focused on the big goals and boost confidence in the team's ability to deliver future work. 


アジャイルプログラムは、チームメンバー間にハイレベルの信頼がなければ機能しません。特定のプログラムと製品にとって何が適切なのかという難しい話し合いをするには、率直さが必要です。会話は一定の間隔で生じるので、アイデアと懸念は定期的に示されます。つまり、こうした会話の間に行われた意思決定を実行するためには、チームメンバーがお互いの能力 (と意欲) も信頼している必要があります。

In summary, agile development is a structured and iterative approach to making software. It gives you the ability to respond to change without going off the rails. And that's good news for any program.