Skip to content


XProgramming is Moving – Slowly - Mon, 12/08/2014 - 10:11

As you may have noticed in the “XProgNew” articles, I’m moving the XProgramming site from WordPress to a static site. The main reason for this is to get it under control for a few more years,and out from under the WordPress update cycle and the legacy WP scripting that makes it what it is.

I also own The plan is to move all the content from here to there, then to begin to redirect from here to there, and finally to point directly there.

This will happen incrementally, and this site will not disappear any time soon. New material is already appearing on, however.

We anticipate that existing article links from here will ultimately work there, at least if they work here now. There are, unfortunately, some things that have already been lost or mislaid over the years and versions of this site. Some of these articles will likely re-appear, since they’ll be in the WordPress export even if you can’t find a link to them.

Except for this one, which I’m sticking to the top of the page, new articles will appear on, and not here. I’ll be grateful if you’ll watch it for new material. There’s already an interesting series on the Diamond Problem (or Diamond Kata), and other articles as well.

The site is evolving in content and style, as we learn what works and what we like. It will benefit from your feedback via email and if you can begin to link to it, that will help as well.

Thanks … see you there as well as here!

Categories: Blogs

Emergent Design - Sun, 11/02/2014 - 22:53
Then and now

In a recent email, Martin Alaimo asks:

There’s a very interesting discussion on the latin america agile community going on. It’s about the meaning of the Agile Manifesto Principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”

What is currently under discussion is the meaning of “emerge”, basically, what does it mean that the “architecture emerge”.

So, I would like to reach up to you to share your impressions as a Manifesto signer. Here are two questions, but feel free to add whatever you feel is needed:

1) Back in 2001, at the time of signing the manifesto: what was the sense in which the word “emerge” was used in regards to the architectures?

2) After 13 years, is there anything you’d change/adapt/add in regards to “architecture” in the agile world?

I can’t speak about what everyone was thinking. I’m not sure what I was thinking. Here’s what I, and we, may have had in mind. Or maybe what I have in mind now.

Historically, the heavier approaches to software development have included a separation of architecture and design from “mere coding”. We felt that was far from ideal. Programming is the process of expressing design in some language. Just as our thoughts shape our words, our words shape our thoughts. The end of the sentence is conditioned not just by what we thought we wanted to say, but by how we begin to say it. And sometimes we go back and rewrite the beginning, because of what we find at the end.

The paragraph above is an example, because I didn’t go back to revise it. It’s an example of something that needs refactoring. It starts out being about software and turns into something about language and thought influencing each other. This part of the article might be better designed with the language bit first and then a segue into the software analogy. But I’m not going to do that, to show how a text can call out, or at least whisper, to be changed. That’s part of what we were concerned about.

However, where I thought I was really headed with that paragraph was to the people. In software, it’s the people. Maybe I’ll get there … but not yet.

We perceived, back at Snowbird, that the code needed to influence the design. It wasn’t a one-way street. No matter how much design we did on its own, as soon as we began to express it in code, the design needed to change. We expressed it as the code telling us what the design wanted to be. Very anthropomorphic. Very metaphorical. We knew that. Almost none of us really heard the code talking to us. (That one guy: You know who you are.)

These design discoveries continue to come, throughout the life of the project, if you stay open to them. To stay open to them, you have to keep the code alive: thus refactoring. However, to stay open to them, you also need strong designers in the room, listening, when the code speaks.

And voila! There are the people. I was sure they’d turn up. The people need to be self-organizing. And they need to have the ability, not just the right, to improve the design. They improve the design over time. It changes. It emerges.

If the program is to stay alive, design must change, it must emerge. If this is to happen, the team must do it. If the team is to do it, they must be organized to do it. The best way to organize is in response to the moment. To respond in the moment, you need to be in the moment.

A self-organizing team is the best way to keep the team in the moment, the best way to respond to the moment, the best way to improve the design in the moment it needs it.

The best results emerge from self-organizing teams.

Categories: Blogs

Candy or Death: The Automatic Halloween Candy Dispenser

Radyology - Ben Rady - Thu, 10/30/2014 - 05:59
Let's start with a word problem. Assume you live in a busy trick-or-treating neighborhood and that, on average, a group of four rings your doorbell every minute and takes 1/2 oz of candy per person. If you leave a bowl... Ben Rady
Categories: Blogs

XProgNew – Pivot? - Tue, 10/28/2014 - 11:06

Experience with Sinatra, and some thinking, has caused us to look at a shift in approach. Martin Fowler was probably right.

Early in this project, Martin wrote to me, asking “why dynamic” and offering his bliki software for my use. My answers were that to get my hands dirty, I really wanted to do it myself, and that I chose dynamic solely on the principle of late binding. I’ve somewhat come to my senses.

I am a very old person, which I hope is not in any way noticeable, despite my desire that you all keep off my lawn. I came to realize that while I hope I’ll be writing and drawing stupid pictures for a long time, I will probably not be wanting to fiddle with configuring Ruby/Sinatra/Kramdown/etc on my web site for very long at all. In fact, I already don’t want to do that. I also don’t want to maintain the WordPress stuff that is there now, especially since my webmistress (not as interesting as it sounds) is leaving the area.

Therefore, I decided that I wanted a static site. Some software now, to generate it, but push come to shove you can push new articles up with FTP or similar tools, so it will be relatively maintainable ad infinitum.

(I freely grant that I could be entirely wrong about all this. Nonetheless, static is hopefully here to stay.)

So, a bit of looking and we’ve settled on Jekyll as a basis for the site. In second place, Middleman, which I rejected on the basis of its (non-) documentation. In third place, just code it up. Code it up is running strongly and could catch the leaders.

Starting on

Happens I own (No, don’t bother to buy up all the other ronjeffries.etc, and sell them to me at a profit. Dot com will do me just fine.)

So the current plan is to build up incrementally. We’ll deploy it as soon as my host can get it set up. He’s a bit overwhelmed with personal matters just now but I want to stick with him.

The site wants to integrate XProgramming, new material, maybe even my tumblr. So it needs to be able to support something not unlike the current organization. All the articles (at least the ones I decide to keep), and a bit of organization, done with categories in WP.

However …

Jekyll doesn’t quite want to do all that, at least not at first glance. Let’s revisit the requirements.

My existing site has the notion of general articles and three special kinds: Kate, Beyond, and Classic. The front page shows the most recent Beyond, the most recent Kate, a random Classic, and then, after that row, the five or six most recent other articles. I think I’ve mentioned in previous articles that those groupings may not be quite right, but the basic idea applies.

Jekyll, it seems, is “blog aware”. What that means in practice seems to be that much of its capability revolves around having a list of posts named 2014-10-11-foobar, and laying them out in a typical blog style. Next/prev, dated indexes, and the like. All very well and good but not quite what I’m about.

I write a bunch of articles about generally Agile topics. Those ought to be some kind of category, perhaps the Beyond heading, perhaps not. There might be threads. I write series of coding things like the recent ones with Codea. These generally don’t go anywhere, they just display how I’m approaching developing something over the period where I play with things. (I should probably say at the beginning of each of those that it will not have a nice live happy ever after ending, because when I get bored with that tool or topic, I’ll stop.)

I write Kate Oneal stories. I write other themed things.

Each of these needs an index page, and some of the lists are long and courtesy suggests the index should be paged.

And I have a writing requirement, or at least writing desire, which is to put each article and its associated pictures in its own folder. This makes writing easier (currently using Sublime Text and Marked) because I can view what it looks like as I go, and can push it up without worrying about name overlap in an images folder.

I plan to have the article “slug” (which I guess means web-compatible name) be the name of the folder, and in a great concession, I am prepared to name all the articles index.markdown, each in its own folder. I’d rather give them a meaningful name but at least right now I’m not seeing quite how to make that happen in Jekyll.

And I really don’t want to call them all 2014-10-11-whatever, though perhaps I need to get over it.

What’s there and what’s apparently not

It’s early days with Jekyll, we just talked about it via email a tiny bit last week, read some stuff, and I tried some things yesterday. Here’s what I think I have learned.

Jekyll will scan your whole input folder structure and process files you tell it to, and will process any file that starts with some YAML. It digs down through nested folders at least as well as I need it to.

But inside the standard _posts folder, it will only process files with the date prefix format, as far as I can tell. That is, a file containing YAML but not named by the date standard, gets ignored entirely. It’s not even copied over raw. In other folders, Jekyll processes the text files and copies others such as images. So inside posts, I’d be stuck with the dated names. I really don’t want to go there.

In other folders than _posts, it processes most everything, so I can put all my articles under, say “Articles” and they’ll all get run through kramdown and rendered to html. They can have categories, and other goodies in the YAML, so maybe a flat structure would be enough.

And there are “collections” in Jekyll. They are red-flagged with markers saying they might change. What seems to maybe happen (based on a limited experiment) is that you can name a collection in your config, then have a folder of that name, and everything inside it goes into the collection. Then you can process that collection in your templates and includes.

Where are we?

We’re in very early days in Jekyll, just finding our way. Today will be our first day pairing with it. Should we just use categories or the like to sort out the Kates from the Beyonds? Should we use collections?

We’re not sure. I’ll report more when I know more. Meanwhile, if you know stuff I should know about Jekyll, please drop me an email. Thanks!

Categories: Blogs

Uh Oh... We Discovered More Stories!

Practical Agility - Dave Rooney - Sat, 10/11/2014 - 18:00
As I've said before, I'm a huge fan of Jeff Patton's Story Mapping technique. While Story Mapping goes a long way towards identifying the work that needs to be completed to deliver a viable system, you will inevitably miss some stories. This is a natural outcome of the discovery process that is inherent to software development. When you discover that some functionality is missing or
Categories: Blogs

Refurbishing a Mail Slot and Doobell

Radyology - Ben Rady - Fri, 09/26/2014 - 15:01
When I moved into my house, the mailbox was in pretty sorry shape. It was corroded, and the mail flap was stuck open. On top of that, it had an integrated doorbell that didn't work. Lastly, the entire border of... Ben Rady
Categories: Blogs

How to Enable Estimate-Free Development

Practical Agility - Dave Rooney - Wed, 09/17/2014 - 20:06
Most of us have been there... the release or sprint planning meeting to goes on and on and on and on. There is constant discussion over what a story means and endless debate over whether it's 3, 5 or 8 points. You're eventually bludgeoned into agreement, or simply too numb to disagree. Any way you look at it, you'll never get those 2, 4 or even 6 hours back - they're gone forever! And to what
Categories: Blogs

How I messed up a medium-scale refactoring

Exploration Through Example - Brian Marick - Fri, 05/16/2014 - 01:20

Suggie is a back end Clojure app that is responsible for maintaining eight collections of stutters. The collections live in Redis and are consumed by two front-end apps. What goes in which collections, and how, is governed by a number of business rules. For example, one kind of new stutter produces two entries in one of the collections: the first being the new stutter and the second being an old one selected by a Lucene search.

The collections and business rules were added one by one. I wasn’t vigilant enough about keeping the code clean as I added them. At a point where I had a little bit of slack, I decided to spend up to two ideal days cleaning up the code (and adding one small new feature). I failed and ended up reverting about 70% of my changes.

What have I learned (or, mostly, relearned)?

