FAQs

Supporting You During COVID-19. Readmore

What is an Agile Development Team?

A development team is a group of people that work together to create software. This is complex, creative work that requires adaptability as technical challenges arise and business requirements evolve. An agile development team will seek to meet these challenges by applying the principles of cross-functionality and self-organisation.

Cross-functional

Rather than organising people into specialist teams such as analysts, coders, and testers; agile development teams have all of the skills to turn requirements into production-ready product. This does reduce pure efficiency and utilisation – there may be times that there is nothing to do but test, so coders and analysts will have to help out. The pay-offs for this compromise include:

  • Reduced dependencies and co-ordination required to get a feature into production, increasing predictability.
  • Faster feedback cycles: mature teams are able to get from idea to deployed feature in a matter of weeks.
  • Increased control and visibility.
  • Enhanced risk management for decisions made on requirements and technology.

Self-organising

There is no project manager assigning tasks to an agile development team, nor a defacto “team lead” amongst the developers who keeps everyone busy. Self-organisation is built on the premise that if no single person is in charge, then the whole team needs to stay vigilant and engaged in their shared goals. This is a radical departure from traditional development, where your responsibility as an individual technologist ends at delivering your work package and reporting issues. Now, individuals share whole-team accountability for their actions and decisions. If implemented well, this is likely to mean:

  • Higher motivation arising from greater autonomy and trust.
  • Increased innovation, resulting in new feature ideas and technical solutions.
  • Reduced defects as the whole team takes shared accountability for overall outcomes.
  • Efficient problem resolution: teams are able to act without escalating up the chain of command and waiting to be told what to do.

Can a Scrum Master also be a Line Manager?

There is nothing in the Scrum Guide that says roles cannot be combined. This is true for core roles such as Product Owner and developer, and also for complimentary roles. A Scrum Master would not be breaking any rules if they also served as a technical architect; project manager; coffee shop assistant; finance director; or line manager for members of the team.

It is for each team and organisation to decide what makes sense for them, and what risks, conflicts of interest, or time management issues might arise. For example, a scrum master may encounter:

  • Time management issues if they had to work in the coffee shop for an 8 hour shift every day
  • A conflict of interest between optimising the system for value vs delivering on time, on budget if they were also a project manager
  • Risks of not being able resist pressuring the team to over-commit during time-critical delivery scenarios if they also served as a product owner

Line management is an essential role for all organisations. If done well, it can result in significant benefits to staff and their organisation:

  •  Career development
  • Increased skills and productivity
  • People feeling valued and motivated
  • Having an accountable person to take the lead in managing problems if they arise

In practice, there have been cases where scrum masters have fulfilled this function, and it’s possible to be successful with the right approach. If considering this arrangement, the following conflicts with the scrum master role should be anticipated and mitigated:

Coaching – Scrum Masters provide this service on the basis that teams and individuals take ownership of the decisions and outcomes. This works better when the coach isn’t directly accountable for the actions and decisions of the people they are coaching.

Leadership – Scrum Masters lead by example and provide an enabling function without detracting from the team’s autonomy. This works better without direct authority, regardless of whether you choose to use it, because teams retain ownership of outcomes.

Organisational HR policy – Part of the role of the Scrum Master is to coach the organisation to make the most of Scrum. Sometimes this might include advising the organisation on the effects of established HR policy, such as the way promotions and pay rises are handled. If HR policy is effective, there would be little impact; however, if HR policy was creating problems with team motivation or alignment, then a good scrum master should seek to highlight these problems and influence change. This is more challenging if the scrum master is accountable for implementing existing policy. It can also affect the dynamic between the Scrum Master and members of the team if they play a role in evaluating their performance.

In summary, line management is an essential function that can have a positive or negative effect on team capability. Like other functions, it takes skill and experience to do well, and there are risks of conflict of interest. In deciding who should perform the role, consideration should be given to the people available, their skills and experience, and how it might impact their existing responsibilities. There are usually better options than the Scrum Master, but if not, an awareness of the potential issues above will increase the chances of that person leading effectively.

Why is Estimation part of Refinement and not Sprint Planning?

Scrum teams plan continuously across multiple horizons. In the daily scrum, the development team plans their daily activities and re-assess their ability to deliver the sprint goal. At the start of every sprint, the team needs to create a sprint backlog, giving them focus for the few weeks. Scrum teams also need long term plans that help them understand when they are likely to meet business objectives or milestones; this is release planning.

