Risk management strategies beyond spiking

The key concept: To understand the concept of risk management strategies and how to implement the risk management strategies in the right direction. The limitation of risk management strategies also is the important area to mention.

Argument:

Risks could vary a great deal in their impact, probability of occurrence. Hence it becomes very important for the success of the project to identify risks, set priorities, have risk control and mitigation strategies in place. Spikes are generally a very good way to avoid risks associated with certain gaps in knowledge, skill and technology. And that’s where small scale risk eliminating strategies such as ‘spikes’ run out of steam.

The Risk management strategies (that go beyond spiking) are mostly divided based upon four major risk treatment categories (and hence risk management categories): avoidance, reduction, retention and transfer.

Risk avoidance is ‘don’t practice something if it involves risk’. E.g., don’t use c++ (use java) to avoid serious memory management bugs (but what if all the programmers only know C++). Risk reduction is agile is an excellent example, develop and deliver incrementally to avoid huge risk of failing the whole project. Risk transfer is where risks are transferred to another source (outsourcing!) or for example, insurance. Risk retention is be prepared to accept the risk. If a risk is not managed, it happens, it retains automatically

Conclusion:

To conclude that, while large risk management strategies are essential to any decent sized project, spiking has its own value – very simple, follow the basics approach where known gaps are spiked. Spikes fail where gaps are not known or their risk causes are not known. That’s where the four risk management come into play and come handy!

Limitation of user stories

Blog:  Limitations of User Stories

The key concept: To understand the limitations of user stories under different usages when user communicate with the developers for the software requirements.

Method to communication

User story is used for requirement gathering in agile software development project such as extreme programming. In general user story is a short goal oriented story on how a user will perform certain tasks with the system.

Argument:

One of the main limitations of user story is that it opens for many interpretations. User story is simple and contains scripts which focused on a functional goal. It does not state the detail of the user interaction with the system. Our users may have different understanding with the team. As a result, it is hard to use user story to act as an agreement between the user and developers. That is why it is suggested that the customer or end user is part of the team, so that we can communicate and clear any doubts through face to face communication.

Another limitation is lost the performance requirement detail. Often, user story which becomes the basis of user acceptance test will only test the business logic of our application. It will not test the performance or our database layer such as database response time. To overcome this limitation, developers or testers need to pay attention to other documents such as product attributes and system constraints when building the test case. Therefore, developers and users have to develop these documents carefully as it will accompany the user stories.

Conclusion:

Commonly, user stories contain less information for software information. After collecting requirements, we need to scan them. During the estimation effort, sketching UML user case diagram and sequence diagram are clearly described tasks required to implement the user story. Then list out those programming tasks. Mock-up or a UML activity diagram can help to represent the relevant business logic. User stories are merely the starting point.

Reference 

Limitations of user stories, user Articles, viewed Saturday 20th August,

http://en.wikipedia.org/wiki/User_story

What is the optimal iteration length in agile projects?

The key concept: To understand the optimal iteration length in agile projects. Also we can understand the side effect and importunateness of the optimal iteration in agile projects.

What exactly is the optimal iteration length in agile project?

The length of the iteration depends on the amount of time the users can go without seeing progress and providing input. Some core mechanics require a lot of feedback from outside, so maybe one or two week iteration is better. Some teams don’t need such a rapid cycle of feedback especially production teams and so four weeks iteration is fine for them.

Team Experience affection

The experience level of a team needs to be considered when selecting the length of iteration. Teams that are new to agile often want to have the longest possible iterations. Experienced teams will do a bit of each of these things daily which is a better way to work. It creates better results and allows the team to discover better value during the iteration.

Ability to plan the iteration
If the iteration goals have a lot of uncertainty and experimentation that needs to be done (in the form of spikes, or time-boxed tasks) then the iteration should be shorter than one with less risky goals. Risk implies that the solution might be significantly different from the one anticipated at the start of the iteration. It’s better change direction (or even backtrack) after two weeks than four in this case.

Balanced Intensity
sometimes four weeks is too long to give a team to work. This is especially true of teams that are new to agile. As described above, new teams will do mini-waterfall on iterations at first which leads to a pretty lax mini-design phase up front and an intense debug mini-crunch phase at the end. Teams will find what works best for them over time.

Agile Planning -- Challenges

The key concept: Well planned software project planning should plan like this: undergoing with aggressive process date, over-promised feature sets, and unrealistic project plans that not included technical skills. However, the fact is backfired with reality. This article can show how an agile planning approach can help.

Get trouble when traditional Project Planning start

Usually, the business stakeholders usually have these three things in common for each project:  i) Scope:  specific problem they need to solve. ii) Time:  Timeline the project need to solved by. iii) Cost:  estimate how much it’s worth to solve the problem.

With Agile project planning is different approach to solve the specific problem. Without define every detail, agile planning can plan incrementally, starting with the most important features. The development team can then determine which of those features they can complete in a specific timeframe or “iteration” within the range from 2 to 4 weeks.

Each iteration allows the user to choose additional features (or enhancements to existing features) and to prioritize the remaining work. The development team can learn from each previous iteration to improve their estimating. If they complete all of the features agreed to, the team can start working on the next priorities as determined by the user. If not completed the features, it’s the user who gets to decide which ones to defer until later.

The key for approach is communication and rapid feedback. The user communicates in the form of clear, priorities needs. Development communicates in the form of estimates for specific, measurable functionality, which is critical in the prioritization process.  Finally, there is rapid feedback to both teams on how things are going. The development team delivers working software at the end of iteration, even if it's just a skeleton of the finished product.  This tight feedback loop is a big part of why an agile approach works better.

Reference –
Agile software Planning, user Articles, viewed Saturday 6th August, 2011 http://www.extremeplanner.com/articles/Agile-Project-Plannipng.html