1.
Improving the Development Process 13 th May, 2008

2.
Tec Flow Chart expand contract TARGET DECIDE ACT Summaries Next Steps

3.
White Hat <ul><li>No planning seems to occur </li></ul><ul><li>No continuity. Continually jumping between issues means that you lose track of what you were doing </li></ul><ul><li>Everything seems to be a “big emergency” which must be done immediately </li></ul><ul><li>Customer appears to set our priorities </li></ul><ul><li>Sales promise things to customers with little thought for schedules </li></ul><ul><li>We seem to do any enhancement that comes along, regardless of whether it adds any value to the product </li></ul><ul><li>Backlog of work for QA to do. Not enough QA resources to handle the volume of work to test. Support are currently assisting QA </li></ul><ul><li>facts </li></ul><ul><li>figures </li></ul><ul><li>Information </li></ul><ul><li>asking questions </li></ul><ul><li>defining information needs and gaps </li></ul>

4.
Red Hat <ul><li>Everyone appears to be trying to manage development (e.g. Clients, Suanne, Gerard, Doug and Martin) </li></ul><ul><li>Development is difficult because of the number of coding streams </li></ul><ul><li>Not enough thought into estimates </li></ul><ul><li>Development are completely reactive </li></ul><ul><li>Everything seems to be a panic because of a crisis </li></ul><ul><li>No planning </li></ul><ul><li>Not enough resources in each department </li></ul><ul><li>Constantly shuffling resources to cope with the latest problem </li></ul><ul><li>Lack of specifications </li></ul><ul><li>Roadmap does not include fixing bugs </li></ul><ul><li>No continuity </li></ul><ul><li>Number of streams is confusing to customers </li></ul><ul><li>FreeBalance should differentiate between “customer-centric” and doing something just because the customer says we should do it </li></ul><ul><li>Development does not believe the four week iteration concept will work because we are so reactive at the moment </li></ul><ul><li>intuition </li></ul><ul><li>feeling </li></ul><ul><li>emotion </li></ul><ul><li>no justification </li></ul>

5.
Black Hat <ul><li>Not enough resources </li></ul><ul><li>Rest of company will not be on board with the new process </li></ul><ul><li>Crisis will still occur which need addressing immediately </li></ul><ul><li>Increase customer annoyance – will now have to wait at least four weeks to get a resolution to their issues </li></ul><ul><li>Customer A may have a problem that is planned to be fixed in the next iteration. This will be communicated to the customer. Customer B then raises higher priority issue which will push Customer A’s issue down the queue. </li></ul><ul><li>What will happen if you need a business analyst during the development week </li></ul><ul><li>New process will require more management </li></ul><ul><li>Will extend projects – a process which may have required three weeks of solid development will now be increased to twelve weeks to include the analysis and QA </li></ul><ul><li>Manuel always escalates issues to the top of the pile which need addressing immediately </li></ul><ul><li>judgement </li></ul><ul><li>caution </li></ul><ul><li>justification </li></ul>

6.
Yellow Hat <ul><li>Increase headcount </li></ul><ul><li>Lose support for earlier versions </li></ul><ul><li>Build in mandatory upgrade cost into pricing model (see Hal for explanation) </li></ul><ul><li>Leverage extreme programming </li></ul><ul><li>Set up data beforehand </li></ul><ul><li>Need more people in service department so that developers are not doing services work; “Service dept should be recruiting from places other than development” </li></ul><ul><li>Employ person to act as go-between for Development and Support. This person would gain knowledge in all products. Would stop all developers getting interrupted as this person would be familiar with everything. </li></ul><ul><li>Have one developer for assisting helpdesk and another for working on new stuff. </li></ul><ul><li>logical positive </li></ul><ul><li>benefits </li></ul><ul><li>value </li></ul><ul><li>justification </li></ul>

7.
Green Hat <ul><li>One person to deal with support permanently, go to client sites, investigate issues, do SQL scripts </li></ul><ul><li>Keep development staff on development work, not on services engagements </li></ul><ul><li>Stop being a development organization and become a services organization until Portugal delivers the new platform. Do not do any new work on the existing product set, instead concentrate on services billable enhancements etc. </li></ul><ul><li>Improve visibility for the development activities up and coming </li></ul><ul><li>Improve visibility for the services work up and coming – would lessen the ‘crisis’ issues since we would have advance notice (rather than finding out on the morning that we need to fix issues immediately because we have people on the ground in Country X – we must have known these consultants were going there and could try to identify potential issues beforehand rather than the “drop everything” approach) </li></ul><ul><li>We still need to know what is going to be in FA 6.3. This has not yet been decided </li></ul><ul><li>Developer to be interface between CSR and development – 2 nd line support </li></ul><ul><li>Need a masterplan for at least 6 months </li></ul><ul><li>creativity </li></ul><ul><li>alternatives </li></ul><ul><li>proposals </li></ul><ul><li>interesting </li></ul><ul><li>changes </li></ul>

8.
Blue Hat <ul><li>Try out the 3 / 4 week iteration plan and get the other departments on board – some team members remain skeptical </li></ul><ul><li>Suggest hiring more people; </li></ul><ul><ul><li>More QA required </li></ul></ul><ul><ul><li>More Services staff required </li></ul></ul><ul><ul><li>Extra developer required to act as 2 nd line support / CSR – Development go-between </li></ul></ul><ul><li>set agenda </li></ul><ul><li>next steps </li></ul><ul><li>keep discipline </li></ul><ul><li>summary </li></ul><ul><li>requests </li></ul>