Tuesday, December 22, 2015

Why Agile


Agile, and it’s most popular implementation Scrum, is becoming standard in software development. Yet, each organization’s journey to Agile adoption is different, and is not always smooth. Scrum adoption is often a significant change in how the organization functions, a change that requires people to assume new roles, acquire new competencies, develop new relationships.

So, why Agile? Changing the organization is hard work, risky, and painful.  What does Scrum deliver to the organization?

There are a lot of great ways how Agile and Scrum can make a software development organization more productive and successful.  Lets look at some of them.  
  • Scrum can help restructure and reduce delivery risk and increase predictability: potentially shippable software in small chunks, delivered frequently. The most important structural element of Scrum methodology requires delivering working software every 2-3-week iteration. The product must be ready to ship or release. Continuous focus on upcoming delivery forces the organization to focus on finishing up work quickly, and allows to deliver often and on-time.
  • Scrum helps deliver a better product, by encouraging earlier incremental delivery, and regular and frequent communication with customers and stakeholders during development. Frequent incremental deliveries allow to collect feedback on the incrementally delivered, yet already useful, software. Short iteration cycle allows the team to accommodate desired changes as requests come in during the development cycle.
  • Agile and Scrum recognize and encourage better software engineering practices, to improve and maintain higher technical quality of the product. Higher software quality allows for fewer bugs, shorter time and less effort adding new functionality and fixing defects, and makes it easier for new developers to become productive working on the product. Commonly suggested practices are automated builds, frequent or continuous integration, automated developer and acceptance testing, requiring and maintaining code quality using automated code analysis tools and code reviews.
  • Scrum helps organizations achieve better ROI by delivering better product earlier, and working incrementally. The customers get a chance to start working with the incrementally delivered product earlier. The organization enjoys an even-paced delivery schedule that builds trust with stakeholders, improves morale, and limits pressure and stress.
  • Agile approach to software development is built around the understanding that creating software is an inherently complex and complicated business, with tremendous upside, expensive downside, and high uncertainty. Scrum and other Agile frameworks do a great job to allow for experimentation by limiting the impact of mistakes. In order to succeed in a creative enterprise, errors should be allowed and encouraged, and it helps if the mistakes are cheap and easy to identify and fix. Agile encourages communication and experimentation, makes mistakes cheap and visible, and thus creates perfect condition for hitting the ultimate project jack-pot.
Have you considered adopting Agile? What are your reasons for the change?


Tuesday, December 1, 2015

Dealing with the technical debt

That's an interesting way to think about technical debt. The amount of interest on a debt is controlled by the interest rate, and also compounding frequency.  Higher rate leads to more interest accumulating over time, and so does higher compounding frequency. Compounding frequency for the technical debt interest rate is determined by amount of work that still needs to be done on the code.

For any level of technical debt, i.e. code mess, the cost of technical debt could potentially be nothing - if that code never gets touched again.

However, if the codebase is for a useful, living product, chances are it is continuously going through the transformation. Features are being added and removed, bugs are being worked out or at least mitigated, and structure gets updated. That raises the cost of the technical debt in that codebase tremendously, since the interest is being compounded all the time.

When starting to work on reducing the technical debt in a large codebase, the starting point makes a difference. Starting with the code that changes frequently is a high risk/high return approach: improving technical quality will make a noticeable difference in the technical debt burden. However, it is risky to introduce changes to the code that is exercised a lot and in ways that change frequently.

Alternatively, one can choose to start with less-frequently touched portions of the codebase, to build experience and understanding.  The technical debt reduction benefits will be less significant, but the code changes will also be less risky.

Sunday, November 1, 2015

Judging Scrum

Judging Monkey

Scrum is supposed to be simple. Scrum.org by Scrum creators Jeff Sutherland and Ken Ken Schwaber attempts to define Scrum less than 60 words:

“Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.
Scrum itself is a simple framework for effective team collaboration on complex software projects. ”

How simple is Scrum, really?

Scrum, as a management framework, is a practical approach to solving the Agency problem. Agency problems are pervasive in modern economies due to the extensive division of labour and specialization.[1]

The problem of agency was first laid out in 1970s[2], noticing the essential imperfection of agency relationships: people (agents) hired to tend to interests of others (principals) actually behave in their own best interests. Economic and institutional approaches to principal-agency problem look at incentive and punishment schemes and various management issues that arise when trying to bring agents’ behavior closer to what the principals would prefer.

Organizations that engage in software development and IT projects almost always involve a group of people concerned with the final product (principals), and a different group of people (agents) tasked with creating that product. The problem of agency is fairly easy to see in this setting: the interests of the business are not identical to interests of the creators of the product. There are different ideas about what the principals group wants and expects the creators to do, but all agree that interests and behavior of the agents group are never perfectly aligned with principals’ group desires.

Scrum is one of many systems designed to address the agency problem in the commercial software development and IT space. History and current state of management science and business practices show that the problem of agency continues to lack a perfect solution. Among many systems designed to align behavior of principals and agents in a given business situation, most only achieve a partial solution, and some are unreasonably costly. Like other systems, Scrum may be helpful in achieving a better alignment between principals and agents. Scrum can also turn out to be costly, depending on implementation.

Scrum targets to improve communication between the two groups, with the idea that better communication will allow for greater transparency and trust. Scrum provides fairly detailed rules for communication structure for the two groups, and instructions for both the principals and the agents how to set and sustain this structure. This generally works, although trust is not a guarantee. However, communication is costly, and is subject to diminishing returns, i.e. more is not always better.

In addition to the prescribed communication structure, Scrum dictates limited autonomy and accountability for the agents group, and institutes measures to maintain its own framework. These changes are also costly, and run contrary to common organizational structures, thus making them complex to implement. Even worse, the benefits, although sometimes great, may not be easy to quantify, and are very hard to measure.

While the rules of Scrum appear to be simplistic, the overall system is quite complex, with ambitious goals and significant overhead. Scrum affects operation of both principals and agents, steering emotions on both sides. It effectively introduces a brand-new principal-agent contract, with differently defined roles and responsibilities, and new assumptions about each groups’ motivation.

Overall, Scrum is an imperfect approach to a very hard problem – one of many imperfect approaches. There is no known solution as of yet, and it is quite possible that such a solution does not exist at all. When considering Scrum against other less-than-perfect attempts to align behavior between principals and agents, it appears that Scrum does a pretty good job delivering on its goals. Yet, it is far from simple.