Lean Agile Course

Introduction to Lean Agile

• Embrace change and steal a march on your competitors
• Discover the exciting adaptive approach to management
•  Become the Agile champion for your organisation

Business systems do not always end up the way that we first plan them. Requirements can change to accommodate a new strategy, a new target or a new competitor. In these circumstances, conventional business management methods often struggle and a different approach is required.

Agile business management is a series of concepts and processes for the day-to-day
management of an organization. As an Agile manager, you need to understand, embody and encourage these concepts. By embracing and shaping change within your organization you can take advantage of new opportunities and outperform your competition.

Using a combination of first-hand research and in-depth case studies, Directing the Agile Organisation offers a fresh approach to business management, applying Agile processes pioneered In the IT and manufacturing industries.

What does Agile mean?

‘On two occasions I have been asked, “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” […] I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.’
Charles Babbage, 1864.

The Agile Manifesto

The “Agile Software Development Manifesto” was developed in February 2001, by representatives from many of the fledgling “agile” processes such as Scrum, DSDM, and XP. The manifesto is a set of 4 values and 12 principles that describe “What is meant by Agile”.

The Agile Values

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support
   they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
   development team is a face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Lean Principles

In addition to the principles from the Agile manifesto, there are 7 principles defined for lean development.

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

Agile Methods

The term Agile actually refers to a concept, not a specific methodology. There are many, and sometimes conflicting, methods that can be used under the Agile umbrella. These include;

•  Agile Unified Process,
•  Behaviour Driven Development (BDD),
• Crystal Clear,
•  Dynamic Systems Development Method (DSDM),
• Extreme Programming (XP)
•  Feature Driven Development (FDD),
•  Kanban
•  Lean Development,
•  Rapid Application Development (RAD),
•  IBM – Rational Unified Process (RUP),
•  Scrum,
•  Test Driven Development (TDD),

 

Key Points

All of the above methods have four key points in common:

1. Iterative design process
2. Continuous stakeholder engagement
3. Aims for quality and reliable systems
4. Short development cycles (up to a month) allows to the regular delivery of improvements

This shows that an agile approach is appropriate in contexts where the outcomes are not known (or can’t be known) in advance and where the delivery of the outcomes cannot be fully controlled. This is especially relevant in business intelligence environments given the natural ambiguity around reporting requirements, data quality and information management.

The following figures1 is an excellent example of the differences between traditional (or phased) development vs. the agile approach of iterative development.

1. Images with thanks from Jeff Patton: http://www.agileproductdesign.com/

The origin of Lean

Lean Manufacturing often called lean production, or just ‘Lean’, is a streamlined manufacturing and production technique, as well as a philosophy that aims to reduce production costs, by eliminating all ‘wasteful’ processes. Put another way, Lean focuses on ‘getting the right things to the right place, at the right time, in the right quantity, to achieve perfect workflow’.

Lean Manufacturing provides a set of techniques to identify and eliminate, waste which, in turn, improves quality, and reduces overall production time and cost. In addition, Lean Manufacturing also improves the ‘flow’ of production through the system. These techniques include:

• Value stream mapping: Analysing and planning the flow of materials and information that is required in the production process.
• 5S: This is an approach to quality and continuous improvement. The five S’s are: Sort (to clean and organise the work area), Set in Order (arrange the work area to ensure easy identification and accessibility), Shine (mess prevention and regular maintenance of the work area), Standardise (create a consistent approach for carrying out production processes), Sustain (maintain the previous four S’s through discipline and commitment).
• Kanban: This will be covered later.
• Fail-proofing: Prevent human errors before they occur.
• Production leveling: Ensure that each step in the production process delivers at a constant rate so that subsequent steps can also deliver at a constant rate. No step in the production process should produce goods at a faster rate than subsequent steps or consumer goods at a slower rate than preceding steps.

Finally, Lean Manufacturing emphasizes Kaizen (改善) or Continuous Improvement; the ongoing, incremental and regular technique of improving all processes, products and functions relating to production, resources, organizational management, and the supply chain.

