Management

The software factory has firm ideas about what works for software development and the management of projects. The general ideas follow on from Tom Gilb, Eliyahu Goldratt and David Anderson. So, in other words, incremental iterative development that watches for bottlnecks, which need to be resolved in order to increase the throughput of delivered software applications. The key while doing this is to focus on delivering solutions that the client values and avoiding building artefacts which will not be needed.

These general concepts are embodied in evolutionary project management, theories of constraint, and agile and lean software development. These all flow back to the work of W. Edwards Deming on systems work and process control. In other words, you need to work towards specific goals to help the client run a better business, and measure your attainment of those goals. In addition you need to monitor your own work to see where you can improve your own processes in order to do more with what you have to hand.

Background Reading

You can find a number of books to help you with your project at the SafariOnline pages, and ScienceDirect as long as you put the University proxy in your web browser, or access the pages from the university. The link in the top left for 'library' shows you the list of books fully available to you as a student. If you find another one, that is in the system, but not on our list, please let your project leader, or me know, and we'll see about adding it it to the list. You can also get a general perspective on the project management and software engineering aspects of web applications from the Software Engineering for Internet Applications book.

SafariOnline has books about project management, coding in Java, servlets, JSPs, Tomcat, coding in Ruby/Rails, XML, REST, etc. And also includes a variety of articles too. Also, don't forget to just use Google on the topic, and to check the QML for books, which might be there physically, as well as electronic editions.

Rocks Into Gold

Before you read anything else though, you must take 30-40 minutes and read this:

Rocks Into Gold - Helping Programmers THRIVE through the Credit Crunch - by Clarke Ching

View more presentations from cching.

Rocks into Gold by Clarke Ching explains why we're doing incremental delivery on our projects. This little classic in the making explains more simply than any other 'why' all projects should use incremental delivery for their software. This is short and to the point, and understood by many as you can see if you flip through the comments.

Software Development Life Cycle

There are two aspects to the software development life cycle (SDLC) we need to worry about. The first is the project managment aspect (PM), and the second is the software development aspect. The two are often used confusingly, so remember to consider one as 'how' we build it (the SDLC) and the other as 'what' we build and how we know when we're done (the PM) part. We need to remember to ensure that we have useful PM framework in place to ensure that the SDLC part flows smoothly and is not diverted from the goals set by the client.

Several key aspects of these two aspects are that the PM part should determine what should be built, along with a ranking of importance for the parts so that we can build some of it sooner rather than all of it later. This will enable more useful feedback about the application from those using it, and mean the firm has a quicker return on their time invested in the application. This also has implications for the SDLC part of the process.

The SDLC determines the specific development of the application. This means capturing requirments as we go along at each stage of the development, and by doing so using minimal written documentation. There is no point writing lots if you know it will change later. Instead it is better to write simple cards, and talk to the client to understand and detail what is need in a conversation between the developer and client. We also ensure that we have a release sooner rather than later by focusing on one task at a time per developer as a means to limit the flow of work, which counterintuitively, means more is produced faster.

The result of this process is a mixture of project management aspects from evo and lean, along with software development ideas from agile development. Key authors would be Gilb (evo), Anderson (lean), and Cohn (agile), who are all noted in detail below.

Lean and Kanban Development

Lean aims to limit work in progress and to make decisions as late as possible in the planning process. In all things we aim to ensure that the work we do creates value for the client. If it doesn't create value, then it is deemed 'waste'. Waste is work we did, which is rejected by the client as not being up to standard and needs to be re-worked (bugs removed), or was not needed. Waste also includes work that the client asked for, but which was later rejected as it was not done as they thought it should be. Waste in other words, come about from a lack of communication.

Lean limits work in progress by only letting a fixed number of tasks be in the pipeline of work at any one stage, which is shown on a kanban board. This means that people are not overworked, and we can have a higher throughput of finished components than if everyone worked on more items. The result is that everyone can swarm onto one item to ensure it is completed as soon as possible and then the team can move onto the next item to be done in the iteration.
Key authors in Lean and Kanban are David Anderson, Tom and Mary Poppendieck and you can get a free minibook on using Kanban and Scrum from InfoQ.

We'll use the notion of a Kanban board to limit the work we do at each stage. In order to decide which we to do in each stage we'll use Evo.

Evo Development

