Following Plato Dialogues: conversation about estimates

-            So, why do we need estimates?

-          Well, as a customer, I want to have estimates.

-          Great! In what ways are estimates useful to you?

-          Say, I order from Amazon, and if my purchase does not arrive on the estimated day, I get to request a refund.

-          Huh, so you are rooting for the sender to fail, and that’s why you need estimates?

-          I guess so.

-          Any other reason to want estimates or tracking?

-          Well, if as a customer I was promised a certain delivery, and it is getting really close, but the work is less than half done, I can make a determination that I am not getting that delivery.

-          So, the reason you want estimates is to feel reassured that work is being done? To make you more comfortable with the delivery that you do not trust?

What are good and useful reasons to want estimates? 

99 little bugs in the code...

A lot of developers I work with are very good, and many are very productive.  Surprisingly, those are not necessarily the same people. Unfortunately, it is not always easy to tell the difference. 

Once upon a time, the management at the company* where I worked decided that there were too many bugs in our code base, and an effort must be made to deal with those bugs.  So, the team was asked to come in on a Saturday, and work on resolving bugs. The deal included a significant bonus for the developer who closed the most bugs by the end of the day.

Lo and behold, on Monday the winner was announced: the person who got the bonus apparently fixed 27 recorded bugs. He also introduced many new ones, so that the next couple of weeks ended up being devoted to resolving the problems introduced on that bug-fixing Saturday. The team did not dare to record any more bugs, though, for fear of being called in to work on a Saturday again.

The developer who fixed the 27 bugs on that memorable Saturday was getting praised by the management as the most productive employee, while the rest of the team grudgingly worked to resolve the errors he (and, undoubtedly, other people too) has introduced, while the productivity of new feature development came to a stand-still. Since the new bugs were not being recorded, the situation virtually guaranteed that knowledge will be lost as time went on.

---

* The names have been omitted to protect the innocent and the guilty.

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?