Each level of planning requires a different style of estimation. During the daily scrum, the development team will be creating a plan for the next 24 hours; this will require a certain amount of informal estimation to determine a reasonable amount of work for a day. During sprint planning, it is crucial to understand how much work can be completed within the sprint and therefore, how many product backlog items the team should select. Release planning takes a longer-term horizon and requires deeper estimates through the backlog so that release plans can be forecast.

Suppose estimation is limited to the sprint planning event and entirely focused on the product backlog items selected for the sprint. In that case, it will not be possible to estimate further down the product backlog providing the data needed for release planning. It may be possible to estimate further down the product backlog during sprint planning; however, this would reduce the focus on the purpose of the event and lower the team’s ability to achieve the outcomes of it. The process of estimation often raising technical risks, challenges, or decisions. These can be disruptive to the sprint planning process as there is a pressure to confirm the plan by the end of the timebox. If discovered during refinement, there is more time to decide how to resolve the issues discovered.

What is the Sprint Review Canvas?

The sprint review is a critical event in the scrum framework for implementing the empirical process, making the increment transparent, collaborating with stakeholders and using feedback to guide future sprints. It enables the scrum team to ensure they deliver the highest possible value.

The key elements of discussion are described in the scrum guide; however, when facilitating a scrum event, a little structure helps. The sprint review canvas is intended as an aide-memoire to all of the different elements to be discussed. It enables you to move your scrum team away from a simple demo to a holistic review.

The nine segments of the sprint review canvas

The Sprint

This segment helps bring transparency to how the sprint progressed. What was the sprint goal, and was it achieved? What items in the forecast were done and what was not “done”?

  • Challenges

Not all sprints are plain sailing. Often the team face challenges and it’s useful to share if they were overcome and if so, how?

Feedback on the increment

An essential part of the review is to present the increment and gather feedback from stakeholders. This segment also reminds us of the importance of having stakeholders in the review.

Targets and delivery

Often teams have specific milestones they’re trying to achieve. Discussion of progress may inform changes to the order of the product backlog. Progress or lack-of may affect the viability of a product or feature.

Empirical Data

Using data and evidence helps the scrum team focus on the real goal of delivering value. Without measuring value, success is based on nothing more than intuition and assumption.

Marketplace

Many marketplaces change rapidly with new technology, competitors, environment factors and customer expectations. Reviewing the marketplace helps keep the product focused on where the market is going rather than where it was.

Next releases

Since the release cycle is not tied to a sprint, what product releases are upcoming, and what is the forecasted value of them? This helps bring transparency to the product backlog to both the development team and stakeholders.

Next sprint

The sprint review is the last opportunity in the scrum cycle to discuss product backlog items. Any urgent items arising from the review for the next sprint are best discussed before sprint planning.

Success

All events take a considerable amount of time and effort. They each have a specific purpose. It’s important to reflect on how effective this sprint review was. The scrum framework provides a mechanism whereby the development team can collaborate with the product owner to ensure the product catalogue is in a ready state. Product backlog refinement happens outside of the prescribed scrum events and takes up no more than 10% of the development teams’ capability. During this time the development team will be able to spend their efforts working down the product backlog and providing the right amount of detail. Refinement includes the processes of estimating the product backlog sufficiently so that the product owner can forecast releases.

What are the stories, features, capabilities, and epics in SAFe?

When you want to express a requirement for functionality in SAFe, you can use stories, features, capabilities and epics. When is each of these used? What level of detail do they contain? And who has content authority for them?

Requirement model

In general, descriptions of new functionality, or updates to existing functionality, start at a high level and get broken down into smaller items as more detail is needed and understood. Not every team using SAFe will use capabilities and epics, but all teams using SAFe should use stories and features, as they are part of the essential levels.

Stories

Stories are created by the agile team who are going to do the work and they are put onto the team backlog. The product owner in that team has content authority over the stories and, as part of that, they prioritise the stories on the team backlog. All stories must be small enough to fit into a single iteration for a single agile team. There are two categories of stories, user stories and enabler stories.

User Stories

These describe the required functionality from the perspective of the user, using the user voice statement format, which is:

As a <user>

I want <function>

So that <purpose>

This boils down to the ‘who?’, ‘what?’ and ‘why?’ of the change.

In addition to the user voice statement, clear acceptance criteria are added until the members of the agile team have sufficient understanding of the requirement to be able to deliver the item.

Enabler Stories

Where there is work to be done by an agile team that does not directly benefit a user of the system, this can be expressed as enabler stories. Broadly, there are four main types of enabler stories:

  • Exploration – often referred to as a ‘spike’. The agile team perform an investigation to better understand available options and what work would be required to deliver a story planned for a later iteration.
  • Architecture – design a suitable architecture that describes the components in a system and how they relate to each other.
  • Infrastructure – perform some work on the solution infrastructure.
  • Compliance – complete an action required for compliance purposes, such as providing the documentation required by a regulatory authority.