Evo is associated with Tom Gilb, who has been doing incremental iterative development since the sixties. He is also the acknowledged influence on most of the agile thought leaders. You can find Gilb's Competitive Engineering available to you at http://www.sciencedirect.com/. If you're accessing this off campus, then you'll need to have your browser use the university proxy. He has been lately joined by his son Kai, who has been bringing the main thoughts of him and his father into line in the (Evo) Evolutionary Project Management book, which is available as a pdf. You can also find a short overview of the steps involved in running an Evo project in Ryan Shriver's Measurable Value with Agile in February 2009 Overload magazine. Shriver also wrote some useful material on determining the 'real release' requirements ten basic principles of Evo are found at NR Malotaux's site, which also has a number of useful presentations and project timeline guides.

Evo project steps

The big picture of Evo project management -chapter 10 from Competitive Engineering by Gilb
The steps below come from Shriver's article noted above as a simple way to keep track of 'what's happening next'.

1. Identify Stakeholders, objectives, and resources

Who are the stakeholders?
What are their objectives?
What resources are available?

2. Quantify the objectives to clarify requirements

Scale: what to measure (units) - chapter 5 from Competitive Engineering by Gilb
Meter: how to measure (method)

3. Identify targets, constraints and benchmarks

Targets: meet these for success
Constraints: meet these for failure
Benchmarks: current levels of achievement
Qualifiers: [when conditions apply]
Sources: <- where did info come from?

4. Determine minimum release requirements

What is the bare minimum that is needed for the initial release? The faster we get something going, the sooner we get feedback to incorporate into later releases. See Shriver 'real release'.

5. Brainstorm design ideas

Design idea: potential solution that meets one or more stakeholder objectives

6. Select the next best design

Impact estimation table (IMT): provides matrix showing how well each proposed solution meets objectives
See Shriver’s spreadsheet on business value to use as a template
Impact Estimation for business value is basic, while agile engineering breaks down options further

7. Agile integration

Agile process: use preferred agile steps for the iteration being sure to align quality requirements alongside the functional ones
See the agile steps (see also Shriver ‘smart decisions’ on agile + evo)

8. Measure value

Update IMT and repeat from step 5
Write one page summary about progress and estimates for next cycle.

Lean and Kanban projects

Lean follows on from evo insofar as both are based on the work of W Edwards Deming, who influenced the Toyota production system. Part of this also influenced Eliyahu Goldratt, who developed the 'theory of constraints' (TOC). This in turn provides insight into lean production and lean software development aspects as discussed by David Anderson in his various writtings and presentations. Kanban oversimplified provides a long, but useful, explanation of its' principles and processes. There is a longer 'scrum versus kanban' book that you can download from InfoQ.

We can also make sure we're keeping track of business value for the project by using A3 problem solving templates, which drive at the same sort of issues raised by Gilb and Goldratt.

Agile Development

You can find out more about agile software development from the book Agile Estimating and Development by Mike Cohn.You can also find a briefer earlier version of the book, but with more about user stories under the title User Stories Applied.You will also find a lot of other resources available at Mike's Mountain Goat Software site. Dig in and look around.

Agile Steps in project (fit into step 7 of evo steps)

1. Obtain objectives

Schedule constraint
Budget constraint
Quality constraint
XP Game and Business value game go through almost all parts of the process except progress monitoring.
resort brochure could also do this with scrum also extreme hour game

2. Gather user stories

User stories: one per sheet
Size stories agreed by all

3. Select stories for iteration

Iteration is as much as can be done in selected time (1-2 weeks)
Determine acceptance criteria for stories
Prioritised stories for iteration – cost, risk, value
Offing Off-site customer game

4. Break down stories to tasks

Each story has associated tasks
Buffer plan if necessary knowing can add stories in if time.

5. Start iteration.

One task per developer.
Coordinate during stand-up and track progress with burndown charts, and updating stories and tasks.

6. Add stories/tasks as uncovered to the backlog.

New stories/tasks may be revealed as discuss stories with users.

TDD pair programming game http://www.tastycupcakes.com/index.php?title=Pair_programming_game and see this blog entry about orgianal game
Resort building game http://www.tastycupcakes.com/index.php?title=Resort_Brochure
Offing off-site customer http://jamesshore.com/Presentations/OffingTheOffsiteCustomer.html
Extreme hour game http://c2.com/cgi/wiki?ExtremeHour or it’s variation
XP Lego Game to build animals in teams http://www.magpiebrain.com/presentations/the-lego-xp-game/ and notes from a participant
http://csis.pace.edu/~bergin/xp/planninggame.html
TOC 'the goal' game with variations http://www.vancouver.wsu.edu/fac/holt/em530/Docs/DiceGames.htm and some more recent variations http://aspsp.blogspot.com/2009/05/24th-march-2009-theory-of-constraints.html
Agile Coach has lots on TOC and agile games http://www.agilecoach.net/