I’m back at CodeMash, and it’s Thursday morning. Just left the keynote, more on that later. Now sitting in first morning session, Iteration 0, a session on how to get prepared for an Agile project. Presentation is being given by a gentleman by the name of Ken Sipe.
Goal, many organizations have problems getting started wtih Agile, this presentation is oriented on how to overcome these problems. Ken is an old RUP guy, used to teach Rational courses, has a background doing XP programming, now a scrum master.
Review of different development process, first Waterfall. Waterfall seems to be corporate default. Iterative process is different in that provides for feedback. Corporate environments have problems with an iterative process, why, lack of control of process can’t predicate the future with as much certainty as they’d like. Corporate environments have trouble with communication. Iterations force process to happen before last minute, akin to term paper being done the night before it’s due. If have interim due dates, iterations, things go better, feedback is introduced earlier in the process. Agile is an iterative approach.
How do you know what the right size is for an iteration? Larger iterations mean less feedback, but iterations that are too small don’t allow enough time for anything to get done. Generally most organizations are probably erroring on the side of having iterations that are too large.
Iterations create trust with business. Business starts to realize you can respond to their needs because they see the results of their feedback sooner. Business also is asked to give feedback more often, again building trust. Also allows feedback about progress against plan early and reliably in project.
What agile is not, it’s not evolutionary based on iterative development, it does require documentation, it does require architecture, it is not cowboy development.
Pair programming, many organizations say they do agile but do not allow pair programming. If you aren’t pairing you aren’t really doing agile. Pairing is just in time code review. Should swap pairs regularly, disseminates information across team.
What is an iteration? Opening meeting. Standup meetings daily and a closing meeting. Standup meetings need to be no more than 15 minutes and stand up meeting must actually happen daily. Iteration size, change it around to find points of pain, fix pain points and go to iteration length that seems appropriate. The more you remove yourself from actual agile practices the more risk you introduce into the project.
Who should attend an opening meeting and what’s it for? Optimally an actual end user should be involved. It is optimal to have an actual end user on the project full time. Should have a BA, DBA’s, developers, architects and QA in the opening meeting. Purpose of the opening meeting is to define the vision of the user for the iteration, and to agree on acceptance criteria. Poorly defined acceptance criteria is a large reason for iteration failure. Should have a second follow up opening meeting to break out an allocate assignments.
What is the closing meeting for? Is iteration accepted by the user, define velocity of team. Need to resolve bug level to velocity. Is the team going too quickly to have a better looking velocity at the cost of quality? What kind of bugs are coming out of QA? Are we getting functional bugs? Functional bugs should be caught in dev process in Agile.
Stand up meeting, the Pig Rules. In a ham and egg breakfast the pig is fully committed, the chicked in simply involved. Only pigs are allowed to talk in a standup meeting.
Pre-Iteration 0, collect user storied. Need to estimate ROT, is project justified. Build your team. Create a release plan and iteration strategy. Team needs to be prepared for transparency. Pairing and code refactoring may happen to your code by someone else. Very transparent process
Team Building Phases
- Forming – Team meets very friendly
- Storming – Team forms as get to know each other has some conflict
- Norming – Team becomes settled works well together
- Performing – Team hits its stride
User Story gathering. Some projects have all the stories up front, some have enough to start and expect that others will be provided along the way. Either approach requires a business analyst.
Feature Slip versus Time Slip. In a RUP based approach you will slip dates to get features done if running late. Agile will slip features as iterations are done when they are done. Can extend agile projects and add iterations to handle feature slip.
Agile alignment with QA options. One option: Have BA and QA building test plans for next iteration while dev is working on current iteration. QA executes test plan for previous iteration during current iteration. Features are considered complete when dev has finished iterations. QA bugs will be added to future iterations. QA executes regression testing against iteration -2, while executing test plan against previous iteration and creating test plan for next iteration. Only dev is working on current iteration.
Second Option: have dev work on many iterations before QA starts executing tests against first iteration. Allows many things to change before QA gets involved, someone pointed out this seems very waterfall like, Ken agreed and said first approach is better. Both approaches based on production level code coming from development iterations because of TDD and pairing.
Coming to the end of session, getting into QA now. Someone asked for a definition of velocity, a fairly standard agile concept. Discussion on point allocation to stories and iterations and such. Question of team size, Ken indicated an 8 person team is very large, shouldn’t have bigger teams but more smaller teams or scrum of scrums.
Iteration 0 is heavily about automating everything possilbe before real iterations begin. Why automate? Predictablily, get frequent predictable feedack. Have to setup Version control in iteration 0. Build project should be setup in automated fashion so all things regarding release and such can be done with the push of button. Setup build server to handle moves. Setup build server to automate unit testing and code coverage. Setup automated repoting for management that will be used in iterations. Initial design concepts should be decided on in interation 0. Are you using and MVC model for presentation, logging models. Where it makes sense make these decisions in iteration 0. Ken advises to run iteration 0 like any other iteration. Have an opening meeting, stand up meetings and a closing meeting. In iteration 0 the user is you and your team.