Let’s start before I started:

  • It’s clear that I let the code get too messy before reacting. I should have made a smaller effort, earlier, to clean it up.

  • In general, I find that switching out of the “coding register” into the “explaining register” (talking vs. typing) helps me realize I’m going into the weeds. Because we’re a two-programmer shop, with only one of us (not me) competent at the front end, and we’re under time pressure (first big release of product 3, going for series A funding), I worked on Suggie too much without discussing my changes with Colin.

  • Relatedly, pairing would have helped. Unfortunately, Colin and I are of different editor religions - he’s vim, I’m emacs - and that has a surprisingly negative effect on pairing. We need to figure out how to do better.

As I did the refactoring, I’d say I had two major failures.


I read over the code carefully and made diagrams with circles and arrows and a paragraph on the back of each one explaining what each one was. That was useful. But what I under-thought was the trajectory of the refactorings: which ones should come first, which next, so as to provide the most “You’re going askew!” information soonest. (Alternately: get the most innocuous and obvious changes out of the way first, so that they wouldn’t distract/tempt me as I was doing the more challenging ones.)


I realized there were four design issues with this code.

  1. The terminology was out of date. (Bad names.)

  2. There was the oh-so-common problem that all the communication with Redis had gotten lumped into a single namespace (think “class”). The same code that put stutters into Redis hashes put ordered sequences of references-to-stutters into Redis sorted sets - and also put references-to-stutters into Redis plain sets. The code cried out to be separated into four different namespaces. Alone, that would have been a straightforward refactoring. But…

  3. But there was also the problem that the existing code was inefficient, in that it didn’t make good use of Redis’s pipelining. I want to be clear here: our initial move to Redis was motivated by real, measurable latency problems. And the switch to Redis was successful. But now that we were committed to Redis, I fooled myself in a particular way: “Efficiency’s good, all else being equal. We don’t know that we need pipelining here, but I see a pretty clear path toward just dropping it in during the refactoring that I’m doing anyway. So why not do it along the way?”

    Why not? Because, as it turned out, I’d have gone a lot faster if I’d first solved either problem 1 or 2 and then made the changes required to add pipelining. (That’s what I’m doing now.)

  4. Much of our Redis code is not atomic, which needs to be fixed. I decided I’d also fix that (for this app) at the same time I did everything else. As I write, that seems so obviously stupid that maybe I should find another profession. However, I convinced myself that this new refactoring would fall easily out of the pipeline refactoring (which would fall out of the rearrangement refactoring). In retrospect, I needed to think more carefully about atomicity without assuming that I really understood how it worked in Redis. But, again, I assumed I could learn that as I went.

So I mushed up many different things: renaming, moving code to the right place, introducing more pipelining, and keeping an eye out for atomicity. My brain proved too small to keep track of them. I should have sequenced them.

In addition to all that, I noticed some other things.

  • I would have done better to spend an hour a day over many days, rather than devoting full days to the refactoring. Because I have a compulsive personality, I must be forced to take time away from a problem to make me realize exactly how far down a rathole I’ve gone. (Alternately, I need a pair to reign me in.)

  • I kept all the tests passing, and I kept the system working, but I made a crucial mistake. There was a method called add-personal-X-plus-possible-Y. (The name alone is a clue that something’s gone wrong.) It was 16 lines of if-madness. Instead of modifying it (while keeping the tests passing and keeping the system working), I kept the system working by not changing it. I added a new function that was intended to be a drop-in replacement for it - come the glorious future when everything worked. So there was no connection between “system working” and “tests passing” while I was doing the replacement. The new function could have been completely broken, but the system would keep working, because the new function wasn’t used anywhere outside the tests.

    This seems to me a rookie mistake, a variant of “throw it away and rewrite it”. But somehow I allowed myself to gradually slip into that trap.

  • I suffered a bit from relative inexperience with the full panoply of immutable/functional programming styles. What I’d written was C-style imperative code. Transforming it into object-oriented code would have been straightforward, given my familiarity with various design patterns. Figuring out how to do the equivalent transformation idiomatically in Clojure, given all the constraints I’d placed on myself, took me too long. I only really figured out how to do it after I’d pulled the Eject lever.

Here’s something that’s interesting to me. I spent many years as an independent process consultant. In my spare time, I wrote code. Because that was a part-time thing, I had a lot of leisure to put the code aside and listen to that small, still voice telling me I was going astray.

Things are different now. This real world job has only strengthened my belief in what I preached as a consultant. In particular, I believe that teams must have the discipline to go slow to get fast. And yet: I keep going too fast. These days, it’s markedly harder for me to attend to the small, still voice.

It’s an interesting problem.

Categories: Blogs

More Thoughts on Power

Complex and Agile - Joseph Pelrine - Sun, 04/20/2014 - 09:31

In my last blog post on the different types of power (here), I noted that it is more advantageous to focus on increasing expert and referent power than the other power bases. I’d like to look at this in a bit more detail here.

Power bases may be divided into two categories

-       positional, i.e. situations where a person is in a position to have power
-       personal, i.e. situations where a person’s power is intrinsic in nature

Reward, coercive, and legitimate power are all positional in nature. To have them, one must be in a position to reward or coerce, or to have legitimate authority. Raven’s later addition, information power, is also positional in nature (Raven, 1965). Personal power bases are, in a way, easier to increase, as the effort required is purely personal, and does not always require outside help. This being said, which of the 2 personal power bases should one focus on increasing?

Benfari et al. (1986) define power relatively simple as “the capacity to influence the behaviour of others”. For them, power is value-neutral. Power is also interpersonal; it requires (at least) two individuals, whose power interactions may be reciprocal or one-sided. For individuals, power exists as two aspects: as a motive, and as a behaviour, and either aspect may be disturbing to the person(s) on the receiving end.

