Pragmatic Agile Weblog

Agile software development in real life

Just Tell Me What To Do and I’ll do it – JTMWTD people

My first post in this blog comes from the daily experience in my job, but it represents a more general comment on way of thinking of some people.
It is definitely related to agile methodologies and I’ll explain why at the end of the post, but let me start from the beginning with some considerations on how some people approach common problems.

It’s not rare to find people that just act, perform, work in consequence of kick-off signal; I mean people that just wait for something to work on, wait for orders: people that I’d call the prefect executors – aka JTMWTD (Just Tell Me What To Do) people.
Many times in your life (not just in your job) you’ve probably met people that are perfect executors, but that need an input to start: girls waiting for the perfect love, fathers looking for the perfect son, managers waiting for the perfect business, developers waiting for the perfect design, product owners searching for the killer application.
They are all right, it is a noble cause and belongs to the natural process of cause and effect: you can’t start a fire without a spark (somebody said…).
Maybe it is even a kind of natural approach: “Give me all the resources, procedures, instructions I need and I’ll be the perfect builder”.
It’s great to find people that need just instructions… you have just to wait the cake at the end and that’s it.

But, what is the main disadvantage of this approach and how is it related to agile practices?

Let’s see the drawbacks first (you may already have found some).
Well, in order to let the perfect executor greatly work a microcosm of resources is needed: the perfect designer, the best environment, the right documentation, the right tools…
And here comes the first nonsense: you can reach the goal of a perfect result only if you start with the perfect environment (clap, clap, clap)…. too easy πŸ˜‰ And maybe even under those circumstances the work won’t be that perfect….

In addition, you are going to realize too late that the task cannot be completed: the perfect executor thinks you gave him the right environment and resources and typically doesn’t make a step to bypass obstacles… s/he just waits… for you and for the moment to say “If only you had…”

As I said it’s common in different scenarios (life and work), software development included.
Some team mates are JTMWTD and maybe they even think to be right: they are developers not managers, designers, testers. The worst thing about this is that JTMWTD will always find an external impediment that prevent them to perform the perfect work, and you are always going to know it too late.

The same approach can bee seen at a higher level in software development process. The waterfall process is based on the same kind of assumptions: everybody does just his/her job in sequence and does it to the best.
In the real world requirements change, people fail, tools are not appropriate, documents miss important details, therefore the process is required to take into account the need of a second chance. And it is much more important that every ring in the process chain share the same goals and commitments, so that everybody can better address the challenges that arise every day.

Likely, agile methodologies help to handle this kind of situation, but this require people change their way of thinking with regards to perfect execution.
I’d say that with the agile practices people must switch from the JTMWTD paradigm to “Let’s agree on what to do and communicate”.

Here in Funambol we are applying Agile practices also for the project management and Scrum is our choice.
We are iteratively releasing, trying also to increase code quality and we already have seen the advantages of it.
One of the first thing I’ve understood is that Agile practices increase the communication and I like it very much.
The daily meeting is my favorite practice because makes really easy to track changes and impediments, but above all because in my opinion it’s like the spark that starts the fire of the daily activities.

The daily meeting and the retrospectives change the waterfall rules in software development: nobody can say “if only you had said me this and that…” and each member of the teams is not so scared of changes in requirements… they just embrace the change.

But JMWTD people fight the agility and the team risks to have different feelings inside: agile and “frozen” people hardly work together.

So here is the challenge: applying agile practice in a real world with JMWTD people… don’t talk me about theory please.

For each JMWTD person becoming agile I’ll light a candle πŸ˜‰
As in many other areas of the agile theory, the most challenging factor is the human factor, because it is much easier to change a development tool or process than to change people mind. But this is also the key factor of success in adopting agile methodologies, it is something that can kill all the benefits of agile.

But if instead you manage to change JMWTD people, so that they start estimating and autonomously selecting user stories from the backlog and reporting impediments as soon as possible… what a nice feeling for a Scrum Master πŸ˜‰

Final Note: for Italian readers here is a link to a well known joke about JMWTD: “Tu mi dici quello che devo fare e io lo faccio”


September 22, 2008 - Posted by | Software development |

1 Comment »

  1. […] At a complete opposite side, a team of developers can be very well structured and organized. You divide the team in functional teams, define tech leads, managers, junior and senior developers and then define rules: a process to define the requirements, a process to estimate them, a process to define a plan, a process to manage the plan, a process to manage changes to the plan. With a strongly structured team the tendency is that all those processes depend on some key responsibility, people, roles. The analyst must define all requirements, the architect must validate any small change, the tech lead must estimate and decide the tasks to do, the project manager must check where each single developer spends his/her time and fine-grain follow the whole process. Due to the many centers of responsibilities those processes tend to become very formal and rigid. The main advantage of this approach is that it really keeps the established order and in a way it makes very simple to determine who is in charge of what. On the disadvantages side, it is pretty clear that such organization is very difficult to scale because it requires to scale the whole organization, increasing the number of middle layers. Again, if developers were molecules, you can see this rigid ruled model of interactions like the team was a solid (as opposed to be a gas). It has its own shape and volume that you can see easily, but what happens if something changes or has to change? It is more likely that the solid breaks than changes its shape. Another disadvantage I noted in a “solid” organization is that people in the team can take two main approaches with regards their lead or manager: try to take their place or let them lead completely. Both attitudes are very bad; the former because generates a lot of frictions and make people not work together, the latter because makes the environment even more rigid because people tend to wait that somebody tells them what to do next (see JTMWTD). […]

    Pingback by Why SCRUM? « Pragmatic Agile Weblog | September 28, 2008 | Reply

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: