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…

Retrenched?!

Yes, it seems I’ve been retrenched, not due to the current economic crisis but I think purely because there just isn’t the interest in South Africa (Gauteng specifically) for consultant ScrumMasters, or is there? I have no idea, but based on what I was told (read: sold) I thought they were lining up like kids in a candy store wanting my unique services. I cannot and do not blame anyone for this, especially my (now previous) company, I would’ve done the same in their shoes. What I would’ve done differently is perhaps dished out more of the harsh truth up front, be more transparent, that there was not, in fact, a plethora of clients waiting but only one, and yes, I know I was hired for this “one client” specifically, but really, would I have taken this if I was told that there was a risk this client would pull out of the contract and that there was no-one else lined up, and that ultimately I would be retrenched if they could not find me anything? Hell no! I would’ve kept my nice secure job and waited…

I guess lessons are learned this way, I need to be more careful in future, I was chasing a dream and totally missed the forest for the trees…

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.

Qaulity Driven Development?

I read an interesting post on Mike Cohn’s blog entitled A Requirements Challenge regarding a meeting he had with Tom and Kai Gilb. In short, from what I can tell, it centers around the idea that, as software engineers, we hardly ever, if ever at all, build new functions, but that we inevitably end up improving the quality of an existing function.

I have to say that, after thinking about it for a while, I must agree, even though I tend to find it hard to wrap my mind around the concept. Essentially the idea is to move away from a developer centric design and focus on stakeholder satisfaction. What makes stakeholders happy is quality, not only function. More important than what a thing does is how well it does it. In other words you should adopt an attitude of creating “Quality Requirements” rather than just “Functional Requirements”. There’s a lot more to it of course, but that’s my understanding in a nutshell.

Read the blog, and especially the comments afterwards…

It’s about people…

“Individuals and interactions over processes and tools”

I’ve been thinking recently on the importance of people in this whole agile “thing” (for lack of a better word). I think people lose focus of the actual PEOPLE in a team and still focus on them as resources (some nice baggage from our waterfall days). Agile pushes the concept of a team thinking and working as a unit but I think it’s easy for individuals to become “lost” in this team and forgotten. Don’t get me wrong, I agree on the “team” mentality but people should also not forget about the individuals making up the team.

A simple question, as a “leader” of a team (ScrumMaster etc..) when last have you actually tried to find out if everyone is still “happy”? When last have you interacted with the person as a person and not a resource? I think, to some degree, personal interaction is important. Take a ScrumMaster for example; one of the key things they should be doing is “removing impediments”; often people think of these as purely work centric issues but what if they’re not? What if a team member is experiencing personal issues? This will definitely have an effect on the velocity of the project so why should you not try to help (or at least be aware of it)?

I guess what I’m saying is do not depersonalize the team, reducing them to “agile resources”; make people feel like they’re not only part of a team, but that they’re an indispensable individual within that team…