-
Notifications
You must be signed in to change notification settings - Fork 2
Process Reflection
Team IO 2.0 is using Extreme Programming (XP) to develop the Arinc 838 project. This is unusual for software development in the aerospace industry, which tends to prefer traditional software development methodologies. This document captures our thoughts about the process and any changes we make to the process through each iteration.
This iteration was mostly infrastructure and environment setup, so no development was done.
In Iteration 1, we anticipated that we would be able to split the work more. We believed we could do boiler plate code and tests on an individual basis, rather than in pairs, to be more efficient. This assumption didn’t pan out. We ended up having to work together to conquer the learning curve associated with the spec. We had identified our lack of understanding as a risk and we saw that manifest. Our strategies of relying on the customer and our use of pairing helped to mitigate the consequences, but still our productivity was impacted. As a team we still met our goals for the iteration, but we had originally planned to be able to do more of the work in parallel.
Since the team also works full time, most of our meetings were at night, and went late into the evening. This contributed to burnout on each member, directly impacting productivity. The team didn't see large-scale impacts from this, but we were seeking to find ways to segment the work such that more could be done individually. As the design solidified, our understanding increased, and our productivity increased when moving from larger pairing sessions (5 people) to smaller ones (2-3 people).
Our reflection session of this iteration identified that we should verify acceptance criteria of all stories with our customer before we start implementing stories, to ensure we implement the desired functionality.
As this was our second coding iteration, the team was more in a flow, and although most of the work was still done in pairs, there was better segmenting of the work. We managed on several occasions to be very efficient with segmenting the work to the point where we had two pairs and one individual working all in parallel. This is probably the most efficient segmenting we expect to have on the project. The only potential for further efficiency gains would be to identify additional individual work that could be done by people when it is not possible for pairs to meet up.
We hit our first major obstacle this iteration. We learned that the verification code needed to be completely separated from all other code. This is due to DO-179B requirements. While we had a story and a partial understanding of this requirement, the depth of it was ignored by the team until our customer explained it fully. We conscientiously made this decision, though we probably did not realize the required depth of the separation. This has caused us approximately a week's worth of refactoring work. It also caused us to miss our goals for this iteration. We only delivered one of the anticipated three stories. So did Agile fail us?
We feel that Agile not only did not fail us, but has served us well, even taking into consideration this obstacle. We did have to do some refactoring, but at a cost of one week, it was relatively minor. We likely could have eliminated this refactoring with some additional planning at the start of the project. However, how much planning? There is no way of knowing how much planning and knowledge we would have had to get under out belts in order to understand this requirement at the level that we do today after a 30 minute discussion with our customer on it. The same discussion at the start of the project probably would have required much more time, had we even known the question to ask.
While we did lose some time, we feel that we gained more by diving in and delivering value to the customer. A traditional planning phase could easily have lasted a month or more. Meaning that we would barely now be delivering meaningful code to the customer, instead of being deep into the second phase of the project. The customer was accepting of the cost of the refactor, and is happy with the value received. Having two months worth of working code makes a week slippage much easier to accept.
Our team is really in a groove at this point. We haven't encountered any obstacles and are just trying to finish strong. Mid-iteration we determined that we needed to identify what was most important for our customer. It was likely that we would not have time to complete another major section. Therefore, we discussed the highest priority features with Chris mid-iteration. He indicated that his major goals had been met, so we could focus on whatever we deemed interesting. We decided to finish up the CRC stories and "tie the bow" on what we had accomplished so far, attempting to finish the verification section.
We cut our final iteration short as we needed to focus on our client and school deliverables in the final week and a half of the semester. However we were able to finish all our verification stories, which was a major milestone. We also had a real reflection meeting as a team, which we hadn’t done for the last few iterations. During this meeting, we discussed the issues we had with the CRC stories where we ended up having to do a rather painful code merge. This was because we simply didn’t coordinate well enough.
We also reflected on our metrics choices. Originally we planned on tracking our effort, both total and per story, but it became too tedious and we stopped tracking. We found that if the tools don’t easily allow us to track our metrics, we won’t track them. We should have actively decided, as a team, to drop the metrics rather than doing it passively by simply stopping.
There were good things that came out of our reflection meeting. We were very good at self organizing, which meant we spent more time working and less time organizing as a team. We also did a pretty good job dealing with the odd number of team members, balancing the more complex tasks with the pairs or triplets. Releases