1. Making working software as a team
Agile Projects
Making working software as a team
Bruce Scharlau, University of Aberdeen, 2012

2. Projects have a life cycle
What are the parts of the life cycle for projects in general?
Bruce Scharlau, University of Aberdeen, 2012

3. Projects have a process model
Bruce Scharlau, University of Aberdeen, 2012

4. There are diverging views about software development
Big bang vs salami tactics Manufacturing vs product development
Bruce Scharlau, University of Aberdeen, 2012

5. Software projects often fail
Challenged means over budget, incomplete, late
Bruce Scharlau, University of Aberdeen, 2012

6. Lots of delay in software projects
The project due in 12 months will arrive after 22 months, bit late if it was for specific event
Bruce Scharlau, University of Aberdeen, 2012

7. Bruce Scharlau, University of Aberdeen, 2012
Delays cost money
Bruce Scharlau, University of Aberdeen, 2012

8. There are different methodologies used for software development
Bruce Scharlau, University of Aberdeen, 2012

9. It doesn’t have to be like that
Incremental and iterative delivery means ship part of application early and get feedback
Firm can use and learn, and refine ideas
Firm can start gaining income from product
Bruce Scharlau, University of Aberdeen, 2012

10. Important to do project right
Often it doesn’t work out correctly… lots of failure We need to build the project ‘right’ as well as ‘build the right project’ – balance to ensure build efficiently, and that build project business needs
Bruce Scharlau, University of Aberdeen, 2012

11. What communication is there in waterfall?
Bruce Scharlau, University of Aberdeen, 2012

12. Waterfall lacks sufficient communication
Documents produced at each stage of the process
Always moves forward, and client may not see anything until the end
Bruce Scharlau, University of Aberdeen, 2012

13. You follow regular workflow
5 days
All possible
features
Prioritized current work
Bruce Scharlau, University of Aberdeen, 2012

14. Communication friendly process models are preferred
Describe the types of features you’d expect to see in a communication friendly project process model
Bruce Scharlau, University of Aberdeen, 2012

15. The agile principles cover many aspects of communication
The manifesto has the basics These form twelve principles: how many are about communication?
Bruce Scharlau, University of Aberdeen, 2012

16. Ease of communication means common code base for team
Use source control with anyone on the team expected to work on any part of the code as required
Work in pairs whenever possible
THERE ARE NO HERO PROGRAMMERS
Bruce Scharlau, University of Aberdeen, 2012

17. Agile adds better value than traditional projects
Bruce Scharlau, University of Aberdeen, 2012

18. Agile provides better feedback
Bruce Scharlau, University of Aberdeen, 2012

19. You follow regular workflow
5 days
All possible
features
Prioritized current work
Bruce Scharlau, University of Aberdeen, 2012

20. Ease of communication provides many benefits
Makes it easier to discuss options
Makes it easier to decide later in the process
Means we don’t need to decide when we know little about the product
Bruce Scharlau, University of Aberdeen, 2012

21. Bruce Scharlau, University of Aberdeen, 2012
Knowing that can communicate when required allows decisions to be postponed
Why decide early on, when the client knows less about the product, when we can postpone the decision until later?
We don’t have to lock-in choices early, so why should we?
Bruce Scharlau, University of Aberdeen, 2012

22. Use your real options to procrastinate
deciding to do something is not the same committing yourself to an action
When you commit early, then you must know WHY you do so and what the costs will be
Go see lean procrastination blog
Bruce Scharlau, University of Aberdeen, 2012

23. Communication improves position in cone of uncertainty
Project estimates improve as we learn more about the project
Bruce Scharlau, University of Aberdeen, 2012

24. Seek short project feedback loops
Look for feedback from coding, integration, client, so that can make corrections as soon as possible
Bruce Scharlau, University of Aberdeen, 2012

25. Communication enables choice of project priorities
The customer knows what is required for their application and this will be revealed more with each iteration
Bruce Scharlau, University of Aberdeen, 2012

26. Stand up meetings aid communication
Daily meetings of all of the team in the morning to determine who’s did what yesterday, what they intend to do today, and what issues are holding them up, which need to be resolved
Short, meetings only: follow up as needed with longer individual meetings
Let people work on project if not needed for meeting
Bruce Scharlau, University of Aberdeen, 2012

