8am Breakfast Meeting
We’re here with the project team and find ourselves in the local coffeeshop. Attending is the entire project team (2 BAs, 6 developers, 1 tester, project team lead) and a number of managers and PMO rep.
We start by reviewing the previous day’s activities highlighting some very positive strengths we found along the way. We discuss how to propagate these across the company. Given that there are quite a few strengths, the team selects the top 3 to share with the other projects.
We also identify what didn’t work so well during the sessions and agreed on the need for less time to be spent on context/purpose. Everyone feels that this has been adequately explained by management over the past few weeks.
9.15am Meeting with Management
We conduct a session with management to assess their view of progress to date and to let them know of the terrific strengths we’ve found to date. They agree on the need for sharing the ‘learnings’ (I personally hate that term) across other projects and operations.
10.10am Attend Project Review
After the training session last week, the team are conducting a mid-term project retrospective. I promised to bring donuts so I could attend and hear some of the great feedback and ideas for improving the project. Everyone participates – some using a checklist we provided as a memory jogger for strengths and areas for potential improvement.
There’s an action list created and added to the team’s to-do list system with allocated team members and other key company staff to follow up.
11.30 Review with Developers
We hold a quick discussion with the developers working on the project to see what sort of metrics are collected and/or used. When you’re busy with design, coding and unit testing, metrics are one of the first things to slip. However in this team it’s great to see that a number of key measures are used (even if informally). They’re used for estimating new functions and changes to existing systems. Interestingly functional cohesion is used by everyone – even though it’s done manually they still have a good assessment. This is a good indicator for us of the intentions of the developers.
We also focus on their “thrice-daily” builds and release cycle. As a web-oriented project, that had experimented with more and less frequent builds but found they were too frequent or too infrequent. Three times a day was juuuuuuust right – hence the thrice-daily build.
This project is being closely watched by other project teams who still have monthly and quarterly release cycles. It’ll be interesting to see how widely the thrice-daily will be adopted and adapted if this project is successful.
12.30pm Lunch…
We have a great lunch in Melbourne CBD. The team highly recommended it as fantastic for the sukiyaki-don and other specialties. Sounded good and they were right - it was a great experience. We have a fantastic discussion on the current role of microblogging within organizations. They’re all prolific tweeple and are interested in how to apply Twitter or something similar to their work. We describe several tools we’ve looked at for use in project status updating. They’re keen to pursue this and we’ll take it up with the exec team.
One of the reasons we were brought in to the company was to help streamline and integrate the various tools they have in their development environment. While it may seem tangential, keeping up to date with project status is a good way to help communications between the team and other key stakeholders, and hence to assist in the streamlining of the workflows within the company.
1.30 Ambushed by the PMO
The minute we step back in the door, we’re cornered by the members of the PMO. They’re interested in not only refreshing their templates but also in establishing a Library Of Good Examples. We explain to them that although the LOGE can be started with external examples and other non-confidential documents we developed internally within our firm, it would be much more effective to go through the large (but varied) project documents the company has on its servers. They raise the problem that there is just so much material on the servers from previous projects, it is difficult to sort through the material. They really need extra resources to help sort through the material.
2.15 Rework and design of the intranet
The company had originally established an intranet as their main repository of company and project material (documents, processes, schedules, etc). But as it was an incremental activity (i.e. when developers had some spare time) and had no clear direction or structure, its usage varied from project to project and team to team. Some people hadn’t used it for ages and saw it as shelfware – in fact, they had developed their own project and process wikis.
Rather than cut off everything that didn’t conform to the intended corporate standard, we decided to get each of the core stakeholders together to establish some overall principals – rather then the strict rules which would need constant policing.
Together with the participants of this session we were able to identify who the stakeholders were and how we could best engage and involve each of them.
3.15 Afternoon tea…
We like to take advantage of as many informal activities and gatherings as possible (plus we love coffee and donuts ;-) What strikes us with the people in this company is that everyone at all levels have been suggesting improvements and areas that need attention. Interestingly they aren’t doing it anonymously – the types of comments they’re making to us when management and team leaders aren’t around are pretty much the same type and impact of suggestions as when the boss-man is present. Shows us he and his team have been doing a great job in providing an open and transparent environment.
We get some good ideas on sorting out their rather large collection of project and operational documents, reference material and technical papers they’ve picked up along the way.
345 Process Definition and Rework
While the thrice-daily build has been an effective and rapid approach to development, it hasn’t really integrated well with the surrounding project activities. They’ve also had an important customer who wants daily face-to-face requirements reviews. This has not been accommodated well thus far and as it is a really critical customer, a number of stakeholders are keen to satisfy this need.
So we start by the current work (functionality builds) in progress and how they have been selected (prioritized). Each of the developers does a quick heads-up and what shadows they see on the horizon. Even with the thrice-daily build we identify some inconsistencies in their approach to integration. Their automated test tool has been set up to test for valid data, but few tests for invalid data/threads. Some errors have gotten through because of this.
Each person has been responsible for their own release schedule (once their approach had been agreed in principle with the team leader). In this project each person has about a 2-3 day development cycle and once they were happy with it they would release it during one of the release windows 8-8.30AM, 12-12.30PM, 5-5.30PM. e.g. there were a few staff who wanted to work late and these changes were generally included in the 8AM release window.
After a review of the actual functions released, it became obvious that more changes were released in the 12-12.30 window. In fact 90% of changes were released in the 12PM window. 8% were released at 8AM windows and 2% in 5PM window.
Looking back at the requirement of face-to-face reviews, we proposed a daily morning review of current functions with the customer. This was to be a combined webinar and discussion. Once a week they could get the customer to come into the development office and play with the system. Some debate about work-in-progress and expectations ensued. Given that it was such a short meeting in the morning, they were happy to pilot this for four weeks and evaluate its effectiveness.
As it transpired, one of the developers was an evangelist for this approach anyway. He had done daily build reviews with his last company and provided some specific examples to the other developers on the pragmatic approach this could provide to developers.
Our local champion/evangelist was keen to document what had been proposed and the team leader would keep all of the stakeholders in the loop including discussion with the customer.
A followup meeting was planned in 4 weeks for the review.
5.30PM Beer O’Clock
Time for a quick bit of networking at the Mitre Inn (Melbourne’s oldest pub?)
Great feedback and discussion between the customer reps and the development team.
留言