There may be other activities that don’t fit into these four types, and they can still be written as enabler stories. The format for all enabler stories is straightforward:

  • Story statement – a simple, clear statement about what needs to be done.
  • Acceptance criteria – added until the members of the agile team have sufficient understanding of the requirement to be able to deliver the item.

Features

Features are created by the product manager for an agile release train (ART). They flow through a programme kanban system. Part of that is the programme backlog, where the features are prioritised by the product manager. Features get broken down into stories by agile teams at programme increment (PI) planning events.

Features must be small enough to be delivered in a single PI by a single ART.

All features have the same basic format:

  • Phrase – a brief description of the feature.
  • Benefits hypothesis – a statement, which can be validated, about the benefits of the feature.
  • Acceptance criteria – added until the members of the agile teams, who will deliver this feature, have sufficient understanding of the requirement to be able to release the feature. Acceptance criteria also include any applicable non-functional requirements.

There are two categories of features, business features and enabler features.

Business features

Business features directly benefit the business or its customers.

Enabler features

Where a feature does not directly benefit the customer or the business but completes work necessary so that one or more business features can subsequently be implemented, this is an enabler feature.

Capabilities

Capabilities are items that exist at the large solution level in SAFe. This is an optional level.

Capabilities are created by the solution manager for a solution train. They flow through a solution kanban system. Part of that is the solution backlog, where the capabilities are prioritised by the solution manager.

Capabilities are items that are too big to be delivered in a single programme increment by a single ART and so are broken down into features. This is done by product and solution management, working in conjunction with solution and system architects/engineers. Generally, this will happen two weeks before PI planning, to allow time for the resulting features to be prioritised and socialised ahead of the PI planning events.

All capabilities have the same basic format as features:

  • Phrase – a brief description of the capability.
  • Benefits hypothesis – a statement, which can be validated, about the benefits of the capability.
  • Acceptance criteria – added until the product managers, who will take over content authority for the resulting features, have sufficient understanding of the requirement to be able to write suitable features to be implemented by their respective ARTs. Acceptance criteria also include applicable non-functional requirements.

There are two categories of capabilities, business capabilities and enabler capabilities.

Business capabilities

Business capabilities directly benefit the business or its customers.

Enabler capabilities

Where a capability does not directly benefit the customer or the business but completes work necessary so that one or more business capabilities or features can subsequently be implemented, this is an enabler capability.

Epics

An epic describes a sizable initiative that is deliverable by an agile release train, solution train, or multiple solutions trains. Each epic has an epic owner, who could be anyone in the organisation, but is most likely a business owner or product professional.

As part of lean portfolio management, there will often be a ‘portfolio epic threshold’, above which the epic will be considered a portfolio epic, even if it could be delivered by a single ART or solution train. This might be based on the cost of the work or the risk to revenue streams by making the change.

Programme epic

A programme epic is deliverable by a single ART but would require more than one programme increment to do this. It has a business impact that is below the portfolio epic threshold.

Solution epic

A solution epic is deliverable by a single solution train but would require more than one programme increment to do this. It has a business impact that is below the portfolio epic threshold.

Portfolio epics

A portfolio epic is anything that has a business impact that is above the portfolio epic threshold or requires more than one solution train to be involved in the realisation of the initiative. Portfolio epics flow through a portfolio kanban system.

Format of epics

As with stories, features and capabilities, epics can be business epics or enabler epics. However, the format of an epic is more involved than that of features or capabilities, and typically has the following elements:

  • Name of epic
  • Epic owner
  • Description – a paragraph of text describing the epic that is clear and concise and covers who it is for, what it will do and what benefit it will bring.
  • Business outcomes – anticipated measurable benefits based on the above description
  • Leading indicators – early measures that will help validate the benefit hypothesis before the entire solution is implemented
  • Minimum viable product – the smallest possible selection of elements of the solution that can be used to validate the benefits hypothesis

When an epic is approved, it queues until it converted into the capabilities and features necessary for the MVP. If the benefits hypothesis is validated by the MVP, then the rest of the aspects of the epic can be progressed.

Getting started

Remember that only stories and features are in the essential level, so starting with a single agile release train and getting used to these two ways to express requirement is a good way to start.

What is the difference between a Product Manager and a Product Owner in SAFe?

‘Product manager’ (PM) and ‘Product Owner’ (PO) are two roles that appear in many organisations which have adopted agile approaches to their work. In SAFe, these roles are distinct, each with specific responsibilities.

