Catch up New Technologies

Imagine you are assigned to a project which has many new technologies. It’s your duty to learn them as soon as possible to qualify your job. Imagine one day a friend tells you that he’s just discovered a new application framework which helps him to solve his project requirements. If that really inspires you, you have to start learning that framework.

In both cases, you have the need to learn a new thing but you might have some questions: how to start your self-training? How to do it in an effective way? In this article, I’d like to share with you some steps on how to do that.


Your mindset
Learning a new thing is not always easy, you might already know something related to it before or in some cases you even have no clue about it. So it’s very important to ask yourself questions and try to answer them.
What: This must be your first question. By surfing Google or wiki, you will have basic ideas about such technology and also some of its core concepts. Everything goes with its concepts; your first step is to remember the definition and concepts.

Why: Once you’ve known exactly what it is, the next question is Why? Needless to say, people don’t invent new thing unless there’re problems to solve. Thus, this question will help you find out the reason of existence and the benefit of that technology. In addition, asking the why question is also a chance for you to recap your knowledge. Below is an example:

Why WCF ? You might find this picture with some description about it: “Windows Communication Foundation (Code named Indigo) is a programming platform and runtime system for building, configuring and deploying network-distributed services … WCF provides a common platform for all .NET communication“. So the answer is clear: with only one codebase, you can make your application communicate in different platforms by doing something.

There’s an interesting point in this picture, the grey circles. Have you ever worked with them before? Have you had any knowledge about them? If your answer is “Yes”, then you’re fine. But if it’s “No”, then you know that there’s a gap in your knowledge (and maybe you’ll fill that gap at your convenience time).

How: Keep going and you’re facing with a tricky question, “How?”.  The example above has a phrase “By doing something”. Here you will find out what it is. Usually, at this step I will not try to dip into the codebase (if it’s open source) but re-scan all the core concepts in order to find out why they are there, what their purposes are. The  answer to the How question will appear in your brain once you comprehend the specific concepts/components and their connections. My best practice is to use the high level architecture diagram. Look at the WCF architecture below.

My interpretation about this WCF diagram is: - WCF uses different “contracts” (at this stage I mapped the term contract as Interface) to communicate with the Application. - The communication can be executed via multiple “Messaging” channels. - I can also adjust the behaviors of the communication channel via options in “Service Runtime”. - Finally, a WCF application has to utilize a process to run itself. That’s where “Activation and Hosting” comes in.

One note in this step is: your interpretation doesn’t have to be 100% correct. You just try to grasp its inside by using your own words and your own perspective.

Resource
After spending some time to capture the basic ideas behind the technology, you have the need to go into detail and standardize your knowledge. That’s why you need a book.

Book: With the accelerating of the Internet, you will have no difficulty in searching a good book. You can ask your friend for recommendation or find some book reviews in many websites. One thing I’d like to recommend is: try to find a book which matches your level of expertise and your need, then work on that book only from the first page till the end. Why should I advise this? Because I’ve been in a situation which I downloaded, let say … 1GB of WCF books and samples, but after all I didn’t read any of them because it’s too much!

So, when you’re looking for a book, choose the one that has enough information. Don’t go with a book of +1000 pages. You will not have time to digest everything in such bible-alike; even if you have time, you will get bored at page 300th or 400th.

Blog post: We’ve all known that in these days, book is not the only available resource to learn a new thing. There’re always “big guys” who publish their thoughts and hand-on experiences via their blogs. Someone told me that “This is the time when everybody can be a technical writer”.

I know some people who don’t even read a specific book but blog posts. They told me that books are too much academic, too much discipline. What they want is real experience, real problem and real solution.  I myself appreciate that idea because we all fight against the real issues and the real business requirements; thus, at the end of the day, a technology is aiming at solving those issues. Reading blog posts is a good way to stand on the shoulders of giants.

However, I think that you should only utilize Internet articles as an extension because they’re not always standard. Let’s take a very simple example: To solve a problem, sometimes you have to hack the system and you might find the solution in a renowned blog … But the solution might be just a work around. At some point, you even have no idea why and how the work around works. Utilizing a book will help you become aware of the mechanism deep inside the technology. I’m sure you will understand the hack once you know exactly how its core works.

