We are in a transition from Industrial Economy to Knowledge Economy

Does it means Industrial Economy is no longer exist? Nope, it will continue to be there. The only different is, we have gone passed the day we produce for the sake of producing. To stay alive in the competitive business environment, we must now set our focus on producing value. The company who can produce more value win. This is even obvious in software industry, where duplication is cheap. Basically whoever know how to perform a “copy & paste” function in their computer know how to reproduce something.

This brings to the transformation the title is talking about, we can no longer live in the industrial economy mind-set to be successful in software industry. It’s about producing value. Hence, adopting Scientific Management method from Industrial Economy does not make sense anymore.

The key principle behind Scientific Management is Efficiency! Technical explanation of Efficiency is “The ratio of the useful work performed by a machine or in a process to the total energy expended or heat taken in”. Yes, the focus is to product fast with good quality. 

It is nothing wrong with this approach, however in Software industry, produce more line of code does not yield anything if at the end of the day the software could not produce any value. The situation made worst with other Scientific Management guide:

• Establish clear rules on how work was to be performed. Reduce “rule of thumb”
• Select, train to develop workers
• Cooperate with workers to insure work is consistent with rules identified
• Equal division of work & responsibility between management & workers

Basically, Scientific Management promote specialization. The responsibility of decision making is delegate to the elite person, a.k.a Manager. While the worker just perform the task and complete the plan. The same method has been applied to Software Industry where you can see specialized role or title, i.e. programmer, business analyst, tester, architect and etc. You have the line manager or project manager to perform all the planning and decision making.

Some may ask, what’s wrong with this approach?

Well, Software Industry belongs to Knowledge Industry, where the minimum entry criteria are highly educated worker. Hence, applying Scientific Management does not emphasis learning. In the knowledge economy, the only way to maximize the investment on people is to amplify their learning. To increase their knowledge so they could produce more value.

Is it a Defect or is it an Enhancement?

It is very common for software users to categorize every single unpleasant experience as a Defect.

With the same logic, it is also very common in Scrum project, that a Product Owner classified every things deem "missing" from a "Done" product as Defect.

For me, it is important that a Scrum Master, or an Agile coach to make sure this expectation is set during the project kick off. Recommend the usage of Extreme Programming method of user stories to capture requirements, emphasis on the important of acceptance criteria in the user stories. Make it a point that, any scenario that is not being thought of as acceptance criteria will be classified as enhancement. They will be added into the Product Backlog for prioritization and to be work upon. System behavior that does not match the acceptance criteria will then be classified as a Defect for the team to work on them as soon as possible.

The development team hold the responsibility to make sure all acceptance criteria in the user stories are handled. While the main purpose of the UAT is to discover more new scenario that the system needs to handle and add them as enhancement into the Product Backlog.

Avoid the situation where the development are encourage to make their own assumption and code them into the project, as there is high chance that those will be a waste to the project. All assumptions are to be clarified with the Product Owner before any single line of code is written on them.

Everyone in the Scrum Team should be encouraged to contribute to the acceptance criteria all the time. It will just make the product better.

Human Brain And Quantum Physics

I would like to share this youtube video, I have been very puzzled by people who does not accept reality and I guess some part of this video explain why. As one of Agile's key element is transparency, you will often come across stumbling block of people who cannot accept that they need more time to get things done. Those people would prefer to use traditional approach where the reality could be postponed.

Very interesting, indeed.

What to look for when hiring a Scrum Master?

A friend of mine just posted this question to me, and my answer to him as follow.

If your company has achieved high maturity level on Agile, i.e. When your company has embraced the spirit of Agile, and that you have enjoy all the benefits Agile can bring to you, you can dominate anybody with proper Scrum knowledge to be your Scrum Master. In those scenarios, the main activities of Scrum Master would be purely facilitating Scrum Ceremonies, remove impediments. Anyone from your existing Scrum team could take turn to play that role.

However, if your company is new to Agile or have some bad experiences in past "Agile" projects. It would be wise for you to engage an experience Scrum Master. Below are tasks that a Scrum Master need to perform, which I copied from Scrum Alliance.

1. "The ScrumMaster is a "servant leader" who helps the rest of the Scrum team follow the process. The ScrumMaster must have a good understanding of the Scrum framework and the ability to train others in its subtleties."
- This task is pretty easy to perform, as long as the person is a Certified Scrum Master, either by Scrum Alliance or Scrum.org, he/she should be ready to perform this task. A good Scrum Master would be able to explain the reason behind each component in the Scrum Framework. This is important for your team to tailor the process components to suit your environment yet still keeping the same value.

2. "The ScrumMaster helps the product owner understand how to create and maintain the product backlog. He or she works with the entire Scrum team to evolve the Definition of Done. The ScrumMaster also works with the development team to find and implement the technical practices needed to get to Done at the end of each sprint."
- This task would require an experience Scrum Master to perform it. First of all, he/she would need to educate the Product Owner, understand business language so that the Product Owner could appreciate why good product backlog is important to the project. The Scrum Master must not take over the creation and maintenance of the product backlog from the Product Owner. After that, the Scrum Master would need to understand the business good enough to guide the Scrum Team on developing the Definition of Done. There are many factors to be considered during this list, as business is always under pressure to deliver, certain technical debt would be unavoidable.

3. "Another responsibility of the ScrumMaster is to remove impediments to the team’s progress. These impediments may be external to the team (such as a lack of support from another team) or internal (such as the product owner not knowing how to properly prepare the product backlog). That said, the ScrumMaster fosters self-organization, meaning that the team itself should remove issues wherever possible."
- To perform this task efficiently, it required high level of people skill. He/She also needs to make intelligent decision on whether an impediment reported should be resolved by the team themselves or the Scrum Master should step in. This is not an easy decision, required a lot of experience to make this important decision right. If the Scrum Master remove all impediments by him/herself, then he/she is taking away the growing opportunity from the team, however if the Scrum Master pushes every impediments back to the team, then he/she is not serving the team right.

4. "The ScrumMaster may facilitate meetings and always acts as a coach for the Scrum team, helping it execute the Scrum process. He or she helps team members work together and learn the Scrum framework, and protects them from both internal and external distractions. The ScrumMaster keeps the Scrum team on track, productive, and growing in ability."
- On this note, one must be able to differentiate between facilitating and taking over.

5. "Ultimately, the ScrumMaster is responsible for ensuring that Scrum is understood and in place, inside the team and outside. He or she helps people outside the team understand the process and the kinds of interactions with the team that are helpful (and those that are not). The ScrumMaster helps everyone improve to make the Scrum team more productive and valuable."
- It is important for Scrum Master to understand the value between each actions in the Scrum Framework. Not to take them by the face value. Every project are unique in the environment and process must be tailored to suit the project.

Our education system has fail us

Afraid of failure, our school system never encourage us to make mistake and learn from it. We have exam system where you will be punished by your failure. Exam has turn from assessment purpose to punishing failure. That makes the whole system focus on exam score rather than the meaning of education. I came across this quote from Martin Luther King which I fully agree with.

The function of education is to teach one to think intensively and to think critically. Intelligence plus character - that is the goal of true education.

Martin Luther King, Jr.

The result? I do not know about other industries but I do believe our current education system is the main culprit of many failed software projects. Almost in every software project I stepped into, I have to undo the team's mindset which they inherited from the school. I need to educate them to think intensively and critically to every single decision, not be afraid of making mistake because that is the only efficient way of learning. Let me cite some examples of how this has affected successful project delivery.

1. Project Status Report
- Almost in all failed projects, the cause of failure does not due to a single incident that happened over-night. How would these "symptom" not being picked up by the project organizations that were involved in the project? In most cases, they were not even reported by the project manager in his status report. It can be certain that the team would have been aware of these "symptom", for example, customer keep changing mind, too many work that almost everyone need to work over-time constantly, the quality of the code is giving problem to the progress and etc. Project manager might think that to report these "symptom" will reflect badly on him/her capability to manage the project, hence they were ignored. They do not want to get punished for reporting the problem. While the management also graduated from the same system, they will indeed "punish" any project manager who reports such problem. The management did not create an environment to encourage those "symptom" being reported. If attention were paid to those "symptom", solutions will be generated and no one needs to face the consequences. i.e project failure. Our education system has turn the status report from an assessment to a score card, no one want to see bad things in the score card.

2. Refuse to clarify
- Be it traditionally or even with Agile methods, I still see many programmer refuse to clarify the items in the specification document or product backlog/ user stories. They are afraid that the clarification action will make them looks bad, hence they are making a lot of assumptions by themselves on what actually those requirements mean. Again, they treated the clarification event as an exam rather than an assessment if their understanding of the requirement is correct. They are afraid of being wrong.

There are many more other examples where a project team/organization demonstrated these behaviors or habits that they pick up from the individual's education. They adopted certain methodologies (water-fall or Agile) simply because someone has used it and it kind of work. They do not think intelligently why and what a method work. When they started using it, they refuse to think that they might have understood the method wrongly. They just continue to do it the same way and hope for a different result.