Different focus for each role

The PM and PO roles have a different focus in SAFe:

  • The product manager is focused on the benefits to the customer and organization. They prioritize features and ensure each feature has clearly defined benefits to the customer and/or the organization before it can be picked up by one of the agile teams. The PM is also the main point of contact for business owners and other interested parties who would like work to be done by members of the agile release train (ART).
  • Product owners are focused on the needs of their agile teams. They are there to make sure that their teams have all of the information they require about the feature they are working on, so the team can break it down into stories. The PO is available to the team and, if there are questions that the PO cannot answer, they will seek out a suitable, timely response.

The product manager and the product owners in an agile release train must form an effective working relationship. They must collectively understand their customer’s needs. The PM has the main contact with the customer, with information flowing from the customer to the PM, into the POs and their respective teams.

The PM and POs meet frequently at ART Sync or PO Sync events, and work closely during the PI Planning event for the ART. They also need to be able to communicate effectively outside of these formal sessions so that queries can be resolved quickly and stakeholders can be kept up to date with current information.

Product Manager

Responsibilities of a product manager in SAFe include:

  • Setting the vision for the agile release train
  • Maintaining the roadmap for the agile release train
  • Content authority over features and their associated acceptance criteria
  • Working with the system architect and product owners to understand enabler features
  • Ordering the program backlog of features (including enabler features)
  • Participating in PI Planning, System Demos, and the Inspect and adapt workshop for their agile release train
  • Accepting features as complete
  • Managing the expectations of business owners and other stakeholders
  • Working with the solution manager and other product managers, if the ART is part of a solution train
  • Has authority to say ‘No’ to stakeholders, organizational managers and leaders

Product Owner

Responsibilities of a product owner in SAFe include:

  • Ensuring user stories are in line with the team’s PI objectives, the features that the team have agreed to work on, and the vision
  • Content authority over stories and associated acceptance criteria
  • Helping the agile team break features down into stories to go onto the team backlog
  • Working with the team and the system architect to understand enabler stories
  • Ordering the team backlog of stories (including enabler stories)
  • Participating in iteration planning, iteration review and iteration retrospective
  • Accepting stories as complete
  • Available to the agile team members to answer queries and negotiate alternative options
  • Representing the needs of customers to the team
  • Agreeing iteration goals with other agile team members
  • Using the iteration goal when interacting with stakeholders and organisational management
  • Working with the product manager and other product owners in the agile release train

Can one person do both roles is SAFe?

The SAFe structure is designed so that the PM and PO roles are not done by the same person in the same agile release train. This ensures that their attention is not divided between the team’s needs and the customer’s needs, while providing regular sync-ups to ensure everyone stays aligned.

What is an Agile Culture?

An agile culture is one that has a bias towards collaboration and cooperation and minimises autocracy, control and bureaucracy. It pushes decision making down the organisation to enable teams to take ownership of business outcomes and holds them to account.

Adoption of an agile framework requires more than just adding a new project management methodology. For the new approach to embed and to reap the benefits, organisations often need to develop a new culture alongside it.

Culture clues from the manifesto for agile software development

The Agile Manifesto highlights the focus on people and interactions, noting that it is the sum of the work and collaboration between developers and their customers that creates the working software. By implication, organisations must eliminate barriers to cooperation between these two groups.

Alongside the manifesto are twelve principles that underpin many of the agile frameworks. From these, an agile culture must support:

  • Frequent delivery
  • Changing requirements
  • Trust and empowerment of teams
  • Low barriers to communication
  • Low bureaucracy
  • Empirical reporting
  • Technical excellence
  • Self-organising teams
  • Continuous improvement

Value-based frameworks

Many agile frameworks include values to guide the behaviour, beliefs and attitudes of people who use them. XP consists of the values, communication, courage, simplicity and feedback. While Scrum includes focus, respect, openness, courage and commitment.

The values are often said to put life into their respective frameworks, and the absence of these values have coined expressions such as “zombie scrum” to describe a lifeless approach.

Values direct behaviours and actions, while culture is the emergent property of how any group works together. It is, therefore, mostly dependent on the values that the group adopts.

Agile frameworks require self-organising teams

Managing the complexity of technical product development requires a diversity of thought. Complex problems require new, novel and bespoke solutions. Best practice will not help solve complex problems.

It is unlikely that the big boss will have all of the answers, and have sufficient knowledge and experience to dictate the solution. Solutions will arise from the interplay between experts that self-organise to solve the problem in the best way they see fit.

Self-organising teams require a specific kind of leadership. Coercive command and control style leadership combined with hierarchical organisation structures run counter to self-organising teams. Servant leadership based on respect and support is better suited to supporting self-organising teams.