Another interesting thought regarding this topic is quality and quantity. I’ve met some guys who often read +200 articles per day. Yes, it’s two hundred! I’m very impressed with the number and really admire them. I did try to reach that number but I failed. The primary reason is that I don’t have enough time. Finally, I’d rather research lesser but know exactly what I do and deeply understand all of them instead of aiming at nice number. So, it depends on your level of expertise as well as your ability to decide which approach is better for you.

Get dirty
Once you’ve finished theory stuffs, now it’s time for practice. Some people think that reading and understanding the technique without hands-on experience is enough. I think that a technical guy who can talk confidently about a technical topic doesn’t mean it’s his achievement (… maybe he’s just read it last night!). What we want is not only talk but also be able to work with it immediately and smoothly.

Open source: This is a very useful resource for you to start getting dirty. There’re many websites which are the hubs for open source projects. You’re free to download source code and free to play with it. There are small projects as well as big projects with production code quality.

However, you should be careful with these open source projects because they might include a bunch of technical frameworks while you just want to learn one of them. I did have that experience. I downloaded a big, renowned open source project which has the framework that I was researching, let say, Orchard which has MVC 3. I got nervous because they applied a lot of things that I hadn’t even heard of before. Finally, I decided to focus only on MVC 3 and didn’t attempt to look at anything else. I tried to understand how they organize their Views, their Controllers, how to feed data to the Models, why there’re ViewModels… After I understood all of that, I downloaded a smaller project which I could play around with the codebase and applied what I’d known into it. That’s the way I utilize open source projects to achieve knowledge.

Your own product: Doing your homework with an open source project is not enough; I’d encourage you to build your own “product”. It doesn’t have to be a big, fancy application with full of documents, scalable and extensible architecture. It just needs to be as simple as a shopping cart. But this time, you will write your own code. You will have a chance to validate your understanding of the technique. You will have a chance to solve real issues with your newbie knowledge. That’s really interesting! Once you’ve built a product successfully from the scratch, I believe you can confidently tell your boss that you know the technique.

Congratulations! You’ve got it!

Summary
I’ve read somewhere, there’s a statement:”You should plan to work 60 hours per week in which 40 is for your job and 20 is for yourself”. Achieving a new technique is neither too hard nor simple; it’s all about your perception and methods. Everybody has their own way of studying but I suppose these steps are essential no matter what your approaching style is. In short, there are three phases:
* Mindset preparation by asking questions.
* Resources utilization over the Internet or social connections.
* Knowledge achievement with real projects.

CV Writing Skill

Have you ever wondered what the most valuable certificate is in IT and especially in Software Development Industry? If you google the phrase "Top IT Certificates", you will get many articles telling you about that. Normally they will be issued by Microsoft, Cisco, Sun and even PMI. Now, I have a question for you. Please ensure you will answer the question before you read the next paragraphs. What is the most valuable certificate for you?

While Microsoft, Cisco and other organizations issue certificates to certify that you are mature/expert in some knowledge areas, there is one special certificate which you can certify yourself. It is your Curriculum Vitae !!! Let’s start the debate if you disagree.

1. Introduction
I have been working with recruitment teams for CV screening and CV selection, I have also experienced with sending CVs of people from my team to client for their selection. I have realized that not many people really pay attention to what they should write in the CV or they don’t really focus while writing the CV. Let me tell you a very simple recruitment process as below.

When recruiting one position, the recruitment team can receive up to 20, 30 or even more CVs. The first step is to screen the CVs by scanning through them quickly to see if there are some words matching the job requirement. After having about … 5 CVs, they will sort these CVs and choose the best 2 or 3 CVs for interviewing. So, if a CV isn’t written well, it won’t be in the top 5 selected ones. If a CV is written OK but not attractively, it won’t be in the top 3 final ones.

As I mentioned above, the CV is not only for applying for the job, it is also to certify who you are, what achievements you have made, what skills and experiences you have gained and so forth. After all, you should be proud of your CV and it is the only certificate which you have been working hard to get and you are the only one who can issue it.

