Teamwork by Giving Implementation Hints

Tom and Jerry work in an agile development team building a web application. The team has 4 developers. In the planning meeting, Tom is assigned to a product backlog item (PBI). The PBI is simple. Anyone in the team can implement it.

Tom implemented the PBI the day after. It worked. A pull request (PR) was created and asked Jerry to review it. It is a normal process of the team.

Jerry left a comment in the PR:

Hi Tom, we already implemented the same thing at X feature. There is a common method that you can reuse.

A very constructive, useful feedback. Except the consequences:

  1. Tom has to throw away his implementation and reuse the existing one
  2. Waste of time from both sides: implementer and reviewer

Does it sound similar to you? – A common problem: Developers re-invent the wheel.

Why

The fact is that it is hard for a developer to know everything in the system. For many, that is impossible. Developers take PBI from the sprint backlog and work on them. How could they know what are already implemented? What could they reuse?

Discussions can help if you know what to discuss. Asking questions on the team can help if you know what to ask.

Reflecting on your team, how many times do your developers ask questions regarding to the implementation, to what to reuse. It is easier said than done.

Developers tend to write their own implementation. Because they think it will be faster and safer for them. So they just write code. And one cannot ask that question for every single PBI.

What Could We Do to Improve?

I am not a big fan of theory saying that developers should be proactive, ask questions. Yes. They should and they might will if that is the business logic. Or that is something unclear in the specification. Implementation? Not really.

Well-planned in the planning meeting can help. However, people have not talked much about technical design (or implementation hints) in the planning meeting.

Asking questions in the daily stand-up? I have not seen many questions asked in that regard. Most of the messages in the daily stand-up are status report. Just they are expressed in a different way.

So what could we do?

Give implementation hints in comments of PBIs

Each developer has different knowledge about the system. When an PBI is reviewed, some might have an idea of:

  • What it is
  • How to implement
  • What could be reuse
  • Reference points such as old PBI, Pull Request, or a specific commit

So instead of keeping them in your head, write comments in the PBI. When a developer starts implementing the PBI, he/she has a good starting point. From there, he/she can start discussions, asking questions. Because they know what to ask and who to talk to.

In a team, the most skilled, familiar with the code should look around the team backlog. Try to give as many hints as possible. Anyone can do it as well.

The approach has a compound effect. The teamwork is at the next level. Developers care about other PBIs, about the team. It also encourages conversions, engagement. When a developer leaves a comment, the conversion has started.

Take Away

Give implementation hints, folks, give implementation hints. Your teammates do not know what you know. The developers working on those PBIs will thank you. And in turn, they will do you a favor. That is where the conversation, the engagement begin.

PSM1 My First Certification Since University

At 5:30 AM December 13th, 2017 I decided to take the PSM1 exam. I passed with 95% corrected answers. Such a big moment! Thái Anh Đức at Scrum.org. And there is a story behind my decision.

The Story

I was introduced to Agile/Scrum back in 2009. And I hated it, especially the Daily Scrum (sometimes called Daily Standup Meeting) with the 3 questions being asked every day. I even called them the three stupid questions. I still hold that opinion to now. Since then I read from here and there about Scrum. There are some notion of Scrum-Like in the organizations I’ve worked with. I also attended some Agile events. I still have not felt better about Scrum. I thought Scrum is just a theory and it does not work. I hold that bias for years and that bias blocks me from learning.

Recently, I realized that I had not studied enough into the subject. I was not serious about it. There are good reasons for Scrum to be popular as it is today. Why don’t I figure it out? Why do I block myself from that? Once I made that decision, the next challenge was how. How do I hold that idea seriously? I know the normal trap that people have when they need to do something. Usually, we tend to make a big promise to ourselves. However, just a few days later we come up with excuses for not doing it. That was when I decided to take the exam.

Taking exam is a way to ensure that I am not joking with myself, that I am serious.

 

Before taking the exam, I heard people saying that those exams have no value. They are just a matter of remembering questions, practicing the answers, … and you get the certification. Really? “Is that simple?” I thought. By now, I confirm that it is not easy. Here is my journey.

The Journey

I started with downloading the official Scrum Guide. I printed it and carefully studied it 3 times. I did not just read over it. I studied it with my pencil at hand, took notes, picked out the important information. Do not fall in the trap of skimming it and think you understand it. Some might be able to do that. Many of us do not. Be realistic! After studying the Scrum Guide, I read some books suggested by the Scrum Org. At the same time, I checked out some courses on the Pluralsight. Once I felt a bit confident with my knowledge, I went to the next step.

Then I have to find a way to test my knowledge and get feedbacks. I found these links

http://mlapshin.com/index.php/psm-quiz/learning-mode/

https://www.thescrummaster.co.uk/professional-scrum-master-i-psm-i-practice-assessment

https://www.scrum.org/open-assessments/scrum-open

I took one and did the test. I failed miserably 🙁 That was the moment of truth. The test result put you exactly where you should be. Embrace it. I came back to the Scrum Guide and continued my study.

The nice thing about those tests are they give you answers with an explanation. Mostly they pick out the part in the Scrum Guide to backup the answer.

If you take the tests from all the above links, you will notice that they have different formats. Which means that you cannot remember the questions and answers. And the fact that there are too many to put into our short term brain memory.

After a few days of studying and practicing, I started to understand the Scrum. My testing scores were improving. And soon I completed 100% with half of the time. I kept studying and practicing for another week. I do not just want the certification. I want knowledge. And I was afraid of failing the test.

The Day

The day has come. I had to make a decision – Take the exam. PSM1 is about the basic knowledge of Scrum. I cannot keep learning the basic forever. The only way to verify my knowledge and get feedback is taking the exam. Either pass or fail, I will know where I am standing. Took a deep breath, I did 2 important steps

  1. Order the exam from Scrum.org.
  2. Create an item in my TODO list to take the exam tomorrow at 5:30 AM.

They are very important. Otherwise, I will find a good excuse to delay. As planned, with a bit of nervous, a bit of thrill, I checked the network connection to make sure I had a good stable one, I started doing my test. Once I click the button, there is no way back. The clock starts counting.

Even I did well in my open tests, the real test was a challenge.

  1. Most of the questions are not the same as you did in the open tests. Some might have the same idea with different expressions. That requires you to read and understand the questions and answers carefully.
  2. Time moves so fast. Make sure to keep a good balance between the time left and the questions. You should soon hit the speed of 1 question per minute. When I finished all 80 questions, there was 7 minutes left. I had very little time to
  3. Review all bookmarked questions. If you are unsure about a question, you can bookmark it.
  4. The test takes 60 minutes. Focus is also a challenge. That’s why I chose to start at 5:30 AM.

Mission Accomplished! I finally got it done!

Oh Congratulations! where am I standing in the Agile/Scrum buzzword? Basic, sirs! I know the basic of Scrum and have a good starting point for the next level.

That’s it!

Code That Embraces Changes

Developers write code. They write code for specific functionalities, with requirements from clients (customers, bosses, leaders,…). When requirements come, they know what to do; know what code to write. In the world of business applications, the implementation is not a big deal. The story might be different if we write code for embedded systems using C/C++.

However, most of the problems come later, when the first draft of the function has done. The functions have deployed to the customers. They test and realize that they have to change here and there. If I have to pick one constant in the software development, I would pick CHANGE. The clients will change their mind. They know better when they actually see the product. You, as a developer, cannot avoid changes and cannot tell clients stop changing. No. It does not work that way.

Agile emerges with the spirit: Embrace changes. A wonderful mindset shift! We have to adapt that fact. However, the biggest question remains: How do you deal with changes?

How do you deal with changes in code?

I know that there are processes to deal with changes. But, ultimately, it all comes down to the code. You have to change the code, most of the time you have to.

I do not have a single answer or solution to that problem. However, I do have some experience in designing code that gives me the courage, the tool to embrace changes.

Here we go. But first, let’s define a simple feature. We have to work on a concrete example.

Requirement

As a business owner, I want to export orders (that are made today) into CVS file so that I can import into Excel and build some charts.