Continuous improvement grows cultural change

Each of the agile frameworks includes continuous improvement mechanisms in the form of retrospectives. Including behaviours, beliefs and values in these improvement cycles will allow the agile framework to grow its desired culture. Those in leadership roles must provide the space and authority for teams to make their own changes.

How do I start implementing SAFe?

The Scaled Agile Framework®, or SAFe®, is one of a growing number of frameworks that seek to address the problem of coordinating the activities of multiple teams when using lean and agile delivery methods. This article gives advice on how to start using SAFe.

SAFe is designed to coordinate the work of multiple teams all working together to deliver value to the business. Experience shows that scaling frameworks become valuable when at least 5 teams need to coordinate their work.

If you have fewer than 5 teams and it is unlikely that you will scale up to 5 teams, then SAFe may not be the right solution for you. However, if you have fewer than 5 teams but expect to scale up the number of teams working together then it may be useful to start using SAFe so that it is established ahead of scaling up.

Here are the first three steps recommended to get underway with SAFe:

a)     Find a sponsor, the more senior the better

Implementing SAFe requires investment of time and money, and it needs some level of organisational change. This is not something that can be done from the ‘ground up’ but needs leaders in the organisation to sponsor the change and help make it happen. Ideally, they would complete the Leading SAFe training course.

b)      Find a SAFe specialist consultant

SAFe has a specific role called SAFe program consultant, whose responsibility is to get SAFe implemented successfully. Whether you hire a consultant, bring in a contractor or get your own staff trained is up to you. You are specifically looking for an up to date ‘SPC’ qualification. SAFe keeps evolving so old qualifications do go stale. Also licenced SPCs have access to a comprehensive set of SAFe toolkits from Scaled Agile. If you are bringing in an external SPC, check that they have practical experience.

c)     Pick a date to start with your first agile release train

Depending on the number of teams involved, you should be looking to start 4-6 weeks after your SPC has been with you full time. This will provide enough time for the SPC to get the people who will be involved ready. They will also need the support of the sponsor to make things happen as they need to. To begin with focus on the 10 essential SAFe elements.

How do scrum teams work with Stakeholders and Customers?

In Scrum, the product owner is accountable for managing stakeholders and customers. As with any of their accountabilities, it is up to them if they wish to delegate part of their area of responsibility to someone else; ultimately, they remain accountable.

To build and deliver great products that satisfy customer needs, it is essential that the product owner deeply understands the customer. Product owners should be fully engaged in gathering ideas and feedback from them.

Stakeholders can have a powerful impact on the success of a product. For example, there may be regulatory or legal considerations in delivery of a product that need to be taken into account. Having those stakeholder groups engaged and supportive will have benefits for successful delivery. Their involvement can mean a huge reduction of risk to the product plus, if they are actively involved in the feedback process, value can be added more quickly and therefore productivity increased.

When do stakeholders engage in the scrum framework?

The sprint review is the event in scrum where stakeholders are invited to inspect the done increment at the end of each sprint. The sprint review is a powerful meeting to engage customers and stakeholders in the product development lifecycle. They will see and ideally interact with working software. During the sprint review they give ideas and feedback for future development.

The product owner isn’t obligated to accept all the feedback from stakeholders. However, feedback that is accepted can then be added to the product backlog and prioritised for development. If an idea has been rejected it is often good practice to explain why it was rejected clearly, as this will help to maintain trust and transparency between the product owner, development team and stakeholders. This should help to keep stakeholders well informed and involved rather than leaving them disenfranchised and disengaged.

Where else can product owners engage stakeholders and customers?

Stakeholders and customers can be engaged at any time, not just at the sprint review. Indeed, a good proportion of a product owner’s working day will be spent engaging stakeholders. Engagement occurs in a variety of business contexts, from formal customer interviews, to informal chats over coffee. It is not unusual to have many stakeholders with complex and sometimes ambiguous needs for a product. Often these needs will be constantly changing and may be at odds with each other. So how does a product owner keep these stakeholders engaged and onside?

The complimentary practice of user story mapping can be a powerful tool in engaging customers and stakeholders. It keeps them informed and engaged, particularly with a product where requirements have been hard to articulate to a broad stakeholder base.

Information radiators such as burn up and burn down charts, plus scrum or kanban boards that physically exist are good ways of showing progress against plan, whilst keeping everything transparent.  If electronic versions are in use then stakeholders need to know how and where to access them.