Having a good working history is very important to have an attractive CV. I hope the series of "Road to Destination" articles could help you on this.

2. Background
If you’re working under software projects, your CV should be structured like this.

Your name Your expected position

Summary A few paragraphs to describe your entire employment history.

Skill & Certificates A table or a list of bullets to describe your skills such as C#, Java, SQL Server, Oracle, …

Experience This section lists out all projects which you have joined. Each of them should have a structure as below.

From MMM/yyyy to MMM/yyyy Project name     Employer A brief description on what the project is about Role: Responsibilities: Some bullets to tell what you did in the project. Technologies: Technologies used in the project

Additional Information Education Languages Awards Recommendation References

Personal Information Birthday Marital status Phone numbers IM Website Address

3. Writing Tips
I won’t step into detail of each part, but there are some tips which can make your CV staying on top of the others.

The first part
A CV with a good-looking picture is always more attractive than just plain text. Moreover, your expected position shouldn’t be fixed and should match with the job which you are about to apply for. So, you should update it before sending out.

Profile Summary
The most important part of a CV is the profile Summary. All information which is described in the other parts should be found in this summary part. Instead of reading through so many pages to understand who you are, the reader can quickly have this by just reading the summary in a minute or two. Moreover, the information you put here must be quantitative if possible, otherwise qualitative. Let me give you some examples

Normal writing	Recommended writing
I am a strong experienced engineer in Software Development industry.	With over 7 years of experience in Software Development industry.
I have worked a lot with .NET web platform and also Java based applications.	I have worked with .NET web platform for 5 continuous years and Java based applications for 6 continuous years.
I used to work in big projects with multi-national client.	The biggest project which I used to work was 20 people in 24 months. In this project, I had opportunity to communicate directly with people from US, UK and APAC.

Skill & Certificates
Another important part is describing your skills and the same rule is still applied here, try to make it quantitative as much as possible. So, it is recommended to use a table to list out all of your skills followed by years of experience, level of expertise and last usage time. Let’s see one example:

Skill	Years of Experience	Level	Last Used
Programing
Java	5	Can advise the other	Present
C++	4	Can work without coaching	May-2010
Php	2	Can work under coaching	March 2009
Database
Oracle Development	4	Can work without coaching	Present

Specifying your role:
In many cases, I see that people didn’t write the right role which they actually played. Instead, they put their company position which doesn’t really reflect to what they did. One specific example:

Role: Senior System Engineer Responsibilities: * Working with client to get their requirement * Managing the requirement and allocating work to a team of 5 people * Managing the performance of the whole team * Investigating and defining the solution * …

With the responsibilities as described, the role of this person should be a Team Leader or a Project Leader. Most people don’t really understand why a Senior Software Engineer can take ownership of those tasks, but by mentioning a Project Leader or a Team Leader, people will easily imagine that this person has experienced with managing a team and/or a project.

4. Conclusion:
Again, to be on top of the others when applying for a job, your CV must be written attractively (not cheating but telling the truth as it is). Make sure if someone spends a few seconds looking at your CV, they will read the rest.

To achieve this purpose, keep in mind the guidelines below:

* The profile summary is the most important section, all strengths and key skills must be put there.
* Trying to be quantitative as much as possible.
* Specifying your past roles in the right way.
* A good-looking picture.

To be more practical on what I have presented, I have also put here a sample CV.

Project Sign Off - Something Must Be Planned Right At The Beginning

For Project Manager (PM), getting project acceptance agreement (or project sign-off) is the most important achievement. It looks like professional cyclists reaching the destination after hundreds of kilometers. The winner of the tour is the one who understands the game and practices frequently. Similarly, giving the same project to project managers, you could be the one who can easily get the sign-off early or you could leave the game when you've still not reached the destination.

While most of PMs often do a very good job during the phases of execution, monitoring and control, they often get stuck at the closure phase when it looks like their project team's work will never get done. One important activity needs to be done to get the project accepted by client is doing the acceptance test (or scope verification according to PMBOK v4). However, PMs who are new to project management or lack of training cannot achieve this acceptance. The tricky point is that this activity must be planned very early even when the project is not started yet. As the result, the project team gets panic when they have tried a lot but the work seems never get done.

1. Background
    This article is to give you a full view on how the project acceptance test should be taken care (in PMBOK v4 it is called scope verification, however, in software projects the term project acceptance test is used more popularly). Sometimes, it is called User Acceptance Test (UAT) if the project team works directly to the end-users.

    Basically, the following artifacts need to be considered to get client's acceptance agreement on the project:

* Project Acceptance Criteria: defines the condition in which the project must be accepted.
* Project Acceptance Approach: defines in principle how client will validate the project for acceptance.
* Project Acceptance Test Cases: defines how the system must be tested by client (or end-users).
* Project Acceptance Agreement: a mechanism to have client's official sign-off for the project (meaning they accept to pay money).
* Project Acceptance Test Plan: defines the overall plan of how the project is validated for acceptance.

Lacking of any of above will lead the project into problems and the project likely never gets done. Now, let's see two particular problems which often happen in the real software projects.

2. Problems

Case study 1: Thanh runs a software project to create a Payroll system. After 4 months of development and testing, it is now ready for release. Thanh writes an email to inform client and asks them for testing the system but he has no response timely. He reminds client and gets the answer. Client says that it is the year end now and the Payroll staffs are busy with calculation not only for the current month but also for the whole year. They don't have time for testing until January next year. Thanh has no other choice rather than keeping the project on hold until January but then he has another problem. After two weeks of testing, the Payroll staffs feel uncertain and unconfident when they're asked for sign-off. They have played with the system according to their Payroll experience but they're worried whether it is safe to give the sign-off.

Case study 2: Tuan has been managing his project very carefully. He has got major sign-offs from client during the project life cycle including sign-off for Requirement Specification, sign-off for Architecture Document, etc. He's now moving to getting the final and the most important sign-off which is project sign-off. With the attempt to have no bug in the release for UAT (User Acceptance Test), the team has worked hard in the last few days, but unluckily there are still bugs and the deadline comes now. Tuan has decided to deliver the products to client and will have the team continuously fix the remaining bugs during 2 weeks of UAT. During the UAT, the team not only fixes the remaining bugs but also fixes the new bugs reported by client. After two weeks, bugs are still remaining and Tuan is afraid of asking client for accepting the project. So, he's decided to expand some days in order to clean all bugs. On the last day which Tuan planned for release, there're still two remaining minor bugs which make him feel a bit frustrated. However, he has to deliver the products to client as committed. After a few days, client comes back and reports six new bugs. Especially, client played with the product in strange scenarios which the team never tried and found two new bugs. Tuan has to sit down with the team again and plan for the next release with the hope to get the project accepted soon.

In case study 1, there is no consideration, no plan for Project Acceptance Test at all. PM just assumes that client will test the system after the team completes the development. This is a particular case when PMs are new to project management and lack of training on knowledge and processes.

In case study 2, PM seems to have knowledge on project management. He seems to do every activity right except lacking project acceptance criteria. He assumes the project acceptance criteria to be zero defect. Now, question for everyone who is reading to this point, do you think a project can be delivered with zero defect?

3. What should we do to quickly and safely have project sign-off?

    Firstly, the Project Acceptance Criteria (PAC) must be agreed upfront. If PM involves in the presale/bidding phase of the project, he/she should define PAC clearly. If PM involves in the project late, he/she should consider PAC as soon as possible, do not leave it until too late.

    The Project Acceptance Approach should be defined together with PAC. PM should tell client not only the condition but also the way how they will validate and test the project until it is mutually agreed/accepted.

    The next step is defining the Project Acceptance Test Plan. Normally the plan will also include or refer to Project Acceptance Test Cases, Project Acceptance Approach and Project Acceptance Agreement. Many PMs are confused when they think that their project team has the Test Plan and Test Cases and this is enough. Let me explain:

    * Normal Test Plan & Test Cases: this is normally used by project team to test the project internally. Most of the time, client doesn't really care these artifacts except when they want to understand the methodologies or the development processes of the software vendors.

    * Acceptance Test Plan & Acceptance Test Cases: this is used by client to test released software packages. If client is familiar with software development they often take care of this. Otherwise, the project team has to consult client for this. The project team can even use normal Test Plan and Test Cases and modify to produce Acceptance Test Plan & Acceptance Test Cases. No matter who provides these artifacts, the principle is that the procedure and the schedule of the test must be agreed before it is executed.

    The final step which is the most important one is asking client for signing off the Project Acceptance Agreement. This is done when the project meet the criteria defined at the beginning of the project.

    Up to now, I have mentioned a lot on PAC, acceptance approach, etc, however, I haven't given specific examples of how they really look like. You can find this in the section Templates

