Share it

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.

Wednesday, November 12, 2014

The human side of enterprise

Once upon a conference, I asked a small technology business owner about the interactions his 12-person team had, and he was sincerely surprised by the question. “Why would they need to talk? I tell them what to do, and then they code, each in their cubicle.” – was his response.

We like to think about work strictly as job function-dictated activities. Gathering requirements, evaluating options, making product decisions. Meeting to discuss who does what, how hand-offs happen, what are the acceptance criteria. Org chart-based relations that dictate who is in charge, who reports to whom, and who will get the credit or blame. The result of these interactions is work product, the how-to of getting to a solution.

Yet, there is more to work than “just work”. It is also the true, human relationships we develop with people we spend a lot of time with most days of the week. A quick exchange by the water cooler about a concert, a site of a geeky new mouse pad on someone’s desk, kids’ pictures on the screen. A small group is discussing the latest smartphone while getting coffee; when waiting for a meeting to start someone mentions that she is looking for a rock-climbing gym; and somebody else is asking for advice on the user groups during lunch.  The result of these conversations are not necessarily a work product (although it could be directly useful for work, too), but the building of a team of friends.
A team comes together through learning small, personal, often seemingly insignificant details about each other, discussing experiences, finding shared interests. Working with friends matters. It is a lot easier to be open-minded and welcoming to a friend’s ideas, than to someone’s who is a stranger. Friends deal with disagreements by working together, while strangers get upset and push each other away. Knowing and liking people one works with makes everyone happier and more productive.

When the opportunities for social interactions within a team are limited, work suffers. Teams of strangers are less interested in working together cooperatively, sharing information, establishing and striving toward a common goal. There is more shirking, less innovation and leadership. And less success.