Software Engineering and Architecture

• Periodically take a look at what is and is not working
• Typically 15-30 minutes
• Done after every sprint
• Whole team participates
  • Scrum Master
  • Product owner
  • Team
  • Possibly customers an others

• Parameters
  • Daily
  • 15-minutes
  • Stand-up
• Not for problem solving
  • whole world is invited
  • Only team members, Scrum Master, Product Owner can talk
• Helps avoid other unnecessary meetings

Questions to be answered:

• What did you do yesterday?
• What will you do today?
• Is anything in your way?

• Burndown Chart doesnt decrese fast enough -> remove some backlog items from the srpint -> Scrum Master
• Burndown Chart decreases too fast -> add some backlog items to the sprint -> Scrum Master
• Team is doing stuff in the wrong order (bottom backlog before top backlog), and neglecting the top-priority items
• Too many unplanned items are killin gthe sprint (backlog does not decrease at all)

• Scrum provides the project delivery approach and aspects of XP  provide the engineering practices
• Scrum focuses on management and organization practices
• XP focuses mostly on actual programming practices
• They address different areas and complement each other
• Some overlapping practices:
  • Whole Team
  • Sit together
  • Stories
  • Planning game
• Srum - Project Delivery Approach
  • Incremental & Iterative - 4 week sprints delivering production quality code
  • Analyses, design, development, testing performed throughout iteration
  • Team design and architectural input
  • Self organizing cross-functional teams - including the customer
  • Minimal creation of "interim" documents - focus on code delivery
• XP - Engineering Practices
  • Continual Refactoring
  • Simplest solution that fulfills functional and non-functinoal requirements
  • Automated unit testing & Code Coverage checkin
  • Test driven development
  • Continuous integration
  • Peer Code reviews / pari Programming

• Test-driven development (TDD)
  • According to Kniberg, TDD is more important than both Scrum and XP
  • "Test-driven development means that you write an automated test, then you write just enough code to make that one test pass, then you refactor the code primarily to improve readabilty and remove duplication. Rinse and repeat."
  • TDD is hard. It takes a while for a programmer to get it
  • TDD has a profoundly positive effect on system design
• Incremental Design
  • This means keeping the design simple from start and continuoulsy improving it, rather than trying to get it all right from the start and then freezing it.
  • Contnuous design improvement is mostly an automatic side effect of doing TDD
• Contnuous Integration
  • This is extremely valuable and time-saving
  • It is the ultimate solutoin to the good old "hey but it works on my machine" issue
  • Every time somenone checks something in to the version control system the continuous build serer will wake up, build everything from scratch on a shared server, and run all the tests
• Collective code ownership
  • Teams with a high level of collective code ownership have proven to be very robust, for example their sprint doesn't die just because some key person is sick
  • Pair programming with frequent rotation of pairs automatically leads to a high level of collective code ownership
• Informative workspace
  • All teams have access to whiteboards and empty wall space
  • Use of taskboards as information radiators
• Coding standard
  • A coe standard is very useful, as long as you focus on the stuff that matters
  • Examples:
    • Never, ever, ever catch exceptions without logging the stack trace or rethrowing
    • Avoid abbreviations. Well-known abbreviations such as DAO are fine
• Sustainable pace /energized work
  • Many books on agile software development claim that extended overtime is counterproductive in software development
  • After some unwilling experimentation on this i can only agree wholeheartedly! Says Kniberg

• Estimating and planning are critical to the success of any software project
• Plans help us to know
  • Who works on the project during which period
  • Is the project on track to deliver the functionality the user needs?
  • When will you be done?

Agile teams ten in practice to produce plans at two levels: Create a coarse-grained long-term plan to know where the target is and a fine-grained short-term plan for the next week or month

Organizations demand estimates (budget, marketing campaigns, product release date, training internal users, and son on)

A Quet for Value: Planning is an attempt to find an optimal answer to the overall product development question: What should we build?

• A good iterative planning process:
  • Reduces risk
  • Reduces uncertainty
  • Supports better decision making
  • Establishes trust
  • Conveys information

• Planning can be agile, not plans!
  • Plans are documents or figures
  • Planning is an activity
• Agile planning shifts the emphasis from the plan to the planning
• Agile plans are often (and gladly) changed: During a project we learn new things like
  • The customer wants more of this feature or less of that feature
  • The application server is more complex than expected

