The Agile Mindset

4 March 2020. This article introduces some of the key concepts in Agile Project Management as well as the mindset underpinning the different frameworks.

1) Agile Concepts

Agile is set of 4 values and 12 principles, published in 2001 as the Agile Manifesto, to make software development more efficient and the products more effective. Since then it has come to be used increasingly outside software development, but essentially it is an approach for collaborative and efficient working in order to iteratively deliver products of value to the customer. More traditional methods such as the waterfall method typically deliver products all at once towards the end of the project.

The waterfall methodology has it's roots in industry and construction and was developed for building ships, bridges etc. For example, when constructing a house, waterfall would start with the plan being drawn up, agreed and fixed, then construction on the foundations would commence, followed sequentially by the walls, roofs, floors etc. until at the last stages the house would be ready for use - the big bang.

All perfectly logical for physical projects, but in software development where the code is relatively cheap and quick to produce, this has some drawbacks. In particular it requires that the customer knows what is needed upfront. Additionally there is a delay between initiation and delivery, during which time the business case may have evolved and there is less flexibility to adapt to changes or what has been learned.

An agile approach would be to identify what was most valuable to the customer, focus on that and deliver it as early as possible. In the example of the house, perhaps the customer would pick out the kitchen as the most valuable room and the agile team would deliver that first. Iteratively rooms would be added based on the relative value to the customer. Then finally, perhaps the foundations would be added!!

No one framework is foolproof and this example highlights one of the weaknesses of agile and the comparative strengths of waterfall - dependencies. The agile approach is not best suited for such physical projects but can be employed effectively where testing, iterations and refinement are key, such as conceptual or scientific projects, data analysis or for software development.

A more suitable example for agile would be the development of a website. Let us say that the customer has identified that the most valuable features are the ability to display products and capture orders. These fully working features would be developed and delivered first allowing the customer to start using them. Iterative development would continue until all the features have been delivered or the customer decides that they have sufficient functionality and the project stopped. Studies have identified that typically a mere 20% of a software's functionality is used frequently. Consider how often you have used MS PowerPoint and when was the last time you used the animation or sound features?

a) Agile Values

The Agile Manifesto defined 4 values listed in the diagram below. It is important to note that agile does not state that the values on the right hand side are unimportant, it states that the values on the left hand side are to be emphasised. For example planning in agile remains important though emphasis is given to short term planning over long term planning, which is time consuming and often inaccurate.

"Being agile" is not a valid excuse for not doing something. For example, value 2 states "working software over comprehensive documentation", which is quite different to "working software NOT comprehensive documentation". I have yet to work on a project where no documentation was required, especially when it can be argued that a project can only be considered as delivered once audit has been passed.

b) Agile Principles

Accompanying the 4 values are 12 principles which are effectively ways of implementing the values. I have tried to group the principles together and link them to a corresponding value. The mapping is not exact and argument can be made to organize them slightly differently.

i) Individuals and Interactions

The key concepts are that of building the right team including business representatives, empowering them, providing them the right support and trusting them to deliver.

ii) Working Software

iii) Customer Collaboration

iv) Responding to Change

2) Agile Frameworks

Note that both the values and the principles are deliberately generic and not prescriptive. There is no mention of roles, terminology, meetings styles etc. Agile itself is not a framework but based on its values and principles a number of different agile frameworks or methodologies have been developed. These frameworks introduce the terminology, roles etc. The following sections provides a high level overview of some of the most common frameworks.

a) Scrum

Scrum was introduced in the early 1990s, pre-dating the Agile Manifesto. It has introduced many widely used terms and roles. As it has only a small number of roles and outputs, it is one of the most lightweight and flexible frameworks. It is described as an empirical process control framework i.e. the scrum teams inspect and adapts the product quickly. Typically a scrum team consists of a Scrum Master and generalists who work collectively in Sprints (usually 2 week cycles) to produce working software in a priority order.

At the start, the Product Backlog of priority deliverables is identified with the business representative or Product Owner. From the product backlog a set of deliverables for the next sprint, the Sprint Backlog, is determined. Short daily Stand-up Meetings, typically 15 minutes, allows the team to identify roadblocks to be dealt with. At the end of each sprint, the working software is demonstrated in a Sprint Review Meeting and typically a Retrospective is held by the team to identify how they can improve.

Scrum is the most commonly used framework, though in my own experience few actually use scrum in a pure form and that a hybrid waterfall-scrum method is actually used. The waterfall component typically has been included to satisfy the need to provide status reports, alignment to wider standards, to establish dependencies or ensure strategic goals are met.

b) Extreme Programming ("XP")

Extreme programming or "XP" is another framework that pre-dates the Agile Manifesto being developed in the late 1990's though some of the practices associated with it go back to NASA's Project Mercury in the 1960's. As its name suggests, XP is focused on software development.

One key concept of XP that is popular in agile teams is Agile Planning where customer's provide User Stories that describe in non-technical terms a software feature with its value. XP teams will also include Continuous Integration of code rather than wait towards the end of the project and will also Refactor the Software i.e. continuously improving the code rather than having long development phases with a big-bang. Like with scrum this allows the customer to quickly review and refine the software and reduces the risk as issues are identified more quickly. These teams will typically also employ Test Driven Development ("TDD"), where the tests are written before the software is developed. This helps developers form how the software should work before development commences and also helps prevents tests being defined on how the software has been developed.

c) Kanban

Kanban is framework popular with teams that are continuously moving work items through a series of steps until complete, such as customer service teams. Its does not have the prescribed set of meetings or fixed length work periods. Instead it works on the basis that only a set number of work items can be worked on at any point.

Kanban traces its roots back to lean and Just-in-time (JIT) manufacturing and scheduling processes of the 1940's and 1960's. One aspect of Kanban that has been widely adopted is the Kanban board which helps to easily visualise the work priority and progress. The Kanban board, in its leanest form, is a board divided into vertical swim lanes representing "Work To Do", "Work in Progress" and "Work Done". Work Items are listed from top to bottom in a priority order. Items of work are selected from the top down by the team members and then progressed. In the diagram below, I have tried to demonstrate how the the Kanban board can be linked to user stories.

I have found that the Kanban board also works well in management or steering committee reporting. The RAG status can also be included to provide a easily understood visual guide to the state of the project.

3) The Agile Mindset

Given the number of different frameworks being used, no one framework is best and the circumstances of a project or organization sets suitability. Irrespective of the framework the set of attitudes supporting the agile working environment needs to be established - the agile mindset.

Organisations will need to move from hierarchal control structures where the manager provides the tasks and direction to that of networked self-organized teams. Teams will need to work less in silos to being more integrated with fewer hand-offs. The mindset of providing "oversight" or "approval" at the latter stages of the project will have to make way to one being much more hands-on (attending meetings or requesting status updates does not qualify).

The largest and most rapidly growing companies have already adopted this mindset and not just limited to the way that they run software projects. The way that business projects and the businesses itself operates have been transformed. Whilst these companies have also invested heavily in technology, it is not the technology that is the differentiating factor. Take the example of General Electric which invested heavily in software though suffered a "slow pace of change" requiring its board to replace the CEO and top management team.

I have found that Agile is quick to adopt though difficult to master and the adoption of Agile should be treated like an iterative project itself; with real world experience, collaboration, iterations, learning, adapting, refining, changing, re-refining. Above all I feel that adopting the buzzwords without this mindset is much like building a house, starting with the kitchen.

Author

Murali Thillaivasan is a computer scientist and professional Project Manager with over 10 years consulting experience in private banking, wealth management and technology.