The need for power exists in all of us to a greater or lesser degree. Simply having control over one’s own life is a form of power. Problems start when the urge for power increases, when the desire for power becomes a motive or driving force for someone’s actions, up to the point where it becomes pathological (e.g., as seen in too many politicians). When power is exercised and manifested as influence, it becomes a behaviour in itself. Even though power may be value-neutral, the response to power actions may be positive (P+) or negative (P-) for the recipient, and will thusly change the recipient’s view of the wielder of the power. For example, consider expert power. We have all profited at some time from the advice of an expert, but how often have we experienced someone flaunting his expertise as a know-it-all?

The recipient views the power as negative if he feels a sense of being exploited or manipulated. If the recipient views the power as positive, i.e. when the recipient benefits from the power, he feels support, increased motivation, and an ego boost.

Different types of power have different positive and negative aspects. Reward power is only positive, coercive power only negative. Benfari et al. list 7 types of power – in addition to the 5 classic types described by French and Raven, they include Raven’s information power, and add what they call “affiliation power”. This type of power is similar to the concept of centrality in social network analysis (Bonacich, 1987), and describes the power a person has by virtue of their access to other persons of power, by being affiliated with them. (n.b. Benfari et al. also mention the power of groups. Since this is not an individual power base, we’ll look at it in a later post, but not here).

Power base Explanation Perceived as Reward Positive strokes, remuneration, awards, compliments, other symbolic gestures of praise P+ Coercion Physical or psychological injury, verbal and non-verbal put-downs, slights, symbolic gestures of disdain, physical attack,demotion, unwanted transfer, withholding of needed resources P- Legitimate Management right to control, obligation of others to obey, playing ‘the boss’ and abusing authority P- Exercise of leadership based on authority in times of crisis or need P+ Referent Identification based on personal characteristics, sometimes on perception of charisma; or reciprocal identification based on friendship, association, sharing personal
information, providing something of value to the other, and on common interests, values, viewpoints and preferences; creation of reciprocal ‘IOUs’ P+ Expert Possession of specialized knowledge valued by others, used to help others, given freely when solicited P+ Unsolicited expertise, seen as unwarranted intrusion; continual use can create barriers; expertise offered in a condescending manner can be seen as coercive; withholding expertise in times of need P- Information Access to information that is not public knowledge, because of position or connections; can exist at all levels in the organization, not just at the top; those at the top may know less about what is going on; secretaries and personal assistants to senior executives often have information power, and can often control information flows to and from superiors P- Affiliation ‘Borrowed’ from an authority source with whom one is associated – executive secretaries and staff assistants act as surrogates for their superiors; acting on the wishes of the superior P+ Acting on their own self-interest; using negative affiliation power by applying accounting and personnel policies rigidly P-

Source: Based on Benfari et al. (2001)

As can be easily seen from the table above, the only types of power that are considered purely positive are reward and referent power, and of these, only referent power is personal-based. This provides a good argument for a focus on increasing referent power if you want to be able to help your clients’ teams, and co-workers. In my last blog post, I mentioned a number of core competencies to concentrate on for increasing referent power. Here are some other tips from Benfari et al.

  • Get to know the motives, preferences, values and interests of colleagues.
  • Build relationships using shared motives, goals and interests.
  • Build large networks of people and information – make connections between individuals and between individuals and different stakeholders.
  • Respect differences in interests, and points of view-don’t attack – invite reciprocity.
  • Give positive strokes, use reward power, confirm others competence.
  • Share information and expertise with others.
  • Minimise concerns with status.
  • Develop communication skills – assertiveness, meta-communication, question asking, clarity and rapport.
  • Manage your impression – dress, body language, facial expression, voice one, etc.
  • Develop understanding of how people tick – e.g. body language, use of language, ‘trigger points’.
  • Develop an understanding of systemic deep dynamics and implicit information channels – know what you are sitting in in any given moment.
  • Demonstrate congruence between espoused values and behaviours.
  • Develop ability to take risks and lead on issues – even if it is lobbying for an idea within a meeting.

Sounds like good advice for anyone wanting to become a better ScrumMaster, doesn’t it?


Benfari, R.C. et al. (1986) The Effective Use of Power. Business Horizons, 29, 12.
Bonacich, P. (1987) Power and Centrality: A Family of Measures. The American Journal of Sociology, Vol. 92, No. 5, 1170-1182.
Raven, B.H. (1965) Social influence and power. In Current studies in social psychology, (Ed, Steiner, I.D.F., M.) New York: Hoh, Rinehart. Winston, pp. 371-381.

Categories: Blogs

Authority and Power

Complex and Agile - Joseph Pelrine - Fri, 04/04/2014 - 13:06

One of the classic sayings in Scrum is that the ScrumMaster has no authority. He cannot tell his team members what to do, or what not to do. In a way, this makes sense. If the ScrumMaster had the authority to tell people what to do, he would take away their opportunity to take responsibility for their actions, to become committed and not just involved. Looking at it differently, by telling team members what to do, he would give them the chance to refuse responsibility for their actions. “It’s not my problem, he told me to do it!” Even though the ScrumMaster has no authority, this does not mean that he has no power.

Power cannot be taken, it can only be given. A person only has power over you if you give them this power over you. Being aware of the ways you give people power over you will help you avoid doing it unintentionally or inadvertently. So, what types of power may a person possess, and which types of power should one best focus on increasing?

In 1959, John French and Bertram Raven wrote a seminal paper on the different types of power (1959). According to French and Raven, power is defined as the potential ability of one person to influence another person. Thus, power is potential influence, while influence is kinetic power.

In their paper, French and Raven define five different types of power, all of which may vary in their domain, strength and range.

