Introduction to Agile (and Scrum)
Recorded Webinar
Transcript
Welcome
Hello and welcome to our second webinar, which will be on the topic of Agile business analysis as exemplified by the most popular form of Agile, the Scrum methodology.
In this webinar we will tackle the popular subject of Agile. This is not a new topic, but it is one which is taken business and information technology by storm. It can no longer be regarded as a temporary trend, but a major change in direction for software development and to a large extent business in general, and it can be regarded as here to stay.
What Is Agile?
There are many definitions given for Agile. The one we have selected, is the one provided in Wikipedia.
“Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organising cross functional teams”.
Notice first of all that it is concerned with values and principles, rather than a new technique which we can learn from a textbook. We must first regard the culture and purpose for which Agile was designed before we can begin to use it, otherwise it does not make sense.
It is primarily concerned with how people collaborate and interact, to develop software. It is very much a human-based development. There is also a large amount of trust involved in Agile. It depends upon self-organising teams made up of different disciplines and professions being able to interact successfully to achieve results.
History of Agile
Agile was originally developed in the early 1990s in response to the apparently rigid and inflexible Waterfall methodology. A group of programmers gathered together and came up with a manifesto which concentrated upon flexibility and human interaction as the basis of software development. The manifesto is quite detailed but is summarised in a small number of principles as we have in this slide.
People and interactions between them are considered more important than the processes and tools followed mechanistically in the waterfall methodology. Collaboration with the customer is considered more important than dry contract negotiations, which do not help to build a relationship with the users.
It is more important to be able to respond to change rather than mindlessly following a predefined plan. The product is considered to be working software rather than written or graphic documentation.
In other words, it is more important to form a relationship between the members of the team and the customer or stakeholders, than to stay at a distance and simply operate through a legal contract with them. It is more important to be flexible and responsive to changing conditions that affect the project, rather than following a plan some would say mindlessly. The product is the software itself which is considered to be far more important than the documentation.
The Agile Manifesto
The Agile manifesto was published in 2001 based upon 12 basic principles. We do not have time to discuss them in detail here, and you are free to explore them in more detail later, however we can mention a few highlights.
You will see highlighted consistently words like customer satisfaction, cooperation, motivated individuals, face-to-face conversations. These are all words about people successfully interacting while they work towards a common goal.
Principle 2 welcomes changing requirements instead of resisting them as you would find in the waterfall methodology. It expects them to occur throughout the project life-cycle.
Working software is mentioned as the only valued product in several principles. Technical excellence, good design, best architecture and simplicity are mentioned in several principles. The team is expected to be self-organising and to be constantly adapting to change.
Waterfall Revisited
Before we dive deeply into how Agile works, we need to revisit our concept of the Waterfall methodology as the commonest example of existing software development methodologies. It consists of a series of separate stages carried out in sequence with very little opportunity to overlap. In other words, they must be carried out in the correct sequence. One stage cannot be started until the previous stage is completed and signed off. There is very little opportunity for overlap between them.
If an error is detected, it is very difficult to call back and redo a stage. The project could split off another project if extra requirements were detected. Alternatively, if the change is too great or critical, the project would be stopped, re-scoped and started again to accommodate the change. The deadline and the cost would be reconsidered from scratch because of the new or changed requirements. It is unlikely these changes will result in a shorter deadline or reduced costs.
Scrum Project
Let’s consider what Agile actually looks like on the ground. There are many forms of Agile methodology currently in use and published, so for convenience we have selected the most popular one in use locally, which is Scrum Agile methodology.
In the diagram we see an example structure of a Scrum project. It begins with the scoping of a product backlog which is the functions expected to be performed by the software produced. This is equivalent to the project scope in waterfall terms. It is defined as a collection of small atomic functions or software units that can easily be developed in a short period of time by a dedicated team. These functions are prioritised and built in triage order.
The project then consists largely of series of short development cycles called iterations or sprints which can typically last from between 1 to 6 weeks. Most common sprints last 2 to 4 weeks. During the sprint the development team agrees to develop a collection of functions or software units by the deadline. The project is time boxed which means that the deadline will not change. If there are delays or the team can develop the sprint backlog more quickly they will develop less or more than agreed, but the deadline will not change. Once the sprint is over and the deadline reached there will be a review of what has been developed within the sprint. That will dictate what is agreed for development in the next sprint.
There are daily meetings often called stand-ups, where every team member states what they have achieved in the last 24 hours, what they intend to do in the next 24 hours, and any impediments or problems they have encountered or expect. There will then be discussion after the meeting around how impediments and problems can be circumvented. The meeting itself is intended for a fixed agreed time, in other words it is also time boxed. Any issues are handled after the meeting, but the meeting will finish on time. Typically, a stand-up lasts 15 minutes for the normal size of development team.
Scrum Framework
The Scrum framework is illustrated in the diagram below which consists of an end to end process for the Scrum Agile methodology.
The process begins with inputs from the end users, stakeholders, team members and customers to the Product Owner who is the custodian of the requirements. The Product Owner is responsible for compiling the scope in the form of a product backlog. This will be the scope for several Scrum sprints or iterations.
The project team is a multidisciplinary collaborative team. It is their responsibility to prioritise and select the functions from the product backlog which will be developed in the next sprint. They develop a subset of the Product Backlog for one sprint which is simply called the Sprint Backlog.
They then undertake the sprint which will run from 2 to 6 weeks and end on the set deadline. The team will work at a steady sustainable pace to develop the functionality in the sprint backlog by the end of any sprint as it has been agreed. The end result will be functions in the form of executable software that can be released to the user’s customers and stakeholders via the product owner. The product owner is responsible for ensuring the testing and verification that software released will be of value to the business and will function correctly.
As we’ve said there will be daily stand-up meetings to review what each person in the team is doing each day what they’ve accomplished previously and any problems that they have found. The team will be responsible collectively for resolving any problems found. At the end of each sprint there will be a Retrospective meeting which will review the sprint and lead to other meetings which will determine the scope of the next sprint. The next sprint will be decided based upon the next sprint backlog compiled by the team.
The meetings held regularly or at each stage in the project are called ceremonies. These are used to initiate and terminate sprints or projects and to regularly monitor progress.
The Scrum Organisation Structure
The Scrum development team is referred to as the Scrum core team. It is made up of three types of role. The first is the Product Owner. This role is responsible for defining the product backlog and ensuring that it is developed in order of priority. The Product Owner communicates with the customers or stakeholders gathering requirements from them to define the product backlog. At the end of a project or a Scrum the Product Owner is responsible for delivering value to the customer in the form of product releases of working software.
The Product Owner also communicates the requirements to the rest of the Scrum core team.
The Scrum Master ensures that there is a problem free working environment for the Scrum team itself. It is the Scrum Master’s responsibility to resolve any problems or impediments that would hinder the sustainable development process of the Scrum team.
The Scrum team is made up of developers of various disciplines. It is the Scrum team’s responsibility to agree the functions that will be delivered in the next sprint. They are self-organising and do not follow the dictates of a project manager. They work together to resolve problems and deliver working software within each sprint, which delivers value to the stakeholders. If they encounter difficulties they are supported by the Scrum Master, but also adapt the way in which they work so that problems and issues are resolved by the team themselves.
The optimum size for a Scrum Team from 6 to 10 members which is large enough to ensure adequate range of skill sets, but small enough to collaborate easily.
Empirical Process Control
We mentioned earlier that Agile depends upon people following the principles laid down by the Agile methodology. One of the underlying principles of the Agile methodology is empirical process control which is based upon 3 main ideas. The first is that all tasks will be performed transparently so the entire team is exposed to everything that’s going on. If any team member has difficulty delivering their functions the whole team is responsible for resolving those difficulties and ensuring that the team delivers.
Transparency is maintained by incorporating the practice of continuous inspection into the software development process. Not only is the software tested, it is also inspected by the entire team to ensure that the software delivered is according to best practice and the highest quality possible.
The third principle is adaptation. We have already seen that changes are expected and welcomed as part of the development process within an Agile environment. When change does occur, the team adapts to the new requirements and constraints and works in a new way to ensure delivery of the software product.
Kanban
Many people have heard of the Kanban wall when they hear about Agile projects. In practice this is an optional tool for monitoring progress. The Kanban methodology has introduced it to Agile, and it is typically adopted by many other types of Agile project including Scrum, but it is optional.
There are electronic tools that can be purchased to maintain the Kanban wall online such as Jira or Trello. Most commonly projects maintain their Kanban wall physically using post-its on a whiteboard or wall within the office. Columns represent different statuses of development of functions within a sprint. There are typically columns for the sprint backlog, the product backlog, functions in development, functions in test and functions delivered. There are many variations upon the Kanban wall but all typically cover some of these common statuses.
Challenges of Implementing Scrum
When Agile or Scrum is introduced to a new organisation there are several challenges which typically arise that must be overcome. The introduction of Agile is a major change to the way in which the organisation works. It cannot be introduced in a single day and must be introduced using a professional change management process. Let’s examine some of the issues that arise during the introduction of Agile.
To begin with the introduction of Agile demands a degree of trust that the Scrum team will be self-organising and able to work together by mutual agreement and collaboration. This runs contrary to what many managers who have been taught all their lives that people will only work under close supervision of a superior manager. To enable employees to organise themselves and ensure that they are working hard and pulling together demands a change in culture and management methods.
The project management office will operate differently and project budgets will be far more progressive and flexible than they were before. The Waterfall method advocates that the budget should be set at the beginning of the project and it should not change if there is no change in scope. Agile expects change and therefore the budget and scope will constantly change throughout the project. Project estimation will be repeated throughout the project life-cycle instead of being estimated at only the beginning as it is with the waterfall project.
All of these changes will demand a change in culture and the way people work which will require a gradual introduction of the Agile methodology across the company. Many companies are trying out Agile as a proof of concept or in a certain part of the company, usually within the IT department at first. Others are further down the track and are considering introducing Agile across all departments of the business not just in IT.
Agile Professional Development
Before we finish we need to consider how business analysts can get into the Agile methodology and become trained and equipped to operate inside an Agile project, either as a Product Owner, Scrum Master or part of the Scrum team.
The entry qualification for most people is to pass an exam as certified Scrum Master or certified Product Owner. This is the entry level qualification for a business analyst or project manager to participate in an Agile project. In Scrum there is no role for a business analyst or project manager. There are no such formal roles. Therefore, business analysts and project managers will see their job descriptions change radically as they assume one of the roles that we’ve seen in Agile or Scrum project team.
The next steps are to be trained and certified in the application of Agile to larger projects and programmes of work. The first is the Scaled Agile Framework or SAFe® framework. And the final step is the Large Scale Scrum or LeSS for short. These constitute the application of Scrum Agile methodology to the larger scale. It can be said that the large-scale Scrum is more about what you don’t do on Scrum projects rather than what you actually do.
Thank You
Thank you for listening to a webinar on this topic. I will be happy to take any questions at this time. If you think of any further questions after the webinar has concluded, please send an email and we will endeavour to provide an answer to your questions or make a comment in reply to your observations.
We hope you’ve enjoyed this webinar on agile business analysis and will join us for future webinars. Thank you.
To learn more and get certified please see our Agile courses page.