It should be noted at this point that many of the terms in Lean Manufacturing have been translated from the original Japanese. As such, they often lose the context, or secondary meanings, of the term. Where possible, this context is described throughout this course.

Understanding ‘waste’

The techniques and frameworks within Agile & Lean aim to increase development efficiency, by eliminating all ‘wasteful’ processes. Drawing on the successful concepts from the Lean manufacturing frameworks, we can define 3 major forms of waste.

• Mura (Unevenness): Mura exists where there is a variation in workflow, leading to unbalanced situations, most commonly where workflow steps are inconsistent,
  unbalanced, or without standard procedures.
• Muri (Overburden): Muri exists where management expects unreasonable effort from personnel, material or equipment, most commonly resulting from unrealistic expectations and poor planning.
•  Muda (Waste): Muda is any step in the production workflow that does not add direct value to the customer. The original seven wastes, as defined by the Toyota Production

System (TPS), were:

1. Transport,
2. Inventory,
3. Motion (moving more than is required),
4. Waiting,
5. Overproduction,
6. Over Processing (from poor design), and
7. Defects (the effort involved in inspecting for, and fixing, defects).

Additional and new wastes are not meeting customer demand, and are a waste of unused human talent. There is further differentiation between Type 1 (necessary waste, e.g. government regulations) and Type 2 (unnecessary waste).

Critical Success Factors (CSFs)

The successful application of an agile methodology depends on the relative maturity of an organization in relation to Customer Engagement, Staff Resources, Technology, and Processes. These measures are defined as follows:

• Customer Engagement – Customer Representatives involved in teams’ daily activities, defines user stories, drives the prioritization of stories, and has decision-making delegation of authority.
• Staff – have experience in an agile method, are skilled in the Standard OperatingEnvironment (SOE) toolsets, have an understanding of the underlying data and technical infrastructure, and are conversant in the development, testing, and configuration and release procedures.
• Technology – a stable and well-documented technology stack, with clearly defined ownership and service levels, providing discreet development, testing and release environments that are sized and supported for the delivery of projects, and controlled
  through rigorous configuration and release management.
• Processes – business processes exist for all domains, with cross stream
  interdependencies defined and service levels agreed, and clear business ownership and delegations of authority identified.

Common Misconceptions

Being a generic term, Agile means different things to different people. Therefore, before we go much further, I should clarify some of the more common misconceptions surrounding Agile.

• Agile is ad hoc, with no process control: First of all, Agile isn’t a lack of process. Agile provides a range of formal processes, and methods, to inform work processes, customer engagement and management models. Conversely, Agile isn’t about blindly following the prescribed ‘agile’ methods and processes. Agile is about using your common sense to apply processes, as determined by the current situation, and shaped by the agile philosophy.

• Agile is faster and/or cheaper: Agile isn’t significantly faster, or cheaper than alternative frameworks. Put another way, in most cases, you can’t get significantly more effort out of your teams by moving to an agile approach. While there is an overall efficiency gain when utilizing agile methods, well-managed Agile and non-Agile teams will deliver products and services in approximately the same time and effort.

• Agile teams do not plan their work or write documentation: Agile is not an excuse to avoid appropriate planning or writing documentation. It is an on-demand, or Just-InTime, approach that encourages continuous planning and documentation, but only when needed for specific stories. This allows customers and teams to determine if the planning, or document, adds value to the process or product. It creates an opportunity to emphasize valuable documents, and eliminate anything that isn’t useful.

• An Agile project never ends: While this may be true in some situations, the benefit of Agile is that work will continue while the customer continues to gain business value, and that value is worth more than the cost of developing it. Most projects, in any industry, have a point of diminishing returns. This is the ideal time for an agile project to end.

• Agile only works for small organizations: Agile works for projects, teams and organizations of any size, not just small projects. That is not to say that it will work for all organizations, but the size is rarely a factor. Large and complex projects and organisations are often excellent candidates for Agile transformation, where it is difficult or impossible, to know all your customer’s requirements in advance.