Assumption: There is a shopping system. They take orders from users. The orders are stored in the database. They are all basic stuff if you have ever worked with a business application system.

First Implementation

Without any hesitation, jump right into the VS2017 and implement the feature. Btw, how hard it is to implement such a simple feature, right?

    public class Order
    {
        public string Customer { get; set; }
        public DateTime OrderedAt { get; set; }
        public decimal TotalCost { get; set; }
        public int NumberOfProducts {get;set;}
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ordersFromDatabase = new List<Order>
            {
                new Order{Customer = "Batman", TotalCost = 100000, OrderedAt = DateTime.Today.AddDays(-3)},
                new Order{Customer = "Superman", TotalCost = 1000, OrderedAt = DateTime.Today.AddDays(-2)},
                new Order{Customer = "Spiderman", TotalCost = 100, OrderedAt = DateTime.Today.AddDays(-1)}
            };
            const string headers = "Customer;Total Cost;Ordered At";
            var data = new List<string>{headers};
            foreach (var order in ordersFromDatabase)
            {
                data.Add(string.Join(";", order.Customer, order.TotalCost, order.OrderedAt));
            }
            var fullPathToCsvFile = @"d:\export\orders.csv";
            File.WriteAllLines(fullPathToCsvFile, data, Encoding.Unicode);
        }
    }

The actual implementation in a real project will be different. To demonstrate the point, I simplify the code.

What do we have above?

  1. An order has 3 information: Customer, Total cost, and Ordered At.
  2. There are 3 orders for Batman, Superman, and Spiderman. Assuming that they come from the database. Batman is a rich man so he ordered a lot 😛
  3. Export to CVS with “;” deliminator.
  4. The file is located at “d:\export\orders.csv” with Unicode encoding.

The code works. Mission accomplished.

Changes Come

Here are some changes that a customer might want to make

  1. Add NumberOfProducts into the export
  2. Change the location of exported file or even the encoding.
  3. Hey. I want to see reports of 2 days instead of just today.
  4. ….

Things go on in various ways. Finally, they all come to you, developers, to reflect the changes in code. If the application is just a simple stupid console app in this example, there is not any problem at all. Everything can be changed in a matter of minutes.

But we all know that it is not true in the real life.

Embrace Changes

I would prefer to do some logical analysis before actually writing code. If I start my code first, it will affect my thinking process. Sometimes it helps.

To embrace changes, we, first, must identify the possible changed areas. Isolate and Conquer approach

  1. Identify the possible changed areas
  2. Isolate them. Mean you can conquer them. Because you know where to look at, where to change the code.

Identify

Next and hardest question is

How to identify those areas?

Answer

Think in process and interaction. Capture concepts and patterns

Back to export order example. What does it mean? How do I apply in that example?

What is the process of exporting order?

  1. Get the orders
  2. Build data
  3. Write data into CVS file
Export orders process
Export orders process

Obviously, the process will not change. Because we control how we want to implement it. In other words, it does not depend on the customer. What changes? The 3 boxes: Get orders, Build data and Write to file.

Let’s go through each of them

Get Orders

  • Where to get them?
  • How to get them?
  • Criteria

Build data

  • How many columns do we need?
  • What is the format of currency, datetime, … ? the presentation of the data

Write to file

  • What deliminator to use? “;” or “,”? Maybe directly to Excel file?
  • Where to store the file? in which encoding?
  • What if the file fails to save due to permission?

Let’s say we have identified them. Now, let’s isolate them.

Isolate

