Agile for the non-development team: a practical guide

I have no idea what this has to do with the article, but they sure are cute!

I have no idea what this has to do with the article, but they sure are cute!

Disclaimer: This article was intentionally written for an audience that do not know or care about the terminology of many of the agile methods. If you are a hard-core agilist, please look away.

Let’s say you have a group of people that want to try agile, but you are not sure where to start. If you have been working without any real method before, then Scrum might seem a bit heavy-handed, and Kanban scares you off with rules and an unfamiliar terminology you do not quite understand.

This is how you (might) do it.

  1. Start off by taking any large piece of the wall (or a whiteboard), and create three columns: to-do, doing, done. Take all your current and upcoming tasks from all your group members and put them down on post-it notes. You don’t have to write an essay on every note, just enough to make it clear what each note represent. Put them up in the appropriate column.
  2. Explain that each member of the group is responsible for updating their own notes, moving them along the board, and putting up new ones as new tasks appear.
  3. Make an agreement with the group that they meet every other week for two hours and discuss how to improve the process.

Really, the only necessary and mandatory step is 3), the other ones are just there as a conversation starter.

Depending on your group size, the two hours might look different. The important thing is that you have a meaningful discussion, and that you walk away from the meeting with at least one action, change, or experiment that you want to try for the upcoming two weeks.

Issues and experiments that might solve them

I cannot tell you what issues you might run into – that will be different from every group – but here are a number of issues that might come up and experiments that you could try to solve them:

”I cannot work on my tasks, because x is on vacation”.

Working in a group, or a team, requires each task to be the responsibility of the team, not a single individual. Try collaborating more, making sure that every task can potentially be done by at least two different people in the team (who do not go on vacation at the same time).

”It is unclear what ‘done’ means”.

Book a meeting where the team decides on what done means for different tasks. Create a short definition and put it up next to the board so that everybody can see it.

”Our to-do column is overflowing”.

Only put up tasks that you are planning on doing for the next two weeks (or whatever time span seems reasonable) in the to-do column. All other tasks can be in a longer list in a spread sheet or on a physical to-do-list.

”I do not know in which order I should be doing my tasks”.

You probably need to have someone help you prioritize your tasks. Who this person is, depends on your business. Preferably, it should be someone from the receiving end of whatever your produce.

”My tasks are too big, and just get stuck in the ‘doing’ column forever”.

You probably need to break down your large task into smaller ones. It is a good idea to do so before the task end up on the to-do-column, but not too early either – the prioritization might change. Gathering the team to discuss upcoming tasks regularly will help.

”My tasks have a good size, but they still seem to get stuck in the ‘doing’ column”.

You are doing too many things at once. Try to prioritize and get one task finished before starting a new one. You could try to set a reasonable limit on the number of notes in the ‘doing’ column. This means that instead of just choosing a new task when you get stuck with the current one, you must ask for help in order to get it to ‘done’.

”I do not know what others are working on”.

Perhaps a short meeting everyday can help? Focus on this meeting is to update everybody, but also to be able to ask for and offer help to the other group members.

”I can see that a lot of tasks are in ‘doing’ column, but not who is responsible”.

Simple: if you are responsible for a task, write your name the note.

”What we are doing are being questioned by outside stakeholders”.

Set up a meeting, perhaps every two weeks, where you show what you have done, are doing and why.

”There are too many external disturbances”.

Explain to the outside world that you are now a team, with a prioritized workflow. Any additional work should ideally go through that workflow. Invite people to your meetings, so that they can see how you work.

This is agile

Wait! you say. Is this all there is to it? Is this agile?

Well, yes, it’s a perfectly valid start. Communicate. Be creative. Dare to try. Improve. Go for it.

Introducing: Agile

Will it work with…?

Since a while back, I have a new assignment: introducing agile methodology in a major organization. I’ve also recently been in contact with other organizations, interested in replacing their current methods with agile. Now, these aforementioned organizations do not have that much in common, but they all voice concerns about making the transition to agile: ”will it work?” is an obvious question, while another – but just as common – is the extension ”will it work with our existing methods, roles and processes?”gears-520888_1280

Now, I find the latter question more interesting, because somewhere in there is a bigger issue. It indicates a conservative desire to keep everything as it is, while benefitting from the new. Perhaps that is human nature. But more serious is that it, when probing with follow-up questions, indicates an organization where several such method initiatives have come and gone over the years. Each such initiative have been preceeded by discussions on effectiveness, communication, structure, tools, etc. From many co-workers point-of-view, there is no difference between ”introducing RUP” or ”introducing agile”. It is just another one of a long line of changes supposed to improve their process, driven by consultants (such as me), after a while being replaced by another intiative when the results did not live up to the hype.

Methodology inheritance

The question ”will it work with…” thus also implies, that the employees have to live with a large flora of more or less related methods, roles and processes, sometimes being forced to perform tasks that belongs to a role long since obsolete. They still do them, because they always have done them, or sometimes, put bluntly, it might be a bit unclear as to what their current role actually are supposed to do.

head-46204_1280

You might by now see where this is going, but here it is spelled out: there is no point in blaming your existing methodology for its supposed short-comings, when you are actually not doing what the methodology tells you to. The same is true for agile. You could with some effort apply Scrum, do it by the book, and still not be very happy with the result. You could with much more effort apply SAFe – or some other agile scaling framework – after which you would throw your hands up in frustration since nothing has improved. The only thing you achieved was more confusion.

Inspect and adapt

Here is the catch: you do not ”apply” agile. You are agile. There is no agile ”method”. You inspect and adapt. And this is the difference between ”introducing agile” and all those other, previous initiatives: agile is all about attitude and mentality, and really very little (or nothing) about a preset number of documents and rituals.

Since nothing is a very tough starting point, there are a number of methods or frameworks that previously haveinspect_and_adapt proven to be successful that you can start off with. But they are not intended to be used as-is, and they are certainly not intended to be the ultimate agile goal. ”Introducing agile” is thus, in itself, a large exercise in inspect and adapt.

Thinking agile

When done correctly, the people in the organization will start to think agile, which in turn might lead to it actually making the necessary changes in order to achieve the desired effects. By inspecting and adapting, we can make agile working with just about any other method (if truly necessary, otherwise our agility allows us to remove the obsolete obstacles).

Now, the road to agile is not easy. It requires quite a lot of work, inspiration, education and perseverance. I know a consultant that might help you with that. 🙂