A Kanban System for Software Engineering

At QCON London 2008, David Anderson gave a talk about Kanban. David starts by mentioning he had some failures in institutionalizing agile changes and failing to scale it to a significant size. He then had success with Kanban. Kanban system allows for focus on quality, reduces or limits work in progress, balances demand against throughput, prioritizes.

David then describes a case study at Microsoft where a team was at CMMI level 5 and producing high quality software however they had a huge backlog and items constantly delyed. David shows how implementing Kanban helped this team improve productivity by 200%.

Instead of having an agile transition plan and force a team to use a particular agile process, David now advocates starting from where you are now and create a culture that encourages people to improve, teach them lean principles, teach them about waste and bottlenecks, and then have the team figure out on how to get better.

David then covers another case study at Corbis and describes Kanban in more details. Kanban can work with specialist teams of analysts, developers, testers, QA, etc. However, it puts a limit on the amount of items that each team can process. There are no iterations in Kanban. It is more of a continues flow with a release every 2 weeks, but the release content is bound and published only 5 days prior. Items that take longer than 2 weeks are just not released. Prioritization meetings are held every week (inputs and outputs are not in sync in a cycle). Whenever there is an empty slot, an item from the backlog is added. Prioritization and competition for an empty slot eventually evolves into collaboration. No estimation is done on individual items, with the effort to estimate turned back into increased productivity in analysis, coding, testing, etc. The Kanban white board gives visibility into process issues (transaction cost of releases, transfer though stages, bottlenecks, ragged flow). Daily stand up helps eliminate impediments affecting productivity and lead time. Kanban also allows for scaling standup meetings. Large teams can go through tickets on the board and ask if anyone knows of something impeding the progress of the ticket.

David summarizes that the Kanban method enabled:

1. Culture Change: trust, empowerment, collaborative team working and focused on quality.

2. Policy Changes: No estimating, late binding release scope, late binding prioritization

3. Regular delivery cadence: Releases become routine.

4. Cross functional collaboration

5. Self regulating process robust to gaming and abuse

6. Continuous improvement: Increase throughput, high quality, process continually evolving, kanban limits empirically adjusted.

7. Little Management Overhead: Little to no involvement in day to day

This presentation is available on InfoQ at  http://www.infoq.com/presentations/kanban-for-software

The Ethics of Error Prevention

Michael Feathers gave a talk at JAOO about the ethics of error prevention. He mentions that preventing errors in applications have many different solutions, but most of the time we only need to pick one or two. He then moves on and coves 5 techniques:

1. Abstraction: Use of object oriented languages and higher end languages.

2. Design by contract: document precondition and post-conditions. The clients of the routine are obligated to fulfill them.

3. Clean room engineering: discipline of annotating code that proves to yourself that the code you are writing is correct.

4. Test driven development: write a test for a new capability, compile, fix compile error, run test and see it fail, write code, run the test and see it pass, refactor as needed, repeat.

5. Pair programming/software inspections: Fagan inspection: planning, overview, preparation, meeting, rework (looping back to planning), follow-up

Michael wraps up by mentioning that each of these techniques forces us to focus on what we are doing and steers us away from complication. They each trigger contemplation. The craft of software development is not about languages or tools. It is about practices. Quality is in the intangibles.

This presentation is available on InfoQ at http://www.infoq.com/presentations/error-prevention-ethics

Refactoring Databases: Evolutionary Database Design

Pramod Sadalage gave a talk about refactoring databases. He starts by stating that business requirements change all the time and with agile practice we are getting better at embracing these changes, but that we must also get better at managing change at the database level. He then covers some recommendations to make database refactoring possible:

1. Version Control Database Assets: Having these in version control provides greater control over changes, couples databases and applications, integrate in version control instead of database.

2. Swap best practices: educate DBA about coding practices, educate developers about SQL, automate tasks (physical table deployment, usage statistics, schema verification, data migration verification)

3. Give everyone a sandbox: each developer has his own copy of the database. Have a script to create a database, create all the tables, views, etc, insert seed data and test data. Use dbdeploy tool.

4. Continues Integration: Since sql script is in version control, then it can also be part of continues integration. Migration scripts always get tested.

5. Scaffolding: The old and new schema work together until all apps have been migrated to use the new schema

6. Controlled Release: merge all deltas into release script, branch sql script with code

7. Assert Database Behavior: test the database behavior. Check for unique indexes, nulls, other constraints

This presentation is available on InfoQ at http://www.infoq.com/presentations/refactoring-databases