27. Pair programming aids communication
Two people work together at ONE computer to program a feature, or task
One person types, while the other catches typos, suggests algorithms to make the code work, asks questions
This is proven to work better than two people working separately and joining code together later.
Bruce Scharlau, University of Aberdeen, 2012

28. TDD and BDD confirms that communication is ok
The client writes tests that the team use to confirm the program does what it should. These guide the team in development.
Use Cucumber to clarify with the client what is needed and then can use RSpec for more testing underneath
Bruce Scharlau, University of Aberdeen, 2012

29. Continuous integration is a form of communication
CI is the process of using a tool to download the group source code and building the project to see that it passes its tests and runs as expected. Assumes that everyone is submitting their code regularly to the group repository
Bruce Scharlau, University of Aberdeen, 2012

30. Use PDCA cycle for development
Bruce Scharlau, University of Aberdeen, 2012

31. Can also be seen as lean startup
Bruce Scharlau, University of Aberdeen, 2012

32. Follow the TDD principles
Bruce Scharlau, University of Aberdeen, 2012

33. Use red, green, refactor to code
Make it green, then make it clean
4. Refactor
1. Write a little test
Cycle time < 10 minutes
3. Get test to pass
2. Stub out code.
Watch test fail
Bruce Scharlau, University of Aberdeen, 2012

34. As <a user type> I’d like to <do x> because <reason>
Stories cover basic requirements and we supplement them with specifics
Bruce Scharlau, University of Aberdeen, 2012

35. User stories provide basic requirements

36. Stories are ranked by business priority and risk

37. Use burndown charts to measure progress

38. Evo process model provides clear communication of objectives
Evo checks that the application has clear business objectives and determines how to measure them along an appropriate scale to know whether the application is helping to meet desired organisation goals.
Bruce Scharlau, University of Aberdeen, 2012

39. IET is precise means to communicate priorities
Design Ideas
Objectives #1 #2 #3
Total
Increase Market Share (12% -> 25%) 0%
Increase Monetary Donations ($2.4m -> $3.0m)
Increase Time Donations (2,400 hrs -> 3,200 hrs)
Total Impact
Costs (thousands)
Hardware / Software $1 $3
Development Effort $0
Total Costs
Performance to Cost Ratio
0.00
IET = Impact estimation table
Bruce Scharlau, University of Aberdeen, 2012

40. Lean and Kanban principles ensure we only do what is needed
Limit the work in progress
Delay decisions until last possible moment
Minimize disruption at hand-offs
Make workflow visible
Bruce Scharlau, University of Aberdeen, 2012

41. Limit work in progress (WIP)
Limit tasks per stage speeds up delivery
Only this many tasks per stage
Bruce Scharlau, University of Aberdeen, 2012

42. Too many tasks creates a queue of work
If you shuffle too many tasks for team members everything slows down, and
Feedback loops lengthen
Work takes longer
There is more work in progress
The quality goes down
Bruce Scharlau, University of Aberdeen, 2012

43. Minimize disruptions at hand-offs
Provide work for next stage in suitable format
For example, build to test to deploy hand-offs
Improve throughput by focusing on ‘ready’ before sprint
Improve throughput by focusing on ‘done’ after sprint
Bruce Scharlau, University of Aberdeen, 2012

44. Focus on preparation and completion
© Jeff Sutherland
Bruce Scharlau, University of Aberdeen, 2012

45. Make workflow visible with kanban
Seeing the work in hand aids issue resolution
Shows:
Stuck work
Priorities
Who’s busy
Problems
Bruce Scharlau, University of Aberdeen, 2012

46. We’ll use mixture of evo and lean
Use stories to gather minimum features
Use evo (IET) to determine implementation
Use kanban board to limit and see WIP
Automate testing and continuous build
Work in weekly iterations (stages)
Bruce Scharlau, University of Aberdeen, 2012

47. Build incrementally per greatest need at the time
Small slices of functionality with working software at end of cycle
Build with tests so you know it all works
Track progress to see what’s left
Provide release for people to use and offer feedback
Review your process regularly to improve it
Bruce Scharlau, University of Aberdeen, 2012