Reward power. You gives a person reward power over you when you believe that they can do something good for you or they can take away something bad. Obviously, if the person actually does do something good for you, his or her reward power over you increases.

Coercive power. You give a person coercive power over you if you believe that the person can do something bad to you, for example, cause you harm or pain. If the person actually does something bad to you, their power over you increases. The mere awareness or threat of coercive power is often enough to enforce compliance. Imagine if you were driving a car and you saw a police officer standing on the corner. Even if he was not looking directly at you, you would tend to drive slower.

Legitimate power. You give a person legitimate power over you if you believe that they have the right to have this power. This right often comes as the result of an implicit or explicit social contract. An example for an implicit social contract would be a contract that parents have with their children (although as every parent knows, this contract must be renegotiated regularly). An explicit social contract would be your work contract, which gives your boss power over you. As one can see, legitimate power contains both reward and coercive components. If you do something good at your job, you may get a bonus. If you do something bad at your job, you may get fired.

Expert power. You give a person expert power over you if you believe they have superior knowledge relevant to the situation and to the task at hand. This power rarely extends outside of the domain of expertise, but the implied transference of expert power into other domains is a technique often used in advertising.

Referent power. Referent power is the most difficult type of power to describe. It is best understood as a type of power that comes from personal integrity and/or from charisma. This is the type of power that Gandhi or Nelson Mandala or Martin Luther King had. Over time, though, the power these men had became legitimate power, as they were voted into political office.

In his later works, Raven added a sixth type of power, which he termed informational power. Having access to information, and the ability to use this information, can give a person power. As an example, think of Edward Snowden.

Looking at the different types of power, one sees that they can be grouped into two groups – positional power, which is power one receives as the result of being in a position to have the power, and personal power, which is not dependent upon position, but solely dependent upon the person. If you want to increase your power base, in order to better help people, then which type(s) of power should you focus on increasing?

Being in a position to give a reward or to coerce, or being in a position of having the right to legitimate power, puts one in the position to command others. This is not the type of power a ScrumMaster should use. This is the reason why no one who is in a management position can be a ScrumMaster for his team. It is better to focus on increasing your personal power than on increasing your positional power.

How can you start increasing your personal power? You can increase your expert power by concentrating on your continued professional development. Reading, keeping up to date on new developments in your field, attending trainings, etc., are all ways of increasing your expert power.

Increasing your referent power can be done by focusing on your continued personal development. This is a noble task whether or not you work as a ScrumMaster, since furthering your personal competencies will increase your feeling of well-being. Awartani et al. (2008) define well-being as the realisation of one’s physical, emotional, mental, social and spiritual potential.

Mental or rational well-being as that part of life which is primarily related to thinking and cognition, and to the processes of the rational mind, e.g.: planning, understanding, focusing, envisioning, abstraction, reflection, evaluation.

Emotional refers to the intrapersonal or inward-looking awareness and processing of feelings, of understanding your feelings, their triggers, and your reaction patterns, of having your emotions under control, and not being “hijacked” by them.

Social refers to the interpersonal or outward-looking awareness and processing of feelings, of understanding how they influence our interactions with others.

Physical refers to those aspects of life related to the physical senses and to sensory experience, to our bodies, and to the material and natural environments. The actions and functions of doing, building, taking apart, detailing, producing, acting, and making practical are included.

Spiritual is not necessarily a religious or esoteric concept, but refers to life, to its meaning and purpose, to beliefs and what one believes in. You are believable for others when they feel that you believe deeply and strongly in something.

Although all these aspects each play a role, well-being represents a pervasive feeling about oneself, one’s life, and one’s environment. You can start right now and take a first step towards your own well-being. Take a few moments to think about these 5 areas, where your strengths and weaknesses are, and which areas you want to focus on strengthening.


Awartani, M. et al. (2008) Developing Instruments to Capture Young People’s Perceptions of how School as a Learning Environment Affects their Well-Being. European Journal of Education, 43, 51-70.
French, J.R.P.Jr. & Raven, B. (1959) The Bases of Social Power. In Studies in Social Power, Ann Arbor, Michigan: Institute for Social Research, University of Michigan, pp. 150-167.

Categories: Blogs

Agile2014 Submission: Agile for Educators

Screen Shot 2014-01-15 at 12.24.50 PM

Agile2014 is only 6 months away!


That might seem like a long ways to go, but if you’re submitting a presentation or workshop for the conference, you know that last night was your last chance to propose a session. I know because I actually finally did it. It took some convincing and discussing with some good friends, and a generous agreement by Jimi Fosdick of Fearless Agility to co-present with me, but I did it!


The topic is one I’m really passionate about – agile in an educational setting. I had the privilege of presenting an Agile/Scrum training to a group of high school teachers in October and November of 2013, and the experience was life-changing. The teachers were all Technology teachers, meaning they taught classes like digital media, computer science, web development, networking, etc. The premise was that agile methodologies like Scrum could benefit them in two ways:

1) As a tool when planning and executing their curriculum for the year/semester

2) Providing an agile framework they could teach to their students to improve their challenges with project-based learning. I.e., the students could apply it to the projects they work on for their classes, since they worked in groups/teams

The teachers were amazing. They were engaged, interested, and willing to experiment. I can’t wait to share details of the experiment with others and continue to improve and expand upon the effort.


Jimi, on the other hand, has worked with educational technology for 5 years, and has also been working with education professionals and scholars on finding ways to apply agility (specifically Scrum) in an educational context. His work in this field is a critical part of this presentation – taking it from the what-if to the here’s-how-it-can-be-done.