• Estimating and planning are critical, yet are difficult and error prone
• Cone of uncerainty
• Overplanning and doing no planning are equally dangerous
• A good plan is one that is sufficently reliable that it can be used as the basis for making decisions about the product and the project
• Agile planning is focused more on the planning than on the creation of the plan, encourages change, results in plans that are easily changed, and is spread throughout the project

• Key idea: A project rapidly and reliably generates a flow of useful new capabilities and new knowledge
• New capabilities are delivered in the product
• New knowledge is used to make the product the best it can be
  • New product knowledge helps us know more about what the product should be 
  • New project knowledge is information about the team, the technologies in use, the risk and so on
• Failing to plan to aquire new knowledge leads to plans built on the assumption that we know everything necessary to create an accurate plan

• Planning becomes to a process of setting and revising goals that lead to a longer-term objective

• Every project is initiated with a set of objectives
• E.g. create the world's best software for the airline catering industry
• There will almost cerainly be additional objectives regarding schedule, budget and quality (agile teams typically prefer to treat quality as non-negotiable)
• These objectives are the customer's or product owner's conditions of satisfaction
• Example User Story: As a user, i want to be able to cancel a reservation
  • For an iteration, the product owner's conditions of satisfaction are typically the features she'd like developed next and som ehigh-level tests about each feature
  • In discussing this story with the product owner, the developers learn that her conditions of satisfaction for this story include that
    • A user who cancels more than 24 hours in advance gets a complete refund
    • A user who cancels less than 24 hours in advance is refunded all but a $25 cancellation fee
    • A cancellation code is displayed on the site and is emailed to the user

• Agile teams work together but include roles filled by specific individuals
  • Product owner, who is responsible for the product vision and for prioritizing features the team will work on
  • Customer, who is the person paying for the project
  • Users, developers, and managers are other roles on an agile projext
• Agile teams work in short, timeboxed iterations that deliver a working product by the end of each iteration
• Projects should be viewed as rapidly and reliably generating a flow of useful new capabilites and new knowledge, rather than just the execution of a series of steps
• 3 levels of planning (for an agile team): release, iteration and daily

• With story points or ideal days
• Story points are a relative measure of the complexity of a user story
• Velocity is a measure of a team's rate of progress per iteration
• The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team
• Ideal time and elapsed time are different

• Fine graned level: User Sotry -> in a sprint
  • Estimation scales:
    • Fibonacci: 1,2,3,5,8
    • 2^n: 1,2,4,8
• A large user story is called an epic
• A set of related user stories may be combined and treated as a single entity. This is referred to as a theme.
• Estimation scale for epics and themes: go on in the chosen estimation scale (fibonacci: 13,21,34,...)

• Example:
  • As a user, i want to be able to cancel a reservation
  • Template: As a/an <role>, i want to <goal> so that <benefit>
• Describes a WHO, WHAT and WHY scenario from user perspective
• Delivers value to the user
• Is small enough to be estimable
• Is accurate enough to be testable

• Story points are estimates of the overall size and complexity of the feature being implemented, not time
• Time = size (estimated in story points or ideal days / velocity)
• We should re-estimate only when we believe that a story's relative size has changed!

• Release planning is the process of creating a very high-level plan that covers a period longer than an iteration (three to nine month)
• Iterate until the release's conditions of satisfaction can best be met

• Before starting to plan a release, it is important to know the criteria by which the project will be evaluated as a success or a failure
• For most projexts, the ultimate scorecard is the amount of money saved or generated
• Leading indicators are usually: schedule, scope and resources
• The product owner condition of satisfactions are defined by a combination of schedule, scope and resource goals
• A date-driven project is one that must be released by a cerain date but for which the feature set is negotiable
• A feature-driven project is one for which we consider the completion of a set of features to be more important

• In order to do release planning the product owner need estimates, at least for all stories that are included in the contract
• This is cooperative effort between the product owner and the team - the team estimates, the product owner describes the items and answers questions
  • Let the team do the estimates -> Not the product owner!
  • Don't make the team spend too much time
  • Make sure the team undertands that the time estimates are crude estimates, not commitments
• A time estimaate is valuable if it turns out to be close to corret, less valuable if it turns out to be off by a factor 30%, and completely worhless if it doesn't have any connection to reality
•  