• Without upfront planning, Agile is wasteful: This assumes that your customer knows the detail of all of their stories in advance. If this is true, then, by all means, undertake comprehensive upfront planning. However, in reality, this is rare and usually leads to the greater ‘waste’ of having undertaken design and development work that was ultimately unnecessary. Agile Business Management encourages minimal upfront planning, ensuring everyone is working towards the same goal and reduces the risk of miscommunication.

• Finally, Agile is not the solution to all your problems. It is a change in approach and culture that comes with its own set of benefits and issues.

An overview of Kanban as a software development method

The original concepts of Kanban (カンバン) were developed in the 1940s and 50s by Taiichi Ohno2 as part of the Toyota Production System, as a mechanism to control Just-In-Time (JIT) production and manufacturing processes. Kanban, which approximately translates as ‘signboard’, is described as a ‘visual process management system that tells what to produce when to produce it, and how much to produce’. The modern Kanban method, as formulated by David J Anderson in 20073, is an adaption of the original JIT approach, with an emphasis on staff welfare and continuous process improvement practices. This is ultimately a strategy that strives to improve a business return on investment by reducing waiting inventory and associated carrying costs.

At its simplest, each prioritized task (or card) on a Kanban Board passes through a visualization of the team’s process, or workflow, as they happen. Each primary activity in the team’s workflow is visualized as columns on the Kanban Board, usually starting at task definition, and finishing with delivery to the customer. Of course, being Agile, these cards and activities are visible to all participants, including the customer.

While a Kanban workflow can become very complex, the simplest visualization of workflow has only 4 different states which a task would progress through during its lifecycle. These states are:

1. Backlog – tasks that are waiting to be worked on
2. In Progress – currently being developed by a team member
3. Testing – undergoing integration, system or UAT testing
4. Done – complete and ready to be demonstrated and/or deployed

To identify, and control, bottlenecks and process limitations, each workflow state (or column) has a limit, called a WIP, or Work In Progress Limit, to the number of currently active tasks. This allows managers and team members to regularly monitor, and measure, the flow of
work.

In total, there are 6 core elements to Kanban:

1. Visualize (Kanban / Card Wall)
2. Limit WIP
3. Manage Flow (and reduce bottlenecks)
4. Make Policies Explicit
5. Feedback Loops
6. Improve Collaboratively

Scrum overview

Scrum is described as a ‘framework within which you can employ various processes and techniques’, rather than a process, or a technique, for building products. The Scrum framework is primarily team-based and defines associated roles, events, artifacts and rules. The three primary roles within the Scrum framework are:

 The three primary roles within the Scrum framework are:

1. The product owner who represents the stakeholders,
2. The scrum master who manages the team and the Scrum process
3. The team, about 7 people, who develop the software.

Each project is delivered in a highly flexible and iterative manner where at the end of every iteration of work there is a tangible deliverable to the business. This can be seen in the following diagram.

beginning of an iteration, features to be developed during the iteration are decided during the iteration planning meeting. At the end of the iteration are another 2 meetings, the iteration review and iteration retrospective where the team reviews the product and demonstrates the use of the software, as well as reflect on, and improve, the iteration process itself.

After the iteration is complete, the next set of user stories is selected from the Project Backlog and the process begins again. Burn rate is monitored to determine when funding will be exhausted.

Test Driven Development (TDD) overview

Test-driven development is a development methodology that requires developers to create automated tests before writing the code or function itself. If the tests pass, then the code is displaying correct behavior. These tests should be run automatically using one of the xUnit applications.

There are 5 steps to TDD:

1. Create a test
2. Add the test to the test catalog
3. Write the code
4. Run the tests (all of them)
5. Clean up the code as required. (Refactor)

Extreme Programming (XP) overview

Extreme programming (XP) is an agile development methodology, intended to accept and respond to changing customer requirements.

XP describes four basic activities within the software development process:

1. Writing the software
2. Testing the software, regularly and automatically
3. Listening and understanding the customer
4. Designing, or refactoring, an application framework to reduce unnecessarily
   dependencies between features. XP also includes development methodologies, such as:
   1. Pair programming, with two developers working together
   2. Common code standards (documentation, naming conventions, whitespace)
   3. An understandable system metaphor, where all classes and functions names should be understandable.