There are many other metrics that stakeholders may be interested in and different people may be interested in different things.  Provided it does not create too much of an overhead and is worthwhile doing, the myriad of data held in project tracking systems (Jira, TFS, Version One), source control (Github / GitLab), continuous integration (Jenkins) and application monitoring (AppDynamics) can be centralised and displayed in dashboards to support buy-in from stakeholders.

How could I run PI Planning when everyone is working remotely?

In the Scaled Agile Framework®, SAFe®, Programme Increment (PI) planning is an essential element and is generally run as ‘big room planning’ event where everyone is in the same location. Often there are some people who connect remotely but how could PI Planning be done when everyone is working remotely?

Think about the challenge of remote PI planning in three stages:

  • Select a set of online tools for people to use;
  • Prepare tasks ahead of the planning event;
  • Running the PI Planning event.

For the event itself, there are two key facilitation roles:

  • The host – who runs the meeting from a visible, traditional facilitation point of view, introduces the briefings, manages the schedule, keeps people focussed on outcomes etc.
  • The online facilitator – who looks after the video conference meetings, breakout rooms, and is available for people to contact for assistance during the sessions.
  • It would be very difficult for the same person to perform both roles during the event.

Online tools

There are many tools available that could support an all-remote PI Planning event. Rather than specific tools, here’s a look at the functionality that would be required to help it run smoothly:

  • Video conference – to see and hear what is going on;
  • Chat – to ask questions or to ask for assistance;
  • Online collaboration – to create the team and programme outputs;
  • Online polls – to do the confidence votes and to help the facilitation;
  • Online surveys – to get the end of PI planning feedback;
  • Backlog management tools.
Video conference tools

There are very many different tools out there that allow video conferencing. Fundamentally there is one main decision to make. Do you:

  • Use one high-end tool that allows everyone to connect for the whole duration and move in and out of breakout rooms for specific sessions, or
  • Use multiple video conference rooms lines and people dial in and out of them over the course of the day depending on where they are on the schedule.

Using one tool would be easier for participants and it would be easier to keep to the timeboxes as people would be brought back to the main session automatically, but would require more coordination i.e. someone opening and closing the rooms, putting the right people in the right rooms, etc.

Chat

There are two elements to this:

  • Having an open chat channel that all attendees can use to put in questions, point out issues like a loss of audio or broadcast information, state what time we will restart after a break, will help with keep the event flowing.
  • Allow attendees to contact an online facilitator directly if there are any issues relating to the event that they need support with, such as video conference details or online tool links.
Online collaboration tools

In a similar way to the video conferencing, fundamentally there is one main decision to make. Do you use:

  • A single online canvas which contains areas for each of the teams and also shared areas for cross-team collaboration.
  • Multiple online boards, each with a specific purpose. For example, a board for a single team to forecast their sprints. A different board to capture risks. A different online board specifically for programme level items such as features and cross-team dependencies.
Online polls

Using an online polling tool could be helpful in the following circumstances:

  • Having a confidence vote towards the end of the session to see if the forecasts are believed to be achievable.
  • Asking the audience direct questions – do you need more time? Shall we have a break? Which options should we go with?
Online surveys

This is really to capture feedback about the session so that improvements can be made for next time. Keep it short and snappy but try to get people to fill it out on the day rather than doing it ‘later’.

Backlog management tools

If you’re not using one already, you’ll need to move your backlog into a virtual environment so that you can access, amend or add details to the product backlog items.

Preparation tasks

Once you have chosen your tools, the next stage is to prepare everything for the planning event.

Prep content

Getting features ready in your chosen online collaboration tools so that all teams will have access to them and they are in sufficient details for the teams to use them in the team breakouts.

Decide who will do what

To make the event slick it is key that everyone who is going to present knows and is lined up ready. This includes who:

  • Will present each briefing
  • Will present draft plans on behalf of each team
  • Will present draft risks on behalf of each team
  • Will present draft objectives on behalf of each team
  • Will present the planning adjustment
  • Will present final plans on behalf of each team
  • Will present final risks on behalf of each team
  • Will present final objectives on behalf of each team

Each person presenting should ensure that:

  • They have a good connection
  • There is little background noise in their location
  • They are familiar enough with the technology to share their screen etc. as required.
Check equipment

Everyone should check that they have appropriate and working equipment for the event, especially those who are going to present. It may be beneficial to get everyone to a minimum standard. For example, reasonable quality headphones with a built-in boom microphone.

Prep online tools

As well as the content itself, there will be much to prepare in terms of online tools. For example:

  • Getting any online boards set up with the appropriate columns
  • Getting the boards / canvas set up for each team
  • Getting a space ready for identified risks
  • Getting a space ready for team and programme objectives
  • Everyone can access the online tool
    (e.g. there are enough licences, no firewall restrictions, etc.)