Now comes the waiting game part. There are some amazing speakers, presenters, and topics that have been submitted for this year’s conference, so no matter what happens, I can’t wait to attend the conference in Orlando and continue to learn, grow, and connect with friends (old and new) along this journey of agility!

Cross your fingers for me!

Here’s our submission:

Agile for Educators Presenter: Hala Saleh Co-Presenter: Jimi Fosdick Track: Research Session Type: Talk Audience Level: Practicing Room Setup: No Preference Duration: 75 minutes Keywords: Agile, scrum, students, education, teachers, curriculum Abstract:

This session is a real-world, where-do-we-go-from-here exploration of applying agile concepts and frameworks in the classroom.

This presentation will cover two main aspects of agile in Education:
1) Applying agile concepts (specifically Scrum) for the planning and execution of educational curriculums and teaching plans
2) Teaching educators about agile frameworks (specifically Scrum) and how to apply them in their classrooms for student projects

Hala has hands-on experience with delivering Scrum training to high school teachers and working with them to investigate and coach them on the uses of Scrum with their classrooms. She is excited about the application of Scrum in a non-software context and wants to spread the Agile Manifesto for Education.

Jimi worked in educational technology for 5 years and learned more about education and educators than any non-teacher should ever know. He was been working with his sister (a program director for a school for special needs children) and his uncle (a professor at San Jose State University) in finding ways to apply agility, specifically Scrum, in educational contexts. This presentation represents a theoretical overview of his discoveries and, more importantly, why agility can and should be used outside of software.

Information for Review Team:

The session will be split where 1/2 of the time will be spent covering research and work that has been done to figure out how agile concepts (specifically Scrum) can be used for the planning and execution of educational curriculums and teaching plans.
The second 1/2 of the class will cover a real-life scenario where Scrum was taught to a group of high school teachers, and they were given the assignment to use the framework with their own students. This will conclude with an exploration of the outcomes as reported by the teachers, and a review of artifacts shared by the teachers.

Prerequisite Knowledge:

A working knowledge of agile concepts and main methodologies is encouraged. The session covers Scrum, so a knowledge of Scrum is helpful.

Learning Outcomes:

  • Part I:
  • Describe the basic principles of primary, secondary and post secondary educational development projects
  • Describe the applicability of agility in an education context
  • Build a basic curriculum skeleton using an agile approach
  • Part II:
  • Experience Report of delivering Scrum training to high school teachers
  • Overview of materials presented to teachers and most effective use of time when training
  • Overview of format & outcomes of presentation
  • Review of teacher feedback and results of check-ins with teachers on student progress and project results
Presentation History:

Hala Saleh has presented at local PMI Chapters, as well as co-presented with Jimi Fosdick (Co-presenter) at Agile 2012.
Jimi has presented at most Scrum Gathering and Agile conferences in the past 5 years.

Categories: Blogs

HoW do you estimate an agile project?

Agile Estimator - Thu, 01/09/2014 - 04:51

HoW is the sixth W. I posted the above framework in Composing an Agile Estimating Process. There are many ways that this framework could be instantiated.

    In fact, there are many ways that this framework must be instantiated:

  • Projects might be new development or enhancements to existing systems. We would expect to expend more effort to develop a a system with 10 screens, than to simply add a new field to those same reports if they already existed.
  • Implementation might be done using agile techniques or traditional planned development. If different techniques always took the same amount of time, then why all the excitement over agile development?
  • Other considerations might favor the use of function points, use case points or some other sizing measure. For example, the work might be outsourced to an entity using function points as part of some type of service level agreement with the outsourcing company.

At this point, I will describe the one that I designed to estimate new development projects that would be implemented using agile development techniques.

    A description of the major functional blocks follows:

  • Estimate Size – is done by using the Early Lifecycle Functionality Estimating (ELFE) process. ELFE estimates IFPUG function points based on the initial user stories that are typically developed early in an agile project. If user stories have not been generated, then there is a companion technique called Elf Poker that can be used in a collaborative fashion to generate these initial stories.
  • Estimate Effort and Duration – can be done by using any of a number of parametric models that estimates agile development time and can be driven by function points. Using COCOMO II and CORADMO is as good as any and better than most. COCOMO II takes the size in funciton points and some other factors and calculates the effort and duration for a traditionally planned project. CORADMO takes the output from COCOMO II along with some other factors and re-estimates the effort and duration for the project if it is done using an agile development approach.
  • Schedule Resources – is often done by hand because many parametric models are not tuned to particular agile methodologies. If the team is working in Scrum, then the organization of the team must be designed. Will the scrum master be part time or full time? The same thing must be decided for the product owner. The length of the scrums must be planned. They will probably be standard for the organization, but they are not currently standard for the industry.

Over then next few weeks, I will post the steps that make up the ELFE methodology. They are already in my dissertation. However, this version will be rewritten to make them more usable by practitioners.

Categories: Blogs

Hello world!

Agile Fun - Jurgen De Smet - Tue, 10/15/2013 - 09:50

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

Categories: Blogs

CITCON Turin Registrations Open!

Paul Julius - Tue, 09/03/2013 - 23:08

Open Spaces Board

Open Space conferences naturally cater their agenda to exactly the people in attendance.

We just finished with CITCON Boston, and now we are headed to Italy for CITCON Turin! September 27 & 28 at the TalentGarden Torino.

Marco Abis volunteered to help find a great venue in Turin. The entire organizing committee and I are excited to bring CITCON to Italy for the European leg of the conference this year.

