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.
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:
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:
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:
Line management is an essential role for all organisations. If done well, it can result in significant benefits to staff and their organisation:
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.
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.
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.
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”?
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?
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.
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.
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.
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.
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.
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.
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.
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?
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 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.
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.
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:
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:
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:
There are two categories of features, business features and enabler features.
Business features directly benefit the business or its customers.
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 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:
There are two categories of capabilities, business capabilities and enabler capabilities.
Business capabilities directly benefit the business or its customers.
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.
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.
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.
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.
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.
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:
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.
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.
‘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.
The PM and PO roles have a different focus in SAFe:
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.
Responsibilities of a product manager in SAFe include:
Responsibilities of a product owner in SAFe include:
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
For the event itself, there are two key facilitation roles:
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:
There are very many different tools out there that allow video conferencing. Fundamentally there is one main decision to make. Do you:
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.
There are two elements to this:
In a similar way to the video conferencing, fundamentally there is one main decision to make. Do you use:
Using an online polling tool could be helpful in the following circumstances:
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’.
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.
Once you have chosen your tools, the next stage is to prepare everything for the planning event.
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.
To make the event slick it is key that everyone who is going to present knows and is lined up ready. This includes who:
Each person presenting should ensure that:
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.
As well as the content itself, there will be much to prepare in terms of online tools. For example:
Ahead of the event communicate the following:
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.
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.
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.
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.
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:
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:
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.
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.
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”.
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.
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.
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.
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.
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%).
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 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.