Communicate

Ahead of the event communicate the following:

  • All of the video conference details
  • All of the online tool access details
  • The event schedule
  • The process and objectives for each session
  • Contact details for the online facilitator

Running the PI planning event

PI Planning is usually run over 2 days. The first day in particular can be very long, especially for those involved in the management review and problem-solving session. Consider spreading out the event over 3 days – this is also useful if there are multiple time zones so there is a better chance that the common hours could be more sociable.

Limit to a maximum of 6 hours of video conference per day for everyone, including the people involved in the management review.

As part of the introduction, include a slide on etiquette for remote meetings (such as keeping your line on mute if you are not speaking). Also add in an overview / reminder of the tools to be used by each team in the breakout sessions.

Frequently refer back to the schedule and keep people informed of where we are up to and what is next, and indicate which video conference lines, tools, etc are required for each session.

Ensure that stakeholders stay contactable even if they are not needed immediately in some of the session.

It is highly likely that things will not go perfectly. Make a note of improvements that could be made for subsequent events, fix what can be fixed, but always focus on the objectives of the event so that at the end of the event there is alignment across the whole agile release train for the programme increment ahead.

What is Business Agility?

Business agility is the inherent ability of an organisation to respond to change.

Can you think of a business that has gone bust? Woolworths, Toys ‘R’ Us, Poundland? There are loads of them out there. These days it’s not just making a profit, but also survivability that matters.

People cite all kinds of reasons for a business failing. Strong competition, the economy and even the weather, amongst many other things.

The reality is that it’s almost always the business’s inability to respond to change that kills it. A rapidly changing technology landscape, rising customer expectations, increasing competition and shortened times to market make it very hard to compete.

Many businesses want to respond to these pressures, but simply can’t do so. They know they are in trouble, but somehow can’t organise themselves to react.

Quite often it’s simply down to how the company is structured that gets in the way. Instead of being organised around product lines, companies are built to support administrative areas, like marketing, sales and fulfilment.

The issue here is customers don’t buy company departments – they buy the products the company makes. This leads to decision making being convoluted and slow. There’s a lack of ownership of the products and direction is administered by committees with political loyalties to colleagues, instead of direct representation of the users and their needs.

The rapid pace of change in our world is still in its infancy. All the evidence points to change becoming faster and faster so it will become harder and harder to survive as a business.

The lean and agile tools and techniques are great at helping businesses change how they are structured, work, think and operate – but they all fall under the wider umbrella of business agility.

Why do OKRs support Business Agility?

Much is written about OKRs and their use. In this FAQ find out more about what OKRs are, how they are used and implemented and why OKRs can be useful in supporting business agility.

What are OKRs?

OKR is an abbreviation for Objective & Key Result. OKRs were created by Andy Grove of Intel in the 1970s, however they started their rise in popularity when John Doerr, his protégé, introduced them at Google in 1999. OKRs are now widely used amongst the biggest technology companies in the world including Google, Linkedin, Uber, Twitter and Bono’s One organisation.

They are a framework of defining and tracking objectives and their outcomes. There main goal is to define company and team “objectives” along with the measurable “key results” that define achievement of each objective.

OKRs are about the company’s goals and how each employee contributes to those goals. Performance evaluations, which are entirely about evaluating how an employee performed in a given period, should be independent from their OKRs.

What is an Objective?

An objective describes what you want to achieve and should be ambitious. Objectives should be significant to the company and personally meaningful, they should promise clear business value, as well as being aspirational. The purpose of setting an objective is to write out what you hope to accomplish such that at a later time you can easily tell if you have reached, or have a clear path to reaching, that objective.

Objectives should be:

  • Significant
  • Concrete
  • Action orientated
  • Inspiring

What is a Key Result?

Key results articulate how you are going to achieve the objective. They should be measurable and limited to 3-5 key results per objective. The important element here is measuring success.

Key results should be:

  • Specific and time bound
  • Aggressive yet realistic
  • Measurable and verifiable

How are OKRs implemented?

Approaches vary but it is helpful to first define organisational objectives, so teams and individuals can set their OKRs to align and contribute to those larger organisational goals. This can help to create alignment through the organisation, giving teams and individuals a clear understanding of how their work contributes to the bigger picture.
Depending on the size of your organisation you then need to decide how many levels of “team” OKRs will best serve the organisation – e.g. does each department, function, sub-group need their own OKRs?

