Adopting Agile


Unlike traditional execution, Agile empowers small multi-disciplinary teams work collaboratively optimizing for flexibility and creativity resulting in increased productivity and quality. As a result, it is becoming more widely adopted as the preferred operating model for early-stage startups and innovative companies. Complex tasks are confronted by being broken into manageable chunks of effort with solutions developed incrementally using rapid prototyping and tight feedback loops with each component integrated back into a coherent whole. Teams are small, multidisciplinary and largely self-governing: Senior Leaders outline where to innovate but do not dictate how. This approach is in stark contrast to traditional Waterfall methodologies which leverage long term planning, lack feedback loops and are managed by chain and command bureaucracies.

When to use Agile vs. Waterfall


Even though the term "Agile" might seem relatively new in a business context, it encompasses the ideas of several pre-existing software development methodologies which prescribed working incrementally, collaboratively with extreme autonomy and flexibility. Most often, business organizations will use Scrum for their ceremonies and artifacts coupled with a task board from Kanban for visualization and overall management. However, the key is to find the right framework(s) that maximizes efficiency and leads to the highest quality product delivered for each specific organization. Companies that have effectively implemented agile at scale tend to be resolutely transparent establishing clear guidelines on what decisions can be made within the Agile team and which require external input. Boundaries are clearly defined, and team members are empowered enough to be accountable but not so much that they could create significant risks with rogue or carte-blanche actions.

Team Structure

Product Owners guide the Delivery team to ensure deliverables and product align with business expectations. Product Owners provides a single voice for the business and are responsible for maximizing the value of the work delivered by the team. They are responsible for managing and clearly expressing the product backlog and has the authority to cancel a Sprint cycle if the goal becomes obsolete. However, cancellations consume resources and should be very uncommon. The Product Owner may or not participate in the delivery of work product, but always remain accountable for the output of the team. Strong Product Owners have an in-depth understanding of the product in question, a deep understanding of the customer, and full authority to make quick decisions. Such accelerated decision making reduces bottlenecks and increases productivity.

Scrum Masters are responsible for overseeing process improvement initiatives and communicating progress, roadblocks, and resourcing needs to business stakeholders. Great scrum masters are organizational engineers who regularly inspect outcomes, diagnose issues and work assiduously for continuous improvement. Similar to the conductor of an orchestra, they do not play an instrument but direct the team so that they play beautifully together. They should be considered a servant leader for the Scrum Team. They ensure the goals and scope are clearly understood and work in collaboration with the Product Owner to arrange the Product Backlog in a way that will maximize the value delivered by the Team. They are responsible for coaching the team in self-organization and removing impediments to the team’s progress. They work to maintain transparency across the group and facilitate all scrum events as needed. If external individuals are present at a meeting, the Scrum Master ensures they do not disrupt the meeting.

Delivery Teams work on delivering the agreed upon products and artifacts by the end of each Sprint cycles. With empowerment from the organization they manage their work and rely on cross-functional collaboration in a way that traditional program execution styles do not. Individual members may possess specialized skills and areas of focus; however, accountability belongs to the team as a whole. There are no titles and sub-teams are not recognized regardless of their domains like testing/operations/analysis. The number of items selected from the product backlog for the upcoming Sprint cycle is solely up to the Delivery Team, and they are responsible for estimating all work efforts. While the Scrum master ensures the Delivery Team has the respective meetings, it is the responsibility of the Delivery Team to conduct the meeting. The optimal team size is small enough to remain nimble and large enough to complete significant work within each Sprint cycle. Fewer than three team members decrease interaction and results in lower productivity gains. A smaller team may also encounter skills constraints. Having more than nine members requires too much coordination. Therefore the optimal team size is somewhere between 3-9 resources depending on the individuals involved and the specific work being delivered. 6 or 7 individuals is what we will recommend here. Teams of this size enable members to have all of the pertinent information needed to contribute to the work effectively. The Product Owner and Scrum Master roles should not be included in this count unless they are also expected to execute tasks from the Sprint Backlog. Agile principles favor face-to-face meetings which are easiest when team members are collocated in the same premises. There may be significant setbacks if all members work from separate locations; however, this will depend on the type of program, team dynamics, among other factors.


Scrum meetings:

Scrum prescribes four formal events for inspection, adaption and to provide a regular meeting cadence. These regularly cadenced events improve communication and increase efficiency by eliminating the constant scheduling of ad-hoc meetings and allows for the rapid removal of any impediments and promotes quick decision making. The Scrum Master is responsible for the facilitation and timeboxing of each event.

Once a product vision has been established with input from stakeholders, customers and end users, the Product Owner creates a prioritized list of features called a Product Backlog. During sprint planning, the team pulls work from the product backlog to create a sprint backlog and collectively discusses how to implement those features. The team works during that time-boxed sprint (typically 1-4 weeks) to complete the sprint backlog’s work. Daily scrum meetings are held to discuss commitments and impediments, and the Scrum Master removes any obstacles and keeps the team focused on its goal. By the end of the sprint, the team should demonstrate any completed work at the sprint review. The Sprint ends with a sprint retrospective where the group focuses on improvement with the process cycling as needed.


The Agile Advantage


Enhance Flexibility

•Frequent reprioritization of work via Sprint Planning

•Rapid adjustment in product via Sprint Reviews

•Continuous feedback loop builds learning


Increase Speed

•Autonomy in execution by empowering the team

• Transparency informs better decision-making

•Flexible resource allocation optimizes capacity


Easily Scalable

•Scrum Masters drive adoption

• Product Owners facilitates key communication

•Easily scalable with SAFe and LeSS frameworks

Brendan Daly