People talk about agile these days in Software Project Management. Each has their own understandings and practices. Sometimes, I have a feeling that people focusing too much on its concept; on what it is; on what we should apply; on how to apply …

Is there any problem with that? I do not know. I cannot judge someone decisions.

However, these are what I know. I know that I have to start with asking the right questions, that Agile is a tool to solve a set of problems.

1. What are my problems?
2. How can Agile help solve my problems? Has it solved the similar problems?
3. What are fundamental steps I should follow?

What Are Problems?

You cannot bring a tool to fix a problem that you have not known. It seemly does not work. There are hundreds of problems when running/working a team. Each team has different set of problems. There is no perfect team, my opinion.

The first step is to identify basic problems that the team is facing. As a software development team, there are some common problems that I have seen. Yours might be different than mine.

Lost Focus

What if you ask a developer in your team “what are our goals this week?“. I hope you will get good answer that your members know the team’s goals. From my experiences, they cannot say clearly about the team’s goals. They might say let me check the board. The point is that those goals are not clear to them.

Why? There are 2 possible reasons I could think of

1. Developers are so focus on their tasks (or they say so). Everyone has their own “to do” list on their mind.
2. The goals themselves are vague. Even the leader cannot say it clearly in 1-2 sentences.

Low Productivity

Output is not good. There is a high bug rate, high regression bugs. There are different definitions for Productivity depending on the team and organization. However, in short, Productivity means you deliver what you are supposed to deliver.

Why?

1. Lost Focus (from above): People are not aware of what they should deliver.
2. Cooperation: a crucial factor of a team.
3. Lack of energy: There is no rhythm in the team. People feel bored.

Agile as a God

Agile has emerged. People pay attention to it, read articles, books. And they quickly start to apply in their own teams and organizations.

Then we see people asking about “how to apply agile?”, “why does Agile not work in their team?”, …

Imagine the situation when you come to your team meeting with a strong claim: guys, we apply Agile. Then you start explaining about it. How cool it is. How popular it is. You have hundreds of reasons. You, then, set up Kanban board, announce daily standup meetings, … all other practices written for Agile.

What will you get after some weeks?

Soon you will chase to solve another new problem: why has Agile not worked with my team?

Wait a second! What was the problem that we wanted to solve at the first place? I hope someone in the team will ask that question.

Agile, on My Eyes

I would like to use Agile as adjective (yes, Agile is an adjective). That is Agile is a set of principles to help us improving our way of thinking, help us delivering better software, better output. That it has some practices to help us solving (improving) our problems (some I mentioned above).

I do not like to think Agile as a set of processes, steps, … or a set of instructions that we should follow.

Let take it small steps.

Daily Standup Meeting

The most common concept that people talked in that meeting is the three questions. In the nutshell, they are

1. What have you done yesterday?
2. What will you do today?
3. What block your way?

My opinion, they are boring. I do not think they work as expected, either. To force myself from not thinking about them, I called them Three Stupid Questions.

Wait! What the problems the meeting is trying to solve? Focus and Cooperation. By letting the rest of the team knows what you have done, everyone has the same vision. By raising the impediments, other can have a chance to help. The intentions are good.

However, in practice, I have not seen it worked (I know it might work on other teams). How to verify that? I suggest asking one of these questions (after the meeting)

1. How far are we closed to the delivery?
2. What were the team’s accomplishment yesterday?

Pyramid and Brick

I created my own version of daily standup meeting. The main idea is to utilize the visualization. In stead of writing the goals in words, I draw a picture with the concepts of Pyramid and Brick.

It must be a hand-drawing one. Team leader will draw it everyday in the team meeting.

1. Pyramid: is the rectangle.
2. Brick: the yellow or black boxes.
3. The window on the top right: The visualization of the delivery. In this example, it is a web form.
4. The face (with 2 arms): The team. The team controls the pyramid. They are in charged of everything. In the end of the meeting, it will either a smiled or sad face.

How does it work?

In the first meeting of the week (or sprint, I prefer weekly basic), the team will help build the pyramid. Bricks are work they have to do to build the pyramid. In the Agile terminologies, they can be either Epic, Feature, User Story, Bug, or task.

On the next meetings, each member will say what they have done will either move the bricks forward or out of the pyramid.

By having this visualization, everyone is more aware of what going on and how far they are closed to the delivery without reading a whole bunch of words.

At the end of the meeting, we should expect this happy face. If not, we should draw a sad face, honestly.

It depends on the creativity of each team to make the visualization alive. The more creative the better they will remember.

Task Based Completed

Put aside the requirement of having a good user story. Because we do not have that much luxury. The reality is that most of the time, we do not have a clear requirement, a well-written user story. That causes some problems. One of them is the feeling of getting thing done. Having spent more than 8 hours per day, working hard on the job, and the next day, we cannot proudly say what exactly we have done. We are kind of aware of what we did, but fail to name them.

To improve the situation, we came up with “Task Based Completed“, known as “The Golden Board“. In the Standup Meeting, your face should be on the board. There is no rule, no punishment, nothing required. Simply your face should be on the board. If not, not a problem, see you tomorrow. Again, your face should be on the board.

There are some benefits with this approach.

1. Encourage the cooperation and design. To breaking down in to small delivered tasks, they have to cooperate with each other and in that process, design the system. Tasks become your technical design documents.
2. Short error prone detection cycle: While implementing a task might spot a fraud in the design or requirement. The sooner the better.
3. Feel good. We know for sure that we have done something; that we get the job done; that we move things forward; that we cooperate with others.

One of the key point to make this system works is to make the task creation/completion super easy. In other word, do not put processes in the task creation. Task creation should be easy as creating a task in to-do list application. However, one should be improving the task’s name. The task’s name should be clear and understandable to the creator. Again, there is no requirement for others to understand others’ tasks.

 

Final Thoughts

Tools are tools. They are their to help us, human being, do our job. Each tool solves a set of problems. Before applying any tool, make sure we analyze our problems first.

When come to the teamwork, the most important factor is people, not tools/processes. Do not throw a tool to a person without instruction/training.

Have a good week!