There are much more on this topic that every project organization should think of. It does not means that you "implement" the Scrum Framework, using Extreme Programming practices means you are Agile. It is more than what meets the eye.

Programmer is not factory worker!

I am always proud to tell people that I am a software programmer, simply because a programmer's job required frequent exercise of both right and left brain. They constantly required to transforming abstract idea into concrete implementation. It's a job that would require both art and science skill. Hence it's not something that anybody could easily perform.

However, most of the software programmers are badly underrated; they are treated like a factory worker. It is not a surprise that most business people believe 10 inexperience programmers will always 10 times better than 1 experience programmer. So when they are looking at how to cut operation cost, they go all the way to create off-shore development centre. This is similar to manufacturers who setup factory at places where salary is lower.

Wait a second! Am I contradicting myself here? If every programmer is smart, then what is wrong with the off-shore development centre? When they are equally smart and lower cost, isn't simple math and economy suggests we should all do that?

Don't get me wrong, I am not against the idea of off-shore development centre. It makes perfect sense for any business to seek every opportunity to lower down their operation cost. What I am trying to say is, while the action has a valid reason, one must know the goal and core principle. I have seen such action give birth to certain mind-set that back-fire on the business themselves

1. Off-shore programmer, they are pay less, hence they are less smart. We cannot trust them with important task!
- This is a very common assumption in this whole off-shore development game, the result is, most inexperience programmer will end up transforming themselves into what other perceive them to be, they become/behave like factory worker. It is largely due to they are not empowered or being encouraged to be autonomy. They work like a machine operator and required high precision of instructions to produce a good outcome.

2. Communication with the off-shore developers will not be a problem since we have comprehensive documentation!
- There are still many people who believe in this statement. Most of them are experience and senior "management" level. They believe that document is a good and efficient way of communication. They truly believe that long distance communication challenges could be resolved easily using specification documents, email and min phone call. Although majority of them have participated the Chinese whispers game when they attended communication training.

I am supporting the idea to recruit developers from foreign country, but you may want to bring them to your work place so they can be co-located with the users. This will allow them to use the most effective communication tool "face-to-face" when come to understanding the requirement. On top of that, give them the equal respect as you will give to any professional. They are smart people!

You should insist your client to take up the Product Owner role

I just read an article posted in Scrum Alliance, by Patrick who thinks otherwise. However, I strongly disagree with his point. Perhaps due to both of us working in a similar environment (development efforts provider) provide me an opportunity to better understand where he is coming from.

I have coached a few Scrum team, all of them are very new to Scrum Framework, some may have individual member who have previous Scrum experience but not the entire team. In each team, I have always insisted the Product Owner role to be played by the client side. Preferably from the same person, who sponsored the project, however this is always difficult because the project sponsor are always too busy to commit themselves into this role.

I always use the metaphor that if you want to buy something that is highly customized, and you are paying it, would you want someone to decide every single detail on your behalf? Or you would like to be able to make every single design decision by yourself? Who can know what you want better than you? If you are too busy to make all those decisions by yourself, won't you entrust someone who you know better on that role than let the supplier decide?

In my cases, I experience the following benefits when Product Owner role is played by my client representative. I focus on coaching the person to be a good Product Owner (CRACK)

C: Committed (to the team, the project and the business)
R: Reliable (has time and is available when needed)
A: Authorized (can have the final decision and can have it fast)
C: Communicative (knows how to bring the message across)
K: Knowledgeable (needs to know what it is all about)

Benefits:
1. Client feels that they own the project
This is one of the key reasons why Scrum advocates the user to play the role of PO. They should not throw the responsibility of the project over the wall. With the PO create and maintain the product backlog, direct the team on what to build on each Sprint, decide on the product backlog priority, it give them the feeling of ownership of the project. It also make the communication of the project status and certain decision making reason easier in the client organization.

2. Client enjoy the transparency and hence difficult project decision are made easier
Having the PO from the client side also encourage transparency, hence there should not have many surprises when a challenges (technical / non-technical) pops up. Should a particular user story needs more efforts that could impact the project budget and schedule, that decision was made easier with the PO having full information and visibility to it.

3. Better team spirit
You really want to eliminate the feeling of vendor vs supplier within a project team. The project team (PO, Scrum Master and Dev Team) has only one goal, i.e. to make progress to the project. Having PO from the client side will eliminate a lot of unnecessary political red tape along the way. Make all them temporary forget which company they draw their salary from will encourage them to make decision that benefit the project.