I will modify the code as below

    class Program
    {
        static void Main(string[] args)
        {
            var orders = GetOrders();
            var data = BuildData(orders);
            WriteToFile(data);
        }

        private static IList<Order> GetOrders()
        {
            return new List<Order>
            {
                new Order{Customer = "Batman", TotalCost = 100000, OrderedAt = DateTime.Today.AddDays(-3)},
                new Order{Customer = "Superman", TotalCost = 1000, OrderedAt = DateTime.Today.AddDays(-2)},
                new Order{Customer = "Spiderman", TotalCost = 100, OrderedAt = DateTime.Today.AddDays(-1)}
            };
        }

        private static IList<IList<string>> BuildData(IList<Order> orders)
        {
            // Initialize rows with header
            var rows = new List<IList<string>>
            {
                new List<string> {"Customer", "Total Cost", "Ordered At"}
            };
            // Add rows data for each order
            foreach (var order in orders)
            {
                rows.Add(new List<string>
                {
                    order.Customer,
                    order.TotalCost.ToString(CultureInfo.CurrentCulture),
                    order.OrderedAt.ToString(CultureInfo.CurrentCulture)
                });
            }
            return rows;
        }

        private static void WriteToFile(IList<IList<string>> data)
        {
            const string deliminator = ";";
            var fullPathToCsvFile = @"d:\export\orders.csv";
            var csvData = data.Select(a => string.Join(deliminator, a))
                .ToList();
            File.WriteAllLines(fullPathToCsvFile, csvData, Encoding.Unicode);
        }
    }

Each method in the Main class encapsulates a concept, area that we have mentioned. Whether we should move them into separated classes is not that important. But yes, you should move them when in production code.

With that in place, when clients want to change something, you are more confident to embrace them. Or when there are bugs. In the beginning of the post, I mentioned that clients want to add NumberOfProducts into the report. Do you know where to change? Yeah! You got it – change in the BuildData method.

The above refactoring is good to embrace changes. However, we can make it better. I leave it to you if you wish to challenge yourself.

Takeaway

Take the “Embrace changes” seriously with you. Train your mindset into the concept. As a developer, we must be aware of that simple fact. Complaining about them will not solve the problem. You will have to deal with it anyway. Better, you should be in proactive position. Changes come! Not a problem!

When implementing a new feature, write new code, I would suggest that you stop for a moment, draw the process, the interaction in your head (better if you do it on paper) before you actually write code. Once you have done that, the possible changes areas emerge. Capture them immediately.

I have a simple process for you

  1. Think about the process, the interaction in normal language. Not the language of the code.
  2. Identify the possible changes areas.
  3. Capture them immediately. You should write them down in the paper.
  4. Write code.
  5. Design patterns, best practices come last.

I hope you enjoy the reading and use them for your next piece of code.

Have a nice day!

Deliver This Feature, Agile Said. Hmm, What About?

Agile is a good methodology to get things done. I buy the philosophies behind it. I think it can be applied in many areas, not just at work, not just at building software. To me, Agile is a tool, a meant to help me get the job done. In software development, I have heard people talking about these beautiful things.

  1. Agile team is self-organized
  2. Deliver working software (features) every sprint.
  3. No upfront design.
  4. Hmm, do we need an Architect? Do we need a Team Leader?
  5. Embrace changes
  6. ….

Many fantasy things. When I first heard about them, I thought

Wow. That’s so cool. Everything looks perfect. Hmm, if everything is perfect, then there is a hidden problem.

Unfortunately, I felt something was missing. Later on (at least up til now), I have found many. Basically, all those things are correct if, and only if, you have a perfect Agile Team. In reality, we all know that human is the root of everything. And having a good team is, well, just a dream. We have to face that truth. Do not try to assume we have a good team at hand. It just does not work that way.

Let’s take a small area from that fantasy: Add a new feature.

The Story

Good morning SWAT Agile Team, in the sprint we will deliver a new cool feature: Delete (soft delete) user. The feature will allow the administrator to delete a user. Users are marked as deleted but not removed from the data storage.

With these facts

  • The system has 10 of features built in.
  • There are features associated with User: Create, Edit, Manage Order, …

The wishes

  • The new feature will not break the existing ones.
  • Reuse the code as much as possible.

The untold facts (which will be discovered when writing user stories for the feature)

  • Some existing features will be impacted. Cannot delete users having orders. Cannot edit a deleted user.
  • Code Quality: Cyclomatic Complexity (CC) must be under control.

If you have been in such a situation, please share how you will handle it.

The Problem

Developers, Testers when joining a so-called agile team, how much have you known about Agile? When a project starts, developers are sold a plan of getting small deliveries, increasements. No upfront design. No architecture. Hey! That is the waterfall, folks, an Agile-men said.