4. Conclusion
The project sign-off is something we can control and achieve as expected. Lance Armstrong has won 7 seasons of Tour de France which is the toughest tournament of the world because he and his team

understand the game and practice carefully. Similarly, if you understand the method, you will have client accept your project as planned. A very short review is:

* Having client agree on the criteria
* Having client agree on the acceptance test plan
* Communicating to make the plan happen
* Asking client for signing off when the project meets the criteria

SCRUM YES/NO

While there’re still discussions and arguments on applying SCRUM, it does exist. One day, you may be requested by your client or your manager to use SCRUM in one project. SCRUM may or may not be a good model, but there are some circumstances you should say "NO" to SCRUM. 

1.       Introduction

This article is to share one project which is failed in applying SCRUM and the lessons learned on it. Because it is an Outsourcing project on new Application Development, this article will so only cover this type of project.

The intention of this article is not to against using SCRUM, but it will provide a checklist to evaluate the factors around the project context to see whether or not we should move on with SCRUM. 

2.       The case study

Paul is Mike’s client. When Paul comes to Mike’s company to outsource one project, Paul only has a list of features which he expects to have in the software product to be built. It will be a B2B enterprise application. Moreover, Paul also wants this project to be run under SCRUM model. Mike builds a team of 6 people, including 4 developers, 1 technical leader and 1 tester. Mike is the SCRUM Master. In the first few weeks, Paul is very happy when he often sees new screens and new features delivered after every two weeks. (the sprint cycle is two weeks) Mike also applies most of the principles of the SCRUM, including product backlog, sprint backlog, burn down chart, Sprint planning, Sprint daily meeting and Sprint retrospective meeting. However, because Paul is often busy, Mike hardly arranges time to talk with Paul about which stories should be planned for sprints. Especially, Mike can’t arrange time with Paul for Demo sections after every sprint. Instead, Paul often reviews the products offline at his spare time and sends back the list of findings (bugs or change requests) to Mike. Sprint by sprint, Mike keeps delivering new products, he also includes high prioritized bugs and important changes into sprints. This makes Paul feel happy as he thinks his system will be ready soon. After 6 months, Dan who is Paul’s manager asks Mike to plan for the first version to go live. Even many features have been built but some important ones are still not available. Looking into the list of bugs and change requests with more than a hundred items, Dan begins worried. Dan asks Mike to give some artifacts such as Architecture & Design, Unit Test reports, System Test reports etc. but Mike couldn’t give sufficient documents and reports because they were not planned to be done. Dan asks his Technical Architect to look into the project in more details technically and he’s got the result: ·         Coding convention is not at level of his expectation ·         Unit test coverage is far low from his expectation ·         The architect of the system (MVC) is not followed strictly and it will be very difficult to enhance in the future. And the worst thing, Dan’s Technical Architect suggests rebuilding the system as it is too late now to modify it.

3.       The analysis

In the above case study, there’re many reasons which have caused the project fallen into a very difficult situation, but in this article I’ll only focus the ones under SCRUM perspective. 

3.1.    Workable product and validation

The heart of SCRUM is to deliver the workable products (the output of sprints) to client as early as possible. Workable means it must be at an acceptance level of quality, otherwise, the product should be cancelled or shouldn’t be delivered.

A lot of products have been delivered during 6 months, but most of them are not workable because they were not validated by Paul, the Product Owner, yet. Without validation, Mike has delivered lots of non-workable products, there is no way to combine non-workable products together to have a complete system. It becomes a mess!

3.2.    Planning

