Thursday, December 18, 2014

Good Agile teams break the rules


Agile frameworks are sets of rules. To become Agile, an organization or a team learns these rules, tries to understand what the rules mean, and executes according to the rules. Not necessarily in that particular order.

Good teams learn rules quickly and follow the rules well. Or do they?

Agile philosophy is all about learning, gathering information and feedback, making small changes, and gathering feedback again. As teams mature and understand the philosophy of being Agile, a rule may get re-assessed, adjusted, and sometimes even completely disregarded. The team will consider the outcome, and either go back to the previous version of the rule, stick with the updated rule, or make another change based on new learnings.

Consider this example, discussed by Mike Cohn: standard Agile rule recommends that the team works on backlog items in the order set by Product Owner. But depending on the technical details of the project, the team may be able to maximize delivered value if it is allowed to do minor adjustments to the order of stories.  

Another standard Agile rule that is often broken is to use collocated teams only. This rule is often not followed due to business constraints, and in those cases breaking this particular rule can and often does lead to serious problems. However, more mature Agile teams that choose to let some members work remotely part of the time, can stay productive and perform on par with completely collocated teams. Being able to occasionally work from home helps people concentrate, allows to save time on the commute, and overall improves enjoyment and morale of the team, which promotes better productivity.

Rules of the Agile frameworks are designed to help teams create a situation that encourages learning, taking responsibility, and enjoy their work. Teams that have developed a deep understanding of the reasons behind the Agile rules, should be allowed and encouraged to modify the rules to fit the details of their physical environment, particular complexities of the project, and organizational specifics. A mature self-managed Agile team can be trusted to develop their own rules for best performance.


Thursday, December 11, 2014

Myths and half-truths about estimates

Estimating is in our DNA. It is about the future, the knowledge, the power – all the things that make us feel in control.  Estimates are required, and are the most straightforward (or even the only) way to gain trust, and budget, to go forward.

Yet… it is an open secret that estimates are flawed. Things do not go as planned. Resources become unavailable, assumptions turn out to be incorrect, changes trickle down in a never-ending stream, and communication becomes strained.

While having flawed estimates may be preferable in some situations to having none, commitment to wrong numbers can wreck havoc on any project. If you are going to estimate, steer clear of these mistakes people frequently make, even if they have plenty of experience with estimating.

  • Myth: If your estimates are a range of dates, you are doing a good job managing expectations.
    • Only the earlier, lower, more magical numbers will be remembered. And those will be accepted as firm commitments.
    • The lower bound is usually set at "the earliest date the project can possibly be completed". In other words, there is absolutely no way the work can be completed any earlier, even by a day. What are the chances of hitting that exact date? Practice shows - close to nil. 

  • Half-truth: You can control the quality of your estimate by putting more work into producing this estimate.
    • By spending some time learning about the project, researching resources available, considering major and minor risks, one can produce a somewhat better estimate.
    • The above activities are only going to take the quality of the estimate so far.  Past a certain point, no matter how much effort goes into estimating a project, the quality of the estimate is not going to improve. Then the best bet is to simply start working on the project.

  • Myth: People can learn to estimate better, as they gain experience.
    • It is possible to get better at estimating – if one keeps estimating the same task, which becomes known and familiar with experience. This is hardly ever the case in software development. Every project is different, most teams are brand new, and technology is moving along fast enough.
      • Do not expect to produce a better estimate for your next project than you did for your last one.
      •  By the same token, do not expect a worse estimate. The quality of the estimate is going to be low, and it is going to be random.

  • Half-truth: it is possible to control the schedule by giving up quality.
    • Only for short-term, throw-away temporary projects.
    • For most projects, aiming for lower quality has a negative effect on the schedule.