Project management

This section provides adaptation information to improve visibility of development projects as illustrated in Figure 23. Improved visibility is part of project management as an adaptation (overt) factor in Fitzgerald’s adaptation framework.

4.4.1.1 Improved visibility

At Akldevelopment, both planning and executing projects are regarded as equally important; their agile product planning tasks maximise the visibility of upcoming

features. The product vision and iteration plans are discussed. Information on adaptation of these plans to improve visibility is also provided.

Figure 23 Improved visibility in relation to project management - Akldevelopment

4.4.1.1.1 Product vision (high-level plan)

At Akldevelopment, considerable effort goes into developing high-level plans. It is an important artefact to establish and to communicate visions of their new developments company-wide. The product managers have this responsibility. Their business-level planning strategy to identify high value features creates the awareness for the new features within and outside the organisation. With the agile development team this is

achieved through their planning practice of creating a release backlog, which is driven by the product analysts. Information on high-level and low-level planning including how and why they are adapted has been provided with the in-house development factor in the profile of the development environment.

4.4.1.1.2 Sprint plan for story implementation

With this agile team, a sprint plan identifies the schedule of all the stories that they commit to implement in a sprint. Here, sprints are allocated stories from a release backlog according to the priorities, which are market-driven. The sprint plan is an outcome based on agreement between their engineers and the product analyst. The business functions such as the sales and marketing departments are dependant upon the sprint output, the build. At Akldevelopment, the visibility of each sprint is extremely important since the stakeholders need to know in advance the availability dates of the implemented stories. However, this is dependent upon the accuracy of the story estimates.

Break down the functionality and lay it out in terms of releases … once the sprint has started … team tracks that every single day … walk to the whiteboard and see exactly if they are ahead of, behind or on schedule (Engineering Manager)

Each Sprint we are not really tracking the amount of time it took to do certain tasks … we are not collecting data … people just kind of roughly remember how much time it took to do something … don’t even know if that would be useful, every task you do is quite different. (Principal Engineer)

Facilitation of intercommunication among developers

Epistemological: transfer of knowledge, template for inexperienced developers, learning from past projects

Economic: skill specialisation, division of labour

Reduction of variety and complexity Project management: improved visibility, reduced risk

4.4.1.1.3 Adapting story priority setting

This agile team has adapted how the priorities are assigned to the stories in order for the team to easily schedule stories within a sprint. They were having stories of equal

priorities making it hard for them to reshuffle the order of the stories for implementation in a sprint. Some of the senior engineers recognised that two stories with the same priority caused unnecessary debate about which story should be implemented first, resulting in precious time being wasted during sprints. In August 2005, the team

collectively agreed with the product manager that no two stories should be assigned the same priority. Previously, stories were given a priority of high, medium, or low. Now, all their stories differ from one another in priority.

Can’t have two stories with exactly the same priority … to decide between two, because able to do one … it becomes even harder and it takes up more of the team effort. (Senior Engineer)

4.4.1.1.4 Story estimates

At Akldevelopment, there are three points for story estimation. One is with the vision and roadmap plan, where they estimate on a large scale the releases that they will do for the next 12 months. This is a high-level story estimate involving a few senior engineers. The next estimates are done when planning a release backlog, which also involves only a few senior engineers. The final estimates are made in sprint planning meetings when the agile team engineers collectively provide estimates for stories against which they will work in a sprint.

Higher level stories get broken into 2 or 3 different stories each [backlog planning] … the engineer sizes [estimates] them … go through each story [sprint planning] … team determines

how many hours they need. (Product Analyst)

4.4.1.1.5 Adapting estimating practice

Despite having three different points for estimation, on occasion it is quite a challenge for them to deliver their sprint commitments. Over the projects, the engineers in this agile team experienced that the most of stories relate to new technologies to improve client performance. Several of their stories require a good understanding of such technologies for the engineers to successfully implement them. Hence, some of these stories require further investigation before their implementation. For this reason, the engineering manager proposed to the engineers that they provide estimates in points rather than in hours, giving them a buffer for gaining a better understanding of a story before its implementation. As a result, this agile team in January 2007 agreed to adapt

their practice of providing estimates from hours to points. Here, one story point is equivalent to one ideal day or 8 solid hours of pair programming.

Moved from hours into story points … look at all the stories … identify the smallest story in terms of the least effort …compare that story with every other story … it can be equal size … it can be 1.5 or it can be 5 … can apply any scale. (Engineering Manager)

0.5 is half an ideal day … doesn’t mean like half a real day. It could be like 1 or 2 real days … an ideal day means an engineer sits there for 8 hours. (Engineer)

Previously, an engineer proposed an estimate for a story. However, it was observed by some of the senior engineers that for the majority of the time during sprint planning meetings an estimate suggested by an engineer was quickly agreed by others without much thought or discussion. The principal engineer suggested using the planning poker game to generate discussion before the team committing to a story estimate. Hence, the team agreed in March 2007 to adapt their estimation practice for sprint planning

meetings with planning poker. This adaptation has enabled the team more discussion helping them to identity issues with stories and providing more accurate estimates for their implementation.

All have cards with different story points on them, from 0 to 5+ … all draw out one of the sprint poker cards … place them on the table at the same time, if 2 people bring out a story point of 1 … 8 people bring out 2 points for that story , more likely put 2 down on the story card. (Engineer)

Next, adaptation information to reduce risks in relation to project management at Akldevelopment is provided, as illustrated in Figure 24.

4.4.1.2 Reduced risk

Discussed next are some of the key risk factors that may impact Akldevelopment’s new development. Information is provided on adaptation of their agile approach with new practices to minimise the impact of these risk factors.

Figure 24 Reduced risks in relation to project management - Akldevelopment

4.4.1.2.1 Unfamiliar technology

It is a constant challenge to provide accurate estimates since stories frequently involves new technologies for which the team lacks knowledge. For this reason, the team has adapted its agile development with a practice known as a ‘spike’. On occasions, the team runs a spike; it is a practice of allocating time to learn about and consider technological issues before being able to implement stories within a sprint. If realised before or during a sprint planning meeting, a spike is run as a story with other story implementations before any reasonable estimates are provided for it.

The risk … new technology the team is not yet as familiar … a spike; you need to invest a few hours in order to determine the actual effort. (Engineer)

4.4.1.2.2 Outdated backlog plan

For this agile team, there was also a constant challenge to allocate time for re-evaluating backlog plans. Having adopted sprint cycles as a method for allocating and carrying out their development tasks, the engineers are constantly implementing stories from one week to another. There is always the risk that the senior engineers may not re-evaluate and provide an updated backlog. This leads to decisions being made based on outdated estimates. They have adapted their agile approach with a practice (it makes sure that time is set aside) that involves evaluating the estimates of the next release in their current release cycle.

Our strategy … regularly update and revisit all the estimates [for] next release or next 2 releases … estimate still looks okay. But this is not only about the size of the different stories, it’s also about the content and scoping of stories and the prioritisations … revisit all of those. (Engineer Manager)

4.4.1.2.3 Missing low priority story implementation

The agile team have missed out implementing some of the low priority stories. These missed items are the missing functionalities for a new feature which Akldevelopment is trying to provide with its product. These types of stories are low priority but are

considered to be important, adding value to new features. For this scenario, they

incorporate their agile approach with a shorter iteration cycle (less than a week long) to

Facilitation of intercommunication among developers

Epistemological: transfer of knowledge, template for inexperienced developers, learning from past projects

Economic: skill specialisation, division of labour

Reduction of variety and complexity Project management: improved visibility, reduced risk

The risk, miss some items of low priority … have short iteration … allocate it for next week … mitigate that risk by making sure that system is always completely refactored, clean and simple design … add whatever you might have overlooked. (Engineering Manager)

Next, adaptation information is provided on reduction of variety and complexity (Figure 25).