CITCON Turin will round out the 8th year of CITCON’s around the world as the 21st instance of the conference. A lot has changed in 8 years. A few highlights come to mind:

  1. Fewer discussions about “What is CI”
  2. More discussion about “What is CD”
  3. I can remember as far back as 2002, colleagues at ThoughtWorks were discussing how to take CruiseControl and Continuous Integration to the next level. They had already played out the limits of traditional CI. They were looking for ways to take the same principles all the way down the pipe to production. The concept had a few names over the years – CI ++, Enterprise Continuous Integration, Continuous Deployment. Personally, I am grateful to Jez Humble and Dave Farley for getting their book published! Finally we have a name for it – Continuous Delivery.

  4. More discussion about DevOps
  5. I think Patrick Debois coined the term when he created DevOps Days after attending CITCON Brussels. A name can say a lot, as we see with Continuous Delivery. People are still trying to figure it all out, as indicated by Jez’s post on the oxymoronic phrase “A DevOps Team”. CITCON provides us professionals with another venue to hash it all out.

  6. More in-depth Automated Testing discussion
  7. Testers (QA Engineers, etc) are stepping up in droves to integrate their work into CD pipelines. They are pushing the boundaries of platforms like Selenium using services like SauceLabs. They are expanding their natural language approach to testing with Cucumber, etc. Coming from my developer background, I’m excited to see the practice securely taking hold in the testing arena. That’s one of the main reasons for the “T” in CITCON. We felt that CI wasn’t enough. We need the testers to unify around a common vision of keep the code working. We mean truly working, not just compiling!

So, join us in Turin for CITCON Number 21. Help us keep moving the boundaries of professional software delivery! See you there!

Categories: Blogs

An anatomy of a successful retrospective

It had been a while since I last facilitated a retrospective. So, I wanted to make sure that I can deliver and prepared properly. I had a few ideas of my own and few based on short discussions I had had what the retrospective should address.

The scope was quite large so I couldn’t use any specific way of gathering information and insights. I had to allow room for a very wide variety of topics.

Without further ado here is the skeleton I used for the retrospective.

  1. Get a mood reading (max 5min)
  2. Gather insights (max 10min)
  3. Decide what to do (max 35min)
  4. Form an improvement backlog (max 5min)
  5. End with a different goal in mind (max 5min)
Getting a mood reading

I wanted to know and I wanted the participants to know what are the prejudices we are working with. I used the EVSP (Explorer-Shopper-Vacationer-Prisoner) as the ice breaker. With a closed vote everyone wrote down a single letter defining their current attitude towards retrospectives at the moment. Here are the results:

ESVP results

Getting something to chew on

Then it was time to move forward and start to gather information to support our aims. Due to the amount of issues known in advance I decided to include last two sprints (we have 2 week sprints) in our time-line exercise. I had two different coloured sticky notes: green ones to signify memorable events and yellow ones to signify meaningful events. Time-line itself was very simple with only two dimensions: time and impact. Time runs from left to right and impact from top to bottom. The higher the note was placed the better the event was and the lower it was placed the worse the event was.

In small groups, 2 or 3 persons, people started and recalled the most important moments and placed them properly on the whiteboard with respect to both the time axis and the Good-Bad axis.

Timeline of 2 last sprintsNow we had something real and concrete to work with.

Morphing events into concrete form

After we had looked into our near past it was time to turn the history into actionable issues. I had prepared one whiteboard with three columns: Stop Doing, Start doing and Keep Doing. I told the team to use the info we just had gathered and by themselves write sticky notes containing issues that mattered to them. I instructed them to keep the notes secret until placed on the whiteboard. The notes were placed one at a time so that we could discuss each and every note immediately.

Ta-daa! We had concrete issues we could address! Next I lead the team to find themes within the notes. You can see the notes that address the same issue connected on the image. This proved to be extremely fruitful and good discussion and analysis followed.Start doing, stop doing, keep doing!

Then it was time to create our improvement backlog. I gave the team 5 minutes to create actions based on the discussions and notes on the three columns.

If you look closely, on the right corner of the image you can see a bunch of red notes. Those notes are the actions that the team found. They are prioritized based on importance and effort required. Effort is significant here, very often the actions are such that the team can not accomplish them alone. Thus, it is very important to have actions that can be implemented immediately.

Ending the show

We had found really good candidates for the team to improve on and it was time to move on. We’ve had all kinds of retrospectives from good to bad to boring so it was appropriate to give the team a possibility to improve on the retrospectives. So, the last item was retrospective process improvement, what is good and what needs to be changed.

Retrospecetive process improvement

Got some very good feedback, ideas and improvement suggestions :)

Required ingredients?
  1. Preparations in advance
  2. Storyline sketched
  3. Neutral facilitator
  4. Fearless people

I had prepared the team room in advance, 2 whiteboards and 2 large paper sheets, enough sticky notes and pens/markers. Timer for timekeeping and enforcing time-boxes. Healthy attitude so that I could leave myself out of the retrospective even though I am a team member. Gentle guidance to allow everyone the chance to speak up.

I was pleasantly surprised how well this went and I want to thank my team for excellent attitude and a sincere desire to improve and discuss even the most difficult subjects. There’s definitely improvement ahead!

None of this would have been possible without the help of the excellent book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. I recommend it for everyone interested in retrospectives.

Categories: Blogs

The Zone Considered Dangerous

Most programmers know what is “The Zone”. It is a very focused state of mind where you feel that there are no problems that you cannot solve. You know, the state where your surroundings disappear and you feel almost omnipotent. You are very productive, take great leaps and progress fast.

I posit that this is a dangerous for a couple of reasons.

Too tight focus

In my experience it is very hard to make corrective actions while in the zone. The Zone has the same effect as speeding, your sight narrows and with high enough speed you can see only forward. How do you verify that you are solving the correct problem? Are you really going to the right direction? Are you sure? When in “The Zone” do you ever stop and wonder “Is this the right thing to do?”. Do you ever question the task at hand? Is this really the most valuable feature? Could there be something that would provide even more value?

