What are the Challenges?

First things first. Organizational culture and executive support play an important role. Principles behind the Agile Manifesto highlight the need for self-organizing teams. These teams are expected to take decisions. When Agile teams change the way the software is delivered, it affects the way the organizations do business. Without executive support, this cannot be achieved.

The Agile Manifesto favours delivery of working software over comprehensive documentation. There is an inherent emphasis on a relation between developers and organizations that is based on trust, integrity, and transparency. It may not sound like a huge shift, but is still a significant challenge for many organizations.

It is crucial that the team is trained and aware of Agile concepts and has the necessary tools needed to perform. A team of skilled and experienced developers is more capable of taking decisions, compared to a less skilled team.

And finally, customer commitment. Agile delivery values business user collaboration and direct interaction instead of intermittent communication at fixed points in the life cycle. Effective business involvement reduces the risk of delivered features not meeting customer requirements. (Gartner, Agile Success Factors, David Norton & Matthew Hotle).

So, how can I go Agile?

More accurate question is, which Agile delivery methodology should I choose for my project?

Though all Agile methodologies recommend iterative and incremental delivery of software, the differences lie in the way each methodology is executed and the artifacts produced.

• Scrum: Focuses on self-organizing teams and client-driven adaptive planning. Prioritizes delivering working software in no more than 30 days, over documentation.
• Extreme Programming(XP): Keeps things simple. Focuses on the continuous implementation of best practices such as code reviews (pair programming), refactoring, ongoing testing, and continuous integration.
• Feature Driven Development (FDD): Breaks down the delivery of a larger software by features. Simple processes, short iteration cycles. Suitable for predictable evolution.
• Kanban: Based on Toyota’s just-in-time (JIT) production system. Incredibly simple and still incredibly powerful Kanban boards. Focuses on eliminating bottlenecks.
• Lean Development: Focuses on providing value for money. Recommends avoiding unnecessary errors, amplifying learning, deciding as late as possible and delivering as early as possible.
• DSDM: Developed from a business perspective. Strong emphasis on project management. Plans evolve based on increments.

Here is a side-by-side comparison of various Agile methods based on key parameters.

2. Knowing You Are Delivering The Right Thing

The Product Owner plays a key role in ensuring project success. Translating business needs into project objectives may seem easy on the surface, but it is a tricky task. The person in this role may need to stay constantly involved with the development team for iteration demos and mid-iteration interactions. The Product Owner represents the business and plays a crucial role in not just validating iteration output but also drives the development of UI designs, use cases, and test cases.

This is a hands-on, high involvement job and can turn daunting especially when done in an onsite-offshore setting. BitWise agile projects delivered from offshore, have a designated Proxy Product Owner who is co-located with the team and usually comes from a testing or a business analysis background. The Proxy Product Owner assists in creating use cases and test cases while maintaining close communication with the real Product Owner.

3. You Can’t Predict Defects

That’s why you need to keep some bandwidth available to fix them. Usually, more bug-fixing bandwidth is recommended for later iterations compared to earlier ones. Historical data, if available, plays a crucial role in deciding how much of bandwidth is really required at different stages.

Continuous testing plays a key role in the success of Agile projects. The team needs to be equipped and prepared to handle the amount of testing necessary for the project. The disastrous launch of healthcare.gov in late 2013 is a good case in point.

An important feature of BitWise agile projects is a dedicated iteration for regression testing, usually towards the end of a milestone or project. It has provided incredible value to customers and ensured adequate attention is paid to defects.

4. Do Iterative Changes Affect Product Design?

Design, like integration and testing, is a continuous activity. The iterative approach provides the luxury to plan a design that’s minimum viable and enhance it from there. Bitwise Agile iterations deliver not only code but also design improvements as deliverables.

Unless you are careful and have invested some upfront effort in setting up a clear roadmap and future-proofing the design, it won’t be long before you start worrying about the rework frequent design changes are causing.

5. Timeboxing Research-Oriented Tasks

Having incomplete tasks at the end of an iteration is not a very uncommon scenario. Especially, if the tasks involve technically complex research-oriented work. Apart from derailing team velocity, such tasks may impact a more important metric – customer satisfaction. The sprint retrospective is an opportunity to brainstorm the causes and consider alternative approaches.

So what are the options? Not too many, really. Either it can be moved to the next iteration if it’s more than halfway through or move it back to the product backlog and reprioritize.

The Science of Story Points

Why use story points? They are not even real, right? Let’s see about that.

The traditional approach of estimation has been to break down the work and then assign the amount of time an “ideal” developer would take to accomplish it. These ideal estimates (in days or hours) are based on some assumptions about the rate at which software can be produced by this fictitious developer. The assumed productivity rate is based on various factors such as skills, experience, coding style, etc.

The story point approach makes it simple and data driven. These are hypothetical numbers assigned to tasks based on the amount of work expected to complete the task and the complexity involved. How could an imaginary story point be translated into the real effort spent by the team? Here’s how:

To begin with, you need to have a system in place to measure the actual hours spent by developers on tasks labelled as one story point. It’s fine if it varies by person and by team.

The central limit theorem The central limit theorem in probability states that the arithmetic mean of a sufficiently large number of iterates of independent random variables (hours consumed per story point in this case) will be distributed like a bell curve. This means if you plot the hours taken to build a story of size 1 story point against the number of stories on a chart, the graph will look somewhat like the diagram here. You clearly see a bell shaped pattern with a mean value “x”. Now similarly, plot the hours taken to build a story of size 2 story points, its mean will be 2x. This “x” is your conversion factor for translating story points into person hours.

What if you don’t have the historical data or a system to gather the data? Start with assigning an estimate of 1 story point to a familiar task that usually takes 8 hours.

The Science of Relative Sizing

Agile estimation techniques recommend sizing up tasks relative to each other. The estimator compares the task or story being estimated with one or more other tasks. If the task involves twice the work or is twice as complex, it is estimated twice as large.
So what are the benefits in doing that?

When you estimate tasks relative to each other, your estimation process is not only more accurate but significantly faster. There is an evidence that humans are better at estimating relative size than the absolute size (Lederer and Prasad 1998; Vicinanza et al. 1991).

Looking at a map, it’s hard to guess that the distance from New York to Chicago is 800 miles and New York to Boston is 200 miles. But it’s not so hard to tell that the distance from New York to Chicago is four times as much as the distance from New York to Boston.

The Coastline Paradox

How much effort should a project of size x take to estimate accurately? Well, the lesser the better. Estimates by definition are supposed to be just usable approximations. Estimation effort beyond a point yields very little value to the project.

The Coastline Paradox It may seem counter-intuitive but the more you break down a task to a micro level, the more are the chances that your estimate is going to be wrong.

A similar challenge is experienced by surveyors trying to measure the coastline of a country. It can produce varying results depending upon the length of the scale chosen for the job.

With a smaller the scale, and you can measure every little crevice along every creek on the shore. Take a bigger scale and it smooths out all details. This paradox of a constant finite area having varying length of perimeter is called coastline paradox.

In short, whether you are estimating efforts or measuring a coastline, choose the level of detail you want to consider wisely. Living with a measure of ambiguity at times will not only save your efforts but will also increase effectiveness of your efforts. Sound counter-intuitive? That’s why it’s called a paradox.