Typically the OKR cycle begins at the start of each quarter with the CEO setting 3 to 5 OKRs for the whole organisation. These OKRs should be ambitious and transparent to the whole organisation. Once these have been set it is then possible for other levels of the organisation to set their own and ensure they are aligned with overall strategy and direction. Throughout the life of the OKRs, progress is made transparent and monitored by management. Midpoint check-ins to see how well the team is doing are common. At the end of the quarter a formal review takes place. With the emphasis on transparency, it is possible to see whether any OKRs are out of alignment with those of the organisation.

Communication is key

All OKRs, regardless of the level they are set, should be visible and transparent to everyone across the company. Progress of the OKRs should be tracked and regularly updated in a way that is visible to all.

OKRs help with motivation

Since OKRs focus on measurable outcomes rather than how the objective is to be achieved team members have an element of autonomy to self-direct towards their own solution. Inspiring objectives provide purpose as to why an individual should work towards something. Having autonomy and purpose have been identified as significant components of motivation popularised in Dan Pink’s “Drive”.

Why do OKRs support business agility?

Typical approaches to management by objectives (MBO) have become poor substitutes for the active managing of individuals, often with an emphasis on form filling and process following. For the majority of organisations following MBO is an annual cycle where once a year employees set objectives for the year then file them until the year end when there is a flurry of activity to justify their efforts over the year. The OKR approach reduces the feedback cycle from setting once a year to quarterly alongside midpoint reviews. Reducing the feedback cycle enables a business to achieve agility by allowing a refined direction to be set based on observations on how it is performing. Making observations and adjusting direction (setting new OKRs) is supported by making clear and measurable outcomes fully transparent.

What is Agile

etc.) or a specific tool (i.e. JIRA, Rally, etc.).

The term agile was first coined for this in 2001, in the Manifesto for Agile Software Development (Agile Manifesto) and although originally written as Agile (with a capital A) this is progressively becoming deprecated.

Success in Agile is based on an attitude of “servant leadership” and focuses on the team, not just developers. Agile encourages and does not lack in accountability or ownership. As a solution for complex problems, teams must “be” Agile, not just “do” Agile.

What are the principles of Agile?

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity — the art of maximizing the amount of work not done — is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How do organizations benefit from being Agile?

One benefit of agile is to reduce a product’s time to market by delivering a product increment frequently. Through this process, customers and users are engaged throughout the delivery cycle to regularly review the product increment and provide feedback. By creating feedback loops with every increment, the product created value working with customers rather than for them. As a result, excess time and resources are not spent creating something customers do not want.

Being Agile also promotes innovation in product teams. Taking an iterative, incremental approach promotes experiential learning, and short release cycles encourage teams to experiment to find relevant, simple solutions.

What are the specific tools for Agile?

Although Agile does not require a specific set of tools for a successful adoption, not all traditional project management and other tools work well with Agile. Some companies configure existing tools in an Agile way while others use index cards and sticky notes to follow the frameworks. Some development group use JIRA software to help with things like requirements management, collaboration and testing.

According to the 10th State of Agile Survey (2015), out of the many software management solutions on the market, over two-thirds of survey respondents use Microsoft® Excel (60%) to manage agile projects. Other commonly used tools were Atlassian / JIRA (51%), Microsoft Project (33%), and VersionOne (28%).

What are the most popular trainings / certifications in Agile?

Project Management Institute – Agile Certified Practitioner (PMI-ACP)

The Agile Certified Practitioner (ACP) from the Project Management Institute (PMI), is for project management professionals whose organizations currently use or are moving to agile practices. The PMI-ACP proves certification holders have real-world experience managing agile projects and familiarity with many subsets of the agile methodology including Scrum, Kanban, Lean and others. Those who achieve the certification must earn 30 professional development units (PDUs) every three years to maintain their status.

Scrum Alliance

Scrum is the leading framework of the agile methodology, especially for software development. The Scrum Alliance is the leading membership organization for Scrum professionals, with the mission of supporting widespread adoption and effective practice of Scrum. The Scrum Alliance offers six Scrum certifications for IT and software development professionals: Certified Scrum Master, Certified Scrum Product Owner, Certified Scrum Developer, Certified Scrum Trainer, Certified Scrum Coach and Certified Scrum Professional.

International Consortium for Agile (ICAgile)

The International Consortium for Agile is an independent accrediting agency offering comprehensive agile certifications that provide role expertise across all agile ‘flavors,’ including Scrum, eXtreme Programming (XP), Kanban and more. There are three certification levels: Professional, Expert and Master, to test and evaluate candidate’s knowledge acquisition and competency within Agile.

GET IN TOUCH

Have More questions?

  • 5 + 22 =

Toggle title

    Choose Language»