Tag: Agile

Why do we do what we do?

I thought of doing a few short posts on the why’s of agile and specifically scrum. Product owners are driven by ROI, so why should we not adopt the same attitude regarding the various “ceremonies” and practices we adopt in our day to day agile development lives… why do I do <something> and what is the benefit of doing it?.

I think it’s important that people understand the rationale behind doing something (like time-boxing for example) before simply adopting it, unless, of course, you like the idea of arranged marriages 😉

Here’s a couple of starters I’ll try cover:

  • Why is it important that the team decides what work should get done?
  • Why do scrum “by the book” first, and then change it?
  • Why do we time-box?
  • Why are the roles, and the clear separation of roles, so important in scrum?
  • Why have a retrospective?
  • Why demo?
  • Why use a physical scrum board?
  • Why should the team run the scrum board?
  • Why use a tool to help you run your project?
  • Why the daily stand-ups?

and others …

Feel free to give me some answers, but I’m not really interested in someone else telling me the answers. This is more of a personal journey of discovery so that I myself can understand why I do what I do, and yes, the answers may not be perfect, but every great journey must start with a first step…

Anarchy anyone?

I was thinking today, while watching a team fail miserably at planning, that we all know what we would do if asked to choose between Agile or Waterfall; but what if you had to choose between “MakeItUpAsWeGoAlongNoRules”-Agile and Waterfall. In other words, “Aspects of Agile” vs Pure Waterfall. I’d have to say I’d go for Waterfall…

(for this next piece to work you need to understand that governments exist to control you in a coercive and violent manner)

If you lived in country that was governed by a central authority, you’d have rules in place, albeit not all pleasant, and made up by a small group of individuals, but you’d still have rules that govern everyday life. Compare this to a state of “anarchy” (the Mad Max style “no rules leather bound bike riding shotgun wielding” kind) where there are no rules, or at the most constantly contradicting rules. What would you choose? I equate Waterfall to a central authority style coercive control and “aspects of agile” as the Mad Max style anarchy. Given this choice, and for nothing more than pure “survival” (read “sanity”), I’d have to go with Waterfall!

Of course, the true nirvana is true agility, which I guess you can equate to the type of true anarchy that rejects all form of coercive control, and has a basic set of rules, related to people and interactions between people, based on universally preferable ethics.

Of course I may be way off here, but these are just my thoughts.

Done?

This is always a highly contentious and relative subject, what does a team mean when it’s DONE? This sort of popped into my head a while ago when I was contemplating how a person would go about making sure a team is actually performing as best they could, without interfering. My question was this, because Scrum is essentially a management process (and yes I know, its not only a process but also a “way of life” and a “mind shift”), and not an engineering process, a “green” team may not realize that a solid engineering process was missing from their way of working? Would it be your responsibility to point this out and prevent future technical debt building up, or should you leave it to the team to inevitably “fail” and attempt to fix the problem then?

Based on the input I had to this question I believe that part of the ScrumMasters role of ensuring process was being adhered to was to make sure the team had a well defined definition of “DONE”, and not only that they adhered to it but that they attempted to improve on it during retrospectives. “DONE” then becomes the instrument by which the team improves HOW they do things and can include good engineering practices like continuous integration, unit testing and essentially anything the team believes will improve the quality of their shippable product.

Along these lines I found a great article on the Scrum Alliance website by Mitch Lacey titled “How Do We Know When We Are Done“, which includes an exercise a team can go through to help them define their “DONE” list. I haven’t tried this yet, so I cannot speak from experience, but in principal it sounds good and I’m hoping to try it at the next available opportunity.

Are you really Agile?

I found this interesting article by James Shore:The Decline and Fall of Agile which essentially talks along the subject of people claiming to be “agile” but are not really and having this potentially destroying the true “agile” drive. People should be careful that they don’t just grab at buzzwords and ideas without realizing what they’re getting in to, especially with Scrum:

“But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt”

Read the full article, it was an eye-opener for me, and be careful, Scrum alone does NOT make you fully agile, it’s only a small step towards agility.