Speakers

• Ibrahim El-Etr
  Head of Program Management in Orange Labs Cairo
  Former head of Mobile Applications and Software Development in Orange Labs Cairo


• Mohamed Ragab
  Head of Technology, and an Agile Development Coach in Orange Labs Cairo

Agenda

• State of affairs
• Agile development methodologies
• From the trenches
• Wrapping up
• Discussion

Show of hands

• How do you relate yourself to software development?
  Testing
  Development
  Management
  Marketing
  Customer

Show of hands

• What is your Agile software development experience?
  Exploring
  Planning
  Started adoption
  Iterating
  Tried it, and it didn't work

Show of hands

• What is your current role in Agile software development?
  Product Owner
  Scrum Master
  Tester
  Developer
  Customer
  Not remotely related!

The Standish Group Report

"chaos report"

• The scope of software project failures.


• The major factors that cause software projects to fail.


• The key ingredients that can reduce project failures.

Report: shows (1995)

• 31.1% of projects will be cancelled before they ever get completed
• 52.7% of projects will cost 189% of their original estimates
• The lost opportunity costs are not measurable, but could easily be in the trillions of dollars
• The failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1.1 million per day.

report: projects' resolutions (2013)

Report: Factors of Success

• (20) Executive management support
• (15) User involvement
• (15) Optimization
• (13) Skilled resources
• (12) Project management expertise
• (10) Agile process
• (6) Clear business objectives
• (5) Emotional maturity
• (3) Execution
• (1) Tools and infrastructure

Report: features usage

• 20% of features are used often


• 30% of features and functions get used sometimes or infrequently


• 50% of features are hardly ever or never used.

the Bottleneck in software development

“Walking on water and developing software from a specification are easy if both are frozen”

Learning is the Bottleneck

What is the goal?

“Build the right thing, right”

• How do we know what "the right thing" is?
• Build it twice? ... too expensive
• Build one small piece at a time, and learn
• Iterate, and get feedback

Software is like ...      

      no it's not

Software is like ...      

    that's more like it

late project ..

“adding manpower to a late software project makes it later”

Lean software development (LSD)

• A translation of lean manufacturing and lean IT principles and practices


• Adapted from the Toyota Production System


• Lean Software Development: An Agile Toolkit, by Mary Poppendieck and Tom Poppendieck, 2003

Lean software development

Lean principles

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

Extreme Programming (xp)

A software-development discipline that organizes people to produce higher-quality software more productively

XP Practices ..

• Pair programming
• Planning game
• Test-driven development
• Continuous integration
• Refactoring
• Small releases
• Coding standard
• Collective code ownership
• Simple design
• Sustainable pace

XP Feedback Cycles ..

Agile Manifesto (2001)

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

Agile Manifesto Principles

• Early and continuous delivery of valuable software
• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Face-to-face conversation

Agile Manifesto Principles

• Working software is the primary measure of progress
• Sustainable development, maintain a constant pace indefinitely
• Continuous attention to technical excellence and good design
• Simplicity, maximizing the amount of work not done
• The best architectures, requirements, and designs emerge from self-organizing teams
• At regular intervals: reflect, then tune and adjust accordingly

Scrum

In 1995, Jeff Sutherland and Ken Schwaber jointly presented a paper describing the Scrum methodology at OOPSLA '95

In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum

Scrum

Scrum is an iterative and incremental agile software development framework for managing product development

Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements

Scrum

• Roles: Product Owner, Development Team, Scrum Master
• Events: Sprint, Sprint planning meeting, Daily scrum, Sprint review & retrospective, Backlog refinement meeting
• Artifacts: Product backlog, Sprint backlog, Product increment
• Progress: Burndown chart, Burnup chart
• Def. of Done: Backlog item, Sprint, Release
• Relative Sizing: Story points, using a rounded Fibonacci sequence

Scrum

Scrum

Kanban

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members

Kanban

• Map your current process
• Define the start and end points for the Kanban system
• Agree on initial work in progress (WIP) limits
• Agree on a process for prioritising and selecting items
• Agree on frequency of reviews
• Draw the board and start using
• Tune as you go

Kanban

Kanban

Planning

• Identify your pains
• Understand the main components of your organization
• Identify your goals
• Then put your strategy for the adoption process

Cost and Cycle time

• We are either writing new code, or modifying existing code


• As a software system grows in size: how does this affect maintenance cost and cycle time?


• Technical dept due to: taking shortcuts, learning, changing requirements

Refactoring

Refactoring is: improving the design of existing code, without changing its behaviour

• But, how can we be sure the behaviour doesn't change?


• Test the entire system after any refactoring .. cost & time

Testing

• Do the developers test the code before handing it to the testers?
• Why do the developers hand the code to the testers?
• Is there any duplication?
• How big is the feedback cycle? Seconds, Minutes, Hours, Days, Weeks, Months
• How does the development scale over time?
• How does this affect the cycle time?
• Cost of maintaining a software system

Automated Testing

We are in the business of automating stuff

• Input > Process > Output
• To test a Process
  1. Control Input
  2. Compare actual Output against expected
• Testing framework
• Test Driven Development (TDD)
  1. Red > Green > Refactor

TDD Practices

• Start from a Red test
• Don't stay Red more than 5 minutes
• A test should be simple, doesn't need a test to test the test
• Treat the test code as first class citizen: readability, maintainability, code reviews
• Trust the tests
• Testing is just sampling

TDD Practices

• Don't write redundant tests
• A full test run should not take more than 5 minutes
• Separate unit tests from integration tests (fast and slow)
• Unit Tests: fast, run in memory, repeatable (no randomness, no external dependencies)
• Integration Tests: slow, integrate with external dependencies
• If a test is failing, one should not work on anything else other than fixing it

Day to day workflow

• Checkout
• Run tests
• Green?: add a new feature (red, green, refactor)
• Checkin a working product increment with all tests green

Behaviour driven development

• Runnable software specification
• Specification with concrete examples
• Engage the Product Owner, the Tester, and the Developer(s)
• Can be used in a discussion with the customer
• A number of supporting software frameworks

BDD: Gherkin language

Scenario: Some determinable business situation
  Given some precondition
    And some other precondition
   When some action by the actor
    And some other action
    And yet another action
   Then some testable outcome is achieved
    And something else we can check happens too
            

Continuous integration

• A build server
• Build jobs are triggered upon any code modification in version control
• Runs the unit tests, integration tests, and BDD scenarios
• Runs the code through static analysis tools
• Provides feedback on the stability of the software after each build

Culture

• Culture eats strategy for lunch, but pain helps
• Is it leadership culture or Command and control culture
• Customer driven organization
• The barriers are in our minds, we change only if we try.
• Openness, willingness to listen to new ideas even if it contradicts with your experience and expertise
• Agile sounds weird, really!! well give it a try
• Then Mindset and the people

People will be in three categories

• Believers, choose your horses


• Non-believers, success by example, bring more to your side


• Not convinced but can give it a try, help them to experiment and join

Self organized team

• It is a joy, but it is not for free: more liability


• Self discipline


• Eliminating waste

Visibility

• Detect week signals, and act on them , the Frog will be broiled when you heat the water gradually.


• Agile development does not create the problem, it just makes it more visible

Ownership

• Obligation and Blame - Finger pointing culture


• Taking ownership

Giving-up control

• I am the technical lead, I always know how to do it better


• I am the manager, I love the command and control style, and I don't know any other way

Trust

• If you do not trust your team, agile is not for you


• Are they working enough?!


• How can we measure their productivity?!


• Can another team finish it is less time?!

Win together

• Single players versus team players


• One evaluation, share success and absorb the failure

Team Structure

• Cross functional teams
• Pick your scrum master
• Pick your product owner
• Deal with
  1. Project mangers: you can be a maker, no longer management overhead
  2. Team leads: you can be great scrum master, lead by example, use soft power

Learning

• Agile development without engineering practices is a dead end
• How to evolve your design, and code
• Refactoring is not a debt
• Develop for customer, build thin vertical slices, not easy to do

Contracting

• Agile contracts
• Customers are not interested, why?
• Minimal valuable product
• Applying agile development, even if it is a fixed contract
• Engage the customer

Who moved my cheese

• Can you stretch your comfort zone


• Incremental change, small but sustainable

self-organizing teams

• Start with one team, you need to plant the first tree, be realistic
• Team competence
• Engineering practices
• Work on conflict while applying the change
• Remove obstacles

Keep trying

• Invest time and means to achieve your targets


• 69% of the fuel is used while Rocket is in take off phase

there is no silver bullet ..

• There will be failures, use them well
• Make things visible
• There will be successes, use them well
• Agile development exposes the issues that are already there
• Can you handle the feedback

there is no silver bullet ..

• We succeed together, or we fail together
• If you don't trust your team, Agile is not for you
• Unlearn, learn, practice, and evolve
• Beware of: not enough training
• Be Agile adopting Agile