• Most agile teams work in iteration of two to four weeks
• Factors affecting the iteration length are:
  • The lengts of the release being worked on
  • The amount of uncertainty
  • The ease of getting feedback
  • How long priorities can remain unchanged
  • Willingness to go without feedback
  • The overhead of iterating
  • A feeling of urgency is maintained

• Use historical values
  • Is the technology, domain, team, product owner, tools etc. the same?
• Run an iteration (or two or three)
• Make a forecast
  • Estimate the number of hours that each person will be available to work on the project each day.
  • Detemine the total number of hours that will be spent on the project during the iteration
  • Arbitrarily and somehwat randomly select stories and expand them into their constituent tasks. Repeat until you have identified enough easks to fill the number of hours in the iteration
  • Convert the velocity determined in the prior step into a range. Our velocity is beween 36 and 44

• Most projects have either too little time or too many features. Product owner must prioritize the features she wants developed
• The product owner defines a list of acceptance thresholds which is a simple classification of what the importance levels in the product backlog actually mean in terms of the contract
• Example of acceptance threshold:
  • All items with importance >= 100 must be included in version 1.0 or else we'll be fined to death
  • All items with importance 50-99 should be included in version 1.0, but we might be able to get away with doing them in a quick follow-up release.
  • Items with importance 25-49 are reqired, but can be done in a follow-up release 1.1
  • Items with importance <25 are speculative and might never be needed at all

• After having completed the size estimation, user story prioritization, and so on
  • Feature-driven project: sum the estimates of all needed features and divide by the expected velocity = release date
  • Date-driven project: Multiply the number of iterations by expected velocity -> number o story points in release
• Updatin the release plan
  • Reality will not adapt itself to a plan, so it must be the other way around
  • Many projects update the release plan after each iteration
    • Look at the actual velocity. If it is very different from the estimated velocity, revise the estimated velocity for future sprints and update the release plan
    • If this puts you into trouble, the product owner may start negotiating eith the customer or start checking how he can reduce scope without breaking the contract

• Release date (three to nine months)
• Prioritized list of user stories with there estimates
• Number and length of iterations
• Product owner's conditions of satisfaction
• Estimated velocity
• Importand: the release plan is usually updated at the start of each iteration

• Unlike a realease plan, an iteration plan looks in more detail at the specific work of a single iteration
• Rather than the three to nine month horizon of a typical release plan, the iteration plan looks out no further than a single iteration
• The fairly large user stories of a release plan are decomposed into tasks on the iteratoin plan
• Each task is estimated in terms of the number of ideal hours the task will take to complete

• Which features should be developed?
• Factors in Prioritization of the user Stories
• The financial value of havin gthe features
  • Amount of Money earned or saved
    • Prioritze on business value: How much money will the organization make or save by having the new feature
• The cost of developint (and supporting the new features
  • How many sotry points
    • Natuarally the cost of a feature is a huge deteminant in the overall priority of a feature
    • An important, yet often overlooked, aspect of cost is that the cost can change over time
    • Do a rough conversion of story points or ideal days into money
• The amount and significance of learning and new knowledge created by developing the features
  • On many projects, much of the overall effort is spent in the puruit of new knowledge
  • It is important that this effort is acknowledged and considered fundamental to the project: At the start of aproject we never know everything that we'll need to know by the end of the project
• The amount of risk removed by developing the features
  • Schedule, Cost and fuctionality risk
    • Almost all projects contain tremendous amounts of risk
    • For our purposes, a risk is anything that has not yet happened but might and that would jeopardize or limit the success of the project
    • Do always the high risk features which contain high-value first and work then on to the features with low risk and low value (the risk-value relationship matrix)

• Because there is rarely enough time to do everything, the product owner niids to prioritize what is worked on first
• There are four primry factors to be consideren when prioritizing:
  • The financial value of having the features
  • The cost of developing (and perhaps supporting) the new features
  • The amount and significance of learning and new knowledge created by developing the features
  • The amount of risk removed by developing the features
• These factors are combined by thinking first of the value and cost of the theme.
• Doing so sorts the themes into an initial order. Themes can then be moved forward or back in this order based on the other factors

A parking-lot chart shows how much of each theme has been completed

• 2 Surveys
  • It-Companies and
  • IT-Professionals
• Each survey divided into two main categories: Agile/ non-Agile