agile development practices

View Github Repository Open presentation in a new window

mragab

See all presentation from mragab

agile development practices

0 1

amecse

On Github mragab / amecse

agile development practices

for sustainable software development

by Ibrahim El-Etr & Mohamed Ragab
Orange Labs Cairo

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

Ibrahim is currently the Head of Program Management in Orange Labs Cairo, and a MBA student in the German University in Cairo. Ibrahim joined Orange Labs as the Head of Software Development in 2006. Ibrahim has 8 years of solid management experience, leading several teams to deliver several portfolios of software products to market. He has over 21 years of software development experience associated with highly diversified portfolio of international companies in different culture environments such as Orange, Telepin, Airwide solutions, Mitel networks, Nortel networks, and Newbridge (Alcatel Lucent). He spent the first 15 years of his career working for start up companies including owning his own business. Entrepreneurship is part of his DNA and he brings that outlook and method of work to every team he works with. Mohamed Ragab is currently the Head of Technology, and an Agile Development Coach in Orange Labs Cairo. He joined Orange Labs as a Senior Software and Service Architect in 2009. Mohamed has more than 15 years of experience building software systems in a wide range of industrial domains, in small local companies as well as large multi-national organizations. Mohamed has experience delivering projects with small collocated teams of a few developers to large distributed teams with a few hundred developers on board. Mohamed's expertise is in the Java platform, Open Source technology stacks, software development infrastructure and automation, and Agile Development Methodologies.

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!

State of affairs

in the young industry of software

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)

  2004 2006 2008 2010 2012 Successful 29% 35% 32% 37% 39% Failed 18% 19% 24% 21% 18% Challenged 53% 46% 44% 42% 43%

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
Standish report 2013 page 7 http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

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” by: Edward V. Berard

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 ...      

a manufacturing process
building construction

      no it's not

Software is like ...      

product design process
gardening!

    that's more like it

late project ..

What to do?
“adding manpower to a late software project makes it later”
Fred Brooks in his book The Mythical Man-Month 1975

Agile development methodologies

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
http://en.wikipedia.org/wiki/Lean_software_development http://www.poppendieck.com/ http://www.amazon.com/Lean-Software-Development-Agile-Toolkit-ebook/dp/B00HEL13HW/ Lean Software Development: An Agile Toolkit May 18, 2003 by Mary Poppendieck, Tom Poppendieck http://en.wikipedia.org/wiki/Lean_manufacturing Essentially, lean is centered on making obvious what adds value by reducing everything else. "lean manufacturing." Taiichi Ohno, and Eiji Toyoda developed the system between 1948 and 1975

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
Deliver as fast as possible The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. Empower the team the managers tell the workers how to do their own job find good people and let them do their own job

Extreme Programming (xp)

A software-development discipline that organizes people to produce higher-quality software more productively
Extreme Programming Explained, by Kent Beck, 1999

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 documentationCustomer collaboration over contract negotiationResponding 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

from the trenches

Planning

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

management and engineering practice

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
  • Control Input
  • Compare actual Output against expected
  • Testing framework
  • Test Driven Development (TDD)
  • 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

TDD is a design tool

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
  • Project mangers: you can be a maker, no longer management overhead
  • 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

Wrapping up

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

questions

http://mragab.github.io/amecse

thank you

0