There are many requirement meetings, discussions, … Everything goes well as planned. The team has a clear set of user stories. Estimation is done. Agile is on set.

Good! Ladies and gentlemen, where do we write the first line of code? Serious. Where do we write? Not mention how. To make thing super clear, where/how do you write the first line of production code? Just to opt out the Unit Test code.

A harder question. How do we code in such a way that in the middle of the sprint (or next sprints) the requirements change? How do we embrace the changes?

As the system grows, the harder to add a new feature.

The Solution

Hell No. I do not have a solution. However, I do have some proposals.

Infrastructure and Architecture

No matter what fields we are in, to embrace changes, to stand still, we need support from Infrastructure and Architecture. Without a good foundation, we just build a house on the sand. A single wind can blow it away.

We need an architect. We need a good, stable foundation. If there has not, we must build one.

We need an architect to define system boundaries, to separate the logics into proper concepts, to decide the architectural style, to decide design patterns. A good architect will limit the impact when implementing a new feature or modifying an existing one.

For legacy systems, a good architect can help decouple the dependencies, create boundaries. It is much harder than in the green field projects. But it can be done and can improve over the time. Otherwise, every single change is a risk.

Agile Mindset

People are the core of everything. Members decide the success or failure of the project, of the team. What is their mindset? We bring Agile in to increase the flexibility, to embrace the changes, … None of them will work if members think

  1. I must have a clear requirement to start with.
  2. My job is just coding or testing
  3. Who cares about the design. I just need to code this function. I change only a small part of the code.
  4. Hey, I just add a new method for me. Isolated. No breaking change.

Still the old mindset. I am not saying that mindset is wrong. But it does not fit the new environment either.

I would suggest the first thing we should do is to train our member; to get them adapt with the new mindset; to install the agile mindset into their subconscious mind. It is not easy, not at all.

A few things we can train developers

Architectural Thinking

There is no clear definition of Architect. However, everyone can think architecturally. Every developer, paid for a job, must be able to write code. They should not stop there. Instead, ask these questions

  1. Can I read my code after 3, 6 months? How about a year?
  2. How many ways can break the code?
  3. How easy to change? What if clients want to change XXX?
  4. Is it easy to understand?

What kinds of architectures that support well to embrace changes?

It is a long road. It is worth a try. Oh, wait a minute! Which means we need an architect. Yes, Sir! We need an architect or one having architecture skill in the team.

There is an argument saying that the architect will setup the system, build the framework, make some training sessions, and finally handle over to the team. Good luck! Soon enough, the framework will break. Things will tear apart. Why? Because of the lack of quality of maintainers, the development team.

Coaching

We cannot change someone else mindset. It does not work that way. However, we can show them the right mindset. We can consistently tell them the right mindset. Coaching approach might work. That is you do not train or tell someone what to do. No! They decide what they want to do and how they will do it. We, the team leader (I hope you have one), will

  1. Give some suggestions, show the direction
  2. Encourage
  3. Motivate

Will It Work?

I do not know. But if your current team does not work as you expected, maybe you should try it. There is no silver bullet. Try and Improve!

In discussions, every leader seems to know that people are the most important asset. However, when it comes to daily work, the reality might not the same. How much do we care the most important asset? What have we done to improve that asset?

Agile or waterfall, no matter what methodologies we use, we are a team works on a mission. We want to get that mission done and we want to be proud of what we have done.

Should we need an Architect in the team? Yes. Definitely. Then help everyone think as an architect.

Should we train our people? Yes. Definitely.

To win the war, you need good soldiers!

Happy Sunday! Thank for your reading.

Agile, My Own Version

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.

Agile DailyMeeting Goals Visualization
The visualization of the goals for the team

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.

Agile Goals DailyProgress
Check the daily progress. Should be more yellow bricks. The red ones are out of track

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.

Agile DailyMeeting HappyFace
A happy face we should expect at the end of the meeting

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.

Boy Dig a Whole
Boy, here is the hoe, dig a whole.

Have a good week!

 

%d bloggers like this: