Skip to main content


Showing posts with the label Agile

DevOps for Dummies

Everyone talks about it, but not everyone knows what it is.
Why DevOps? In general, whenever an organization adopts any new technology, methodology, or approach, that adoption has to be driven by a business need.

Any kind of system that need rapid delivery of innovation requires DevOps (development and operations). Why?
DevOps requires mechanisms to get fast feedback from all the stakeholders in the software application that's being delivered.DevOps approaches to reduce waste and rework and to shift resources to higher-value activities.DevOps aims to deliver value (of organization or project) faster and more efficiently. DevOps Capabilities The capabilities that make up DevOps are a broad set that span the software delivery life cycle. The following picture is a reference architecture which provides a template of a proven solution by using a set of preferred methods and capabilities.

My Remarks Okay, that sounds cool. What does it simply mean, again? The following is a simple case…

Agile Design

How can you design the software which is built in tiny increments?

How can you ensure that the software has a good structure which is flexible, maintainable and reusable?


Not really! In an agile team, the big picture evolves along with the software.

How? With each iteration, the team improves the design of the system so that it is as good as it can be for the system as it is now. They focus on the current structure of the system, making it as good as it can be.
How do we know if the design of software is good? Avoiding these following symptoms of poor design (design smells) should be a way.

1. Rigidity - The design is hard to change.
2. Fragility - The design is easy to break.
3. Immobility - The design is hard to reuse.
4. Viscosity - It is hard to do the right thing.
5. Needless Complexity - Overdesign
6. Needless Repetition - Mouse abuse
7. Opacity - Disorganized expression

These symptoms are similar in nature to code smells, but they ar…

The Evolution of Team Collaboration

In my point of view, if a team has a good collaboration, team members will achieve the following: To be more effectiveTo make work more enjoyableI have been working for a company for nearly four years as an software developer. Working on various projects from maintaining existing systems to developing a substantial product resulted in me moving to new teams three times. Actually, my most stable team lasted only around three years. 
Every time I've moved to a new team, I have a chance to work with new members and a new team culture again. Indeed, I realize that there is a process of developing the team collaboration which gets better time by time. I think it is an evolution! Phase 1: Poorly collaborateFor example, that is when the team members have the following issues: Only work on his/her area of expertiseDon't communicate to othersBe not confident to take on new challagesDon't listen to other members.
Subsequently, the team has some Failed Sprints and the knowledge gap betwe…

Avoiding Time-Wasting Pitfalls in Agile Estimation

If you do Scrum at work, you might be very familiar to the estimation in Planning 1. My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated.

I give you some advice from my experience:
Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement.

The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you don't ha…

The power of acceptance test

User Story is the place PO gives his ideas about features so that developers are able to know what requirements are. Acceptance tests are these show the most valuable things of the features represented by some specific cases. Usually PO defines them, but not always. Therefore, refining existing acceptance tests – even defining new ones that cover all features of the User Story must be a worth task.

If we understand what we are going to do, we can complete it by 50% I have worked with some members those just start implementing the features one by one and from top to down of the User Story description. Be honest, I am the one used to be. What a risky approach! Because it might meet a case that is very easy to miss requirements or needs to re-work after finding any misunderstood things.

I have also worked with some members those accept spending a long time to clarify the User Story. Reading carefully of whole User Story by defining acceptance tests makes us more confident. Having an ove…

Retrospective with Sailboat

Have you ever got bored with the Retrospective meeting? I have, sometime. Most of the times, this meeting just goes traditionally by answering three questions: "What good things have we done? What bad things have we done? And, what actions should we improve?" Ever and ever again! My team found a way to make it a little bit more exciting. The idea is that each member - not only our Scrum Master - will become a host. If a meeting is hosted by a memeber, the next meeting will be hold by another one.

Yeah, I used "Sailboat" pattern in my turn. So, I just want to share with you guys how it was.
I started the meeting by telling a short story that I hoped everyone in my team could recall the meaning behind of Retrospective meetings:
There is a group of people trying pick up trash in a park. At the first look, the park seem not to have a lot of trash because they are spread out all over the place. However, these people continuously found trash when they started. They kept …

Updates to the Scrum Guide - The 5 Scrum Values

This article is available at, here I just quote my favorite points and give my comment at the end of this post.

Ken Schwaber and Jeff Sutherland, the creators of Scrum delivered a webinar on their latest update to the Scrum Guide.  The update was a simple one, adding the 5 values of Scrum to the Guide:

These values sound easy? Well, there are many misunderstandings and common problems when applying these values. Here are some example:

Value Misunderstanding Getting the value right Commitment Committing to something that you don’t understand because you are told to by your boss. Committing yourself to the team and Sprint Goal. Focus Focusing on keeping the customer happy Being focused on the sprint and its goal. Openness Telling everyone everything about all your work Highlighting when you have challenges and problems that are stopping you from success Respect Thinking you are helping the team by being a hero Helping people to learn the things that you are good at and not judging the t…

Meaningful Names - Code Review Checklist with Example

"Names are everywhere in software". "The hardest thing about choosing good names is that it requires good descriptive skills"[1]. In my previous post, I emphasized that we should take care our code, so now let's start with naming.

Issue Original code Revised code Reveals nothing int d; //elapsed time in days int elapsedTimeInDays; Difficult to understand public List<Cell> getThem()
public List<Cell> getFlaggedCells()
Specific to programmers accountList accounts

If We Want to Go Fast, We Need to Go Well

Have you ever thought that we won't need to code anymore because programs might be generated from specification? The answer can be yes or no; there is still arguing about it.

The programming language is more and more closed to the requirements. The starting is from a very low level as Assembly to a very high level like Python. However, it doesn't make much sense when saying that we will eliminate coding. For me, we currently still need to express our ideas in exact words that tells the machine what we want. Otherwise, I hope in the future the machine is intelligent enough to understand our requirements directly from our words. ;)

Take a look at the famous quote of Robert C.Martin about what I mentioned above:

"Remember that code is really the language in which we ultimately express the requirements. We may create languages that are closer to the requirements. We may create tools that help us parse and assemble those requirements into formal structures. But we will never e…

My impression of Google I/O 2016

I have not yet had a chance to attend this event but I just watched it on Youtube as usual. :)
Google Assistant You might be very familiar to Google Now if you're Android fan. I saw that Google Assistant is like an upgrade to Google Now. It looks smarter because we are able to make a conversation with Google rather than just saying "Ok Google" and getting the tasks done as Google Now. That means Google Assistant can understand our personal words in our contexts.

For example:
I: Who is Google CEO? Google: Sundar Pichai I: Show me his awards  => Here I don't need to say "Show me Sundar Pichai awards", because I don't know to pronounce his name correctly. :)
I am thinking about that we can compare Google Assistant to Siri of Apple. Google Home At Google I/O 2015 last year, Sundar mentioned about working on a exciting project with Internet of Things and I think Google Home is a result. Working with Google Assistant, Google home is a very smart and modern devi…

How to apply Lean - Kanban for your business

This is the topic of Scrum Breakfast meetup this time, speaker: Ms. Phuong Bui - Technical Project Manager of YOOSE Pte. Ltd.
Lean comes from Lean manufacturing is a method that focuses on elimination of wastes. In other words, this is a set of principles for archiving the quality, speed and customer alignment. The first time I knew about the term "Lean" is  from the book Software Craftsmanship. Sandro recommends if we want to transform our pet projects into a real business, we should get familiar with Lean Startup concepts.

In this talk, Ms. Phuong pointed out some major wastes includes information (ex: unclear requirements), processes (ex: waiting), physical environment and people. Knowing what the problems should be the best way to eliminate them.

The difference between Single item flow and Batch processing is the second main point; and it is the Lean's idea. Batch processing perform…

Agile Testing - A defense system from my team stories

Today, I would like to tell you about my team stories from no testing to extreme testing system.

I think that is really an exciting idea from the picture above because these devices can work with Jenkins. Whenever they build the Jenkins jobs, this system notify instantly to developers the status of their system.

That is not 100% related to testing but somehow it is like our testing mindset. Because, in my team,  we call our testing system is a defense system - just a metaphor. :). As we know, it is very hard for us to remember all features of our applications even which is developed for a long time. Like a document, tests help us make sure no features will be lost after changes such as adding new more features, fixing bugs or refactoring code.

That is the reason why we care too much about testing. It is really important for developing apps. Next, we think about how to test effectively.
The "testing pyramid" points out that basing on the efforts, the agility of detecting bugs…

Software Craftsmanship by Sandro Mancuso

My first time to know about the term "Software Craftsmanship" is from Agile Tour Vietnam 2015. I finally read this book written by Sandro Mancuso who I met at this event.

Software Craftsmanship is a metaphor for software development: software as a craft and developers as blacksmiths. In other words, Software Craftsmanship is about professionalism in software development.

The Software Craftsmanship manifesto:
Not only working software, but also well-crafted software: regardless how old the application is, developers can understand it easily; high an reliable test coverage, clear and simple design, business language well expressed in the code.Not only responding to change, but also steadily adding value: constantly improving the structure of the code, keeping it clean, extendable, testable, and easy to maintain; always leave the code cleaner than we found it.Not only individuals and interactions, but al…