The Zone is a state of extreme focus and motivation. The problem is that your focus is very likely too sharp. This leads to blindness to your own errors and makes it really hard to change direction. This leads to false productivity as the risk of rework grows very fast. With great speeds even the slightest mistake become huge almost intantly. Think about a steering error while driving over 200km/h.

Susceptible for interruptions

“The Zone” is fragile. Even the slightest disruption, an email, innocent short question from a colleague, can drop you out of it. Getting back is difficult so your productivity is going up and down very frequently. This can be really frustrating and a real motivation killer in the long run, especially when you consider the nature of software development which emphasizes team work and continuous communication.

You may have your own private room you can hide in but is it smart to shut out others? If everyone is locked up in their rooms what does it do to your team spirit? Privacy is ok and should be respected but isolation is not. With people spread out in their rooms how can you ensure that you are all pulling the same rope and in the same direction? Which leads us to the next pitfall.


Everything that is done alone encourages silos. It is always harder to spread knowledge afterwards. Spend too long on one task and you become the sole source of information. In other words a single point of failure.

Isolating yourself to ensure uninterrupted “zone” prevents you from learning from others, gaining information from others and spreading your knowledge to others. Silos prevent sharing the code and the code wants to be shared. In other words you have too long feedback loops.

Too long feedback loops

While in “The Zone” you are alone. Very alone. How can you be sure that you are doing the smartest possible thing? Is it the right thing to do? You practice TDD so technically you are on the right path but logically? Have you been derailed from your original goal? When is your next code review? Can you afford to wait that long? Are you sure that your domain knowledge is deep enough? While you worked in the zone and progressed did it actually move you forward in the right direction?

What if you had understood something incorrectly? Depending on the size of your task this can mean all you have delivered was waste (excluding your own learning). Did you write too much code? Did you try to anticipate the future?

The antidote

You can overcome some of the issues of the zone by ensuring frequent communication with the business and making sure that all tasks are small enough in order to shorten the feedback loop. This still leaves you in a more fragile state than we would want.

But there exists a very effective practice that renders the negative aspects of the zone very close to non-existent.

Pair programming.


In psychology terms “The Zone” sounds like flow. Flow is described as a state of focus, motivation and productivity. I want to make a semantic difference between these two states and add negative connotation to “The Zone” and positive connotation to “The Flow”.

Pairing gets you into a flow fast and it is easy to stay in the flow!

Pairing gives you enough focus but it isn’t too tight. It’s like having someone to read the map to you while driving to an unknown location for the first time. And it beats the GPS and other map utilities hands down. You always have someone there to question your train of thoughts, helping you to take the right exit or turn and to stop when it is time to stop.

While pairing interruptions don’t cost even nearly as much as they while in the zone. The pair can very quickly regroup and maintain their momentum. You can momentarily split up and continue after the interruption has been dealt with.

You can’t hide information while pairing and you can’t become a silo. You will learn, teach and gain information while pairing.

Pairing while programming gives you a feedback loop of seconds. Your thoughts are evaluated as soon as you articulate them. And articulating your problems is the best way to solve them.

Don’t keep zoning, start pairing

Categories: Blogs

Turing, Tortoises, and Lancaster Bombers

Tom Hume - Tue, 10/02/2012 - 05:41

The Science Museum in London is currently showing an exhibition about Alan Turing. Kate and I wandered up there on Saturday. I found the exhibition itself a little superficial - which isn't so surprising given the breadth of material the curators had to draw on between his personal life and death, contributions to computing, the war effort and Bletchley park, and his work on morphogenesis.

But there were two little gems in there which I focused on: the first, one of the tortoises of W. Grey Walter: beautiful and tremendously simplistic devices which exhibit eerily animalistic behaviours. And secondly, a bombsight computer from a Lancaster bomber, on which I was chuffed to discover the manufacturer's mark of Sperry. For it was a Sperry machine which D P Henry used to create his spirograph...

Categories: Blogs

Playing with advertising

Tom Hume - Wed, 09/26/2012 - 00:17

So, down the right hand side of this page you'll see a block, marked "AdSense". That'll be me playing with advertising; I'm interesting in learning a bit more about how online advertising works from a practical perspective, and I like learning about stuff by doing stuff.

So there'll be a small ad - or it might be a large ad in future, who knows? - running there for a little while at least. I'll be donating all income from it to the WWF, to one or several of their efforts around preserving big cats.

Categories: Blogs


Tom Hume - Tue, 09/18/2012 - 21:39

In the animalia-and-tech link-pile today, an iPhone case which acts as an ECG for pets and cows that SMS the farmer. The latter's particularly poignant, as the Sardinian chap who for many years rented FP their offices approached us to build a similar thing for him.

I've just started reading Guilty Robots, Happy Dogs after a Jones-post. I'm hoping it's the missing link between puppets, furries, and technology that I've been waiting for. This stuff has history.

Categories: Blogs

Needz launches

Tom Hume - Tue, 09/11/2012 - 12:05

I'm tapping this out from the gloriously sunny front patio of my uncle's home in Alicante. Just before we departed last week, a little birdie with the face of Ed Moore dropped me an email to let me know that Needz has gone live.

I've been following Needz for a little while, ever since seeing a demonstration of Agora, an early version of the product which they built in collaboration with Vodafone R&D. Needz is an interesting product, I think: Ed and his team have been looking at what a marketplace looks like when it's designed with mobile in mind, as opposed to being transplanted from the desktop web. I like the analogy of classifieds for this: location and convenience might be more important than getting the best price in some situations.

They're not the only people working on this problem, but they have an interesting take around building federated services which let providers run their own versions, which all appear to be the same service to end users.

Categories: Blogs