As the nature of the Software Outsourcing industry, the Outsourcing Project Manager who is often the SCRUM Master doesn’t stand in the client’s business. He’s not at the position to make the release plan or decide on which stories need to be done first, which products need to be delivered before the other. Product Owner or someone else from client has this responsibility and the SCRUM Master is only able to commit together with the team on the deliverables of each Sprint. Product backlog and release plan should be client’s mission.

This was not the case in the story when Paul did not really pay too much attention in planning and there was no one else doing this from Paul’s company. Lacking of planning outside of Sprint cycles is like sailing a ship without a compass.

3.3.    Product Owner’s availability

SCRUM encourages communication between Product Owner who knows well on the products to be delivered and the SCRUM teams. The traditional document like software requirement specification will not be used as an agreement between two sides. Instead, Product Owner is supposed to work closely with the team, to answer questions regarding to the features to be done and give feedbacks in time on the output.

Paul didn’t have time for product validation and planning. He also didn’t invest time enough to work closely with the team to tell them what he wants. How the SCRUM team can deliver the right products when the requirement is not written and the Product Owner is not with them.

3.4.    System architect

Not everything can be planned and executed under SCRUM methodology. Even a project is managed under SCRUM there’s still something such as defining System Architecture, creating System Architecture Framework, creating Graphic User Interfaces etc should be done outside of SCRUM cycles.

The team was focusing too much on delivering products and losing focus on a bigger view which is the system architecture. As the result, the architecture was broken. The MVC architecture was assumed in mind of each SCRUM team member, but it needs to be visible and monitored the compliance of implementation.

3.5.    Scope management

Mike was asked to give the Architecture document, the test reports and so on but he couldn’t provide because he didn’t plan for these activities. Paul should have managed this. There’re other expectations of client to be managed beside the workable products such as documents, reports, standards, test coverage etc. Even none of them is required, at least it is agreed in writing. Scope Management is still important in SCRUM typed project.

3.6.    SCRUM Awareness

After all, one major problem which caused the other problems above is about SCRUM awareness of two important stakeholders, the client and the SCRUM Master. Paul didn’t commit time for the project as Product Owner, client didn’t have someone take care of planning because they didn’t have good awareness on SCRUM. Mike didn’t train/coach Paul on the methodology, he shouldn’t have kept releasing products without validation.

SCRUM doesn’t mean undisciplined purely. SCRUM does require the practitioners to follow its principles to manage undisciplined working processes.

4.       SCRUM YES/NO

Ok so you’ve seen the failure and the lessons. I hope if you are starting a SCRUM typed project, make sure you say “NO” if it should be. Actually, the boss will always expect a “YES”, but at least we see which are missing from the checklist below so that we can put them in risk management and look for a mitigation plans.

Item	Y/N	Note
[Product validation] Is it feasible to do validation on products in every sprint?		There must be the acceptance criteria which are used to validate whether the products are acceptable or workable. Something such as  no major defects, unit test coverage, architecture compliance … Client has to commit doing this every sprint.
[Planning] Product vision and release plan must be taken care of.		No matter who does this, it must be done. Normally, someone at client site should be responsible for.
[Product Owner’s availability] Product Owner must have time to stay with the team every day.		It is recommended the product owner co-locate with the team if possible. Besides, he should commit at least 2 hours per day for queries and explanation on stories.
[System architect] There must be some first sprints to do architecture. Alternatively, there must be a non-SCRUM phase for doing architecture.		This is extremely important when the application is big and complicated. Not only doing the architecture but also validating the compliance on the implementation is required.
[Scope management] Scope management must be done before starting SCRUM cycles.		SCRUM doesn’t cover fully scope management. Refer to Scope Management to see what more need to be managed.
SCRUM Awareness		Make sure you have adequate knowledge to be a SCRUM Master, make sure client has good awareness on SCRUM.

5.       Conclusion

Although this article has shared one failure application of SCRUM, it doesn’t have a negative meaning. Instead, I hope you would make the right decision when deciding to go with SCRUM.

Beside this failure, I do see other projects which were applied SCRUM successfully. Look through the checklist, it was almost complied in those success stories. Hopefully, I would have the next post on one typical successful SCRUM typed project.