How to be Agile?

I have came across a very interesting question lately, i.e. how to be Agile?

Well, if you are just looking at the surface meaning of Agile, it just means being flexible. Business would enjoy great benefit if they could have an IT team that allow them to respond to change.

However, if you look deeper into the Agile manifesto and principles, you will notice that it is very much related to Lean Principles. Which, the primary of Lean Principle is eliminating waste.

So, my typical answer to those question is, if you truly wanted to be Agile, you have to practice Zen thinking as individual and adopt Zen culture in your corporation. But why do I say so?

Practicing Zen allow you to grasp a better understanding of what is "Value", and value is at the center of the entire Agile spirit and methodology.

Let's look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

If you notice, being Agile means we really need to concentrate on the things that really matter. Not the noise which commonly overwhelm the attention.

Abby has some more points in his post regarding this thought which is similar in line.

http://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference/

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!