Digital Fire succeeds with Koyana

Digital Fire needed to be fast and flexible to make critical deliveries to their client. Using Koyana’s insights into the software development process Digital Fire were able to deliver on-time with new, breakthrough, technology.

Read Digital Fire’s endoresment here

Agile process improvement

We hear a lot about applying agile techniques to software projects for producing software. Can Scrum techniques be applied to action-items from a retrospective; specifically process-improvement? Imagine you’ve reached the end of an iteration and you’ve held your retrospective. You and the team now have some action items regarding feature changes and you also have changes to your process. How do your process changes fit into your Scrum project-cycle?

This question arose at a recent XP Toronto meeting and we had several thought-provoking answers. Here is one answer to the question.

In essence the technique for dealing with process-related goals is no different than dealing with features or user stories in a sprint with the addition that we will make a decision about who executes the work.

Step 1 – Who is the customer?
We need to find a product owner for the process improvement items. This step is essential because we need to know the business value of the process improvement and also who benefits from that improvement. For example we may have identified an improvement item during an iteration for a customer but the improvement benefits us and may not produce business value for our customer. In this case our process improvement needs to be owned by us.

Step 2 – What’s the value?
Providing we can identify the customer we can ask the customer or the customer-representative what the business value of the improvement is. With a business value in-mind we can add our process-improvement item to our backlog ad proceed with our sprint planning as usual.

The question that arose in our XP Toronto meeting was this; how do you convince a customer that they should accept a schedule-hit for making a process improvement. The answer is by presenting the customer with the business value of the improvement. For example; if we spend 2 days implementing a new build system we can improve time-to-market and reduce customer costs by 5%.

If we cannot present the customer with the business value of the improvement that’s a strong indicator the improvement either isn’t worth doing, or, it’s an improvement that benefits us and not the customer. If the benefit is to us then we should structure the work outside the customer’s project and execute the improvement work using separate resources. Since our improvement work executes separate from our customer’s work we do not have to convince our customer to take a schedule hit because there is no schedule hit from the customer’s perspective.

(Many thanks to XP Toronto and Ryerson University for hosting our monthly meetings)

Why do some methodologies fail – re-framing the question

After a past experience with Scrum I wanted to write about the conditions under which Scrum projects can fail. A Google search located a presentation from Joseph Pelrine and Jiri Lundak describing a workshop they ran to reveal why Scrum projects fail (http://tinyurl.com/9j2az6). Pelrine and Lundak’s workshop starts by considering the conditions for project failure. This seems like an important first-step but I realized the question may be misleading.

I’m going to use a different approach by asking the question; under what conditions is Scrum applicable? Why ask the question? I was watching Ken Schwaber’s Google Tech Talk video titled ‘Scrum et al’ (http://tinyurl.com/j58cr). 29 minutes into the video Ken states 30-35% of Scrum implementations succeed. What happened to the other 65-70% of Scrum implementations?

After further consideration the question can be broadened to other tools/techniques/methodologies for running software projects, for example; under what conditions are Gantt charts applicable? or, when is waterfall development applicable?

Changing the question helps me address other persistent questions like; why do we still use Gantt charts? Why is waterfall development still used?

Take a look at your own project; what tools, techniques and methodologies are you using? Now comes the hard question; why do you use them?