Category: risk

Taking customer risks fable

September 19, 2008 by Artem Marchenko

Disclaimer: All events and situations are imaginary. Any coincidence with reality is accidental.

Once upon a time there was a web development shop. One day a customer from a mobile phone and laptop company called Nokapple came to the shop asking to build a web site for selling music. The project was supposed to change the whole market and appealed to the company much, the team never worked on that big project, but had relevant experience and agreed.

The development started actively and everything was going more or less smoothly. The customer's requirements did change during the course of the project, but the team managed to cope with that and was still targeting the original release date. Customer was so happy to see the evolving project that two months before the release date he decided to change his business plan and start targeting not only US market, but to go internationally.

The Big Development Project: How much should it cost?

September 3, 2008 by Peter Stevens

Some people think that agile and budgeting are incompatible. The product is ready when the product owner says it is. But before starting a project, most managers want at a least budget. So the product owner puts together his wish list and asks the ScrumMaster what it will cost to build. The answer comes back — usually a long time and whole lot of money! Then the customer turns pale as he tries to decide what it will really cost, whether he can afford it and whether it's worth it.

But there is a better way: the product owner can perform a double worst case analysis. This quick and easy tool uses the project's business value to determine a reasonable price for the software investment.

Five risks of solo programming

August 15, 2008 by Artem Marchenko

Pair programming is one of the most debated practices of the Extreme Programming. Historically, programming used to be a solitary activity that required high concentration and even isolation. The best programmers know how to get into the metal state called "flow" or "zone", in which the undisturbed mind is able to efficiently focus on the code and make highly creative and efficient design decisions.

While "zone" is indeed highly valuable and learning how to deepen into zone as a pair might be more difficult, than learning how to get into flow alone, the truth is that despite the comfort of the long time status quo, solo programming is just too risky and in the end might cost quite some more money for the company. There are many risks of solo programming, here are the top five that come to my mind.

Agile Risk Management

June 17, 2008 by JurgenAppelo

Today's evaluation of one of our projects was a tough one. It seemed like nothing had gone right. The customer had signed the contract far too late, which meant that resource management had to switch to another (inexperienced) team, because the original team was already booked for other projects; the platform to be used turned out to be much older than anticipated; the customer singlehandedly decided on a live release date, and forgot to inform anybody else on the team about it; half of the requirements turned out never to have reached the proper team members, due to some stupidly bad communication; and beta testing was a nightmare because the customer hired a third-party service organization, and the development team was not allowed access to the beta testing environment.
Needless to say, the first release of the project was bad. Really bad.
Could we have prevented our problems?
Of course!
Do the agile methods have anything to say about such problems?
(In our case) nothing useful!
Can we solve these problems by adding more processes?
Absolutely not!

Risk analysis in agile methods

December 21, 2007 by Artem Marchenko

Risk analysis in traditional software development projects is often performed for real only before getting the financing and actually starting work. After the project ends there are often the "lessons learned" sessions, which in case of a failure are called postmortems. During these pre-project and post-project risk analysis activities an attempt is being made to reduce the risks and maximize the probability of success. The recent addition to this collection of methods is the idea of a premortem that is a risks review that happens before the project start as if the projects has failed already. While all the pre- and post-project risk analysis techniques are indeed useful and can help organization to improve own practices, they only look at the potential problems at only two moments of time. Therefore there is always a danger of missing the important factors that either did not exist at the point of analysis or team members did not have enough information about those.

How agile has to kill projects

November 26, 2007 by Artem Marchenko

Agile software development methods assume the significant amount of uncertainties and risks in the software development. The idea of the iterative development  employed by agile methods is aimed at verifying the project direction and state frequently.

Agile risk mitigation

Agile approach at risk mitigation is to attack the most unsure items first and therefore lessen the amount of the unknown as early as possible. In a way every iteration planning is a risk analysis and mitigation planning session. Imagine a project, where supporting millions of users is something the team is not sure is possible. In this case agile methods advocate for implementing the scalability support before the majority of the features.