Skip to main content

Posts

Showing posts with the label Scrum

Scrum eventually is also a tool to grow the team

Agile is a fit for our company business. We use Scrum practices as our Agile framework. Eventually, Scrum is just a framework that helps us work together to develop, deliver, and maintain our products. Moreover, it is also a tool to grow the teams. By practicing Scrum long enough, we will gain the great following values: Commitment Focus Openness Respect Courage --- [1]. https://agilemanifesto.org [2]. https://www.scrumguides.org/scrum-guide.html

Consulting Services

The topic is about my experience on my first project with my freelance team. We implement the last step of this process which you can find in the end of this post. You might have heard of something like the following: Many customers don't know what they want. Yes, that's a fact. In order to help customers solve their needs, we'd better consult them or we provide a consulting service. The next questions is "how?". Our approach is enhancing the collaboration with customers or providing a design of customer interactions. Firstly, we create a website wireframe to express the idea of website's functionalities. For example: Source: Wikipedia And, the further step is that we make a running app based on the created wireframe where the real UI/UX is demonstrated. However, it is just a GUI/frontend with dummy data without interaction to a backend. Technically, that is just a html template which contains source code of HTML, CSS and Javascript. For exampl

My 2017 Review

Passion for System Design After finishing a one year project, my longest stable team (lasted for 3 years) was separated into two smaller teams. Sadly, but that was a good chance for me to become a key member in my new team. My preferred skills were about system architectures; therefore most of the tasks of building the application structures were handled by me. In order to enhance my design system skills, I have spent much my time for reading books closely after work. These following books help me a lot. - Object-Oriented Thought Process | Matt Weisfeld - Head First Design Pattern  | Elisabeth Freeman and Kathy Sierra - Java 8 in Action: Lambdas, Streams, and Functional-style Programming | Alan Mycroft and Mario Fusco Junior Technical Architect I was requested to join a technical architect team (aka Team. Alpha) where I actually had gained experiences almost on interviewing candidates for my company (lol). Besides, I noticed myself must improve the skills of convincing people

The 2017 Scrum Guide, and My Notes

https://www.scrum.org Scrum is not only designed for software development Scrum can be used for addressing any complex issues: 1. Research and identify viable markets, technologies, and product capabilities; 2. Develop products and enhancements; 3. Release products and enhancements, as frequently as many times per day; 4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and, 5. Sustain and renew products. Scrum Values is a key factor for building trust and respect among team members The five values are: 1. Commitment 2. Courage 3. Focus 4. Openness 5. Respect Daily Scrum's questions are more focused on inspection and adaption rather than the status 1. What did I do yesterday that helped the Development Team meet the Sprint Goal? 2. What will I do today to help the Development Team meet the Sprint Goal? 3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Evolution of Team Collaboration

I n my point of view, if a team has a good collaboration, team members will achieve the following: To be more effective To make work more enjoyable I 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 collaborate For example, that is when the team members have the following issues: Only work on his/her area of expertise Don't communicate to others Be not confident to take on new challages Don't listen to other members. Subsequently, the team has

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 do

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. Acceptance test with Given When Then pattern 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

Updates to the Scrum Guide - The 5 Scrum Values

This article is available at blog.scrum.org , 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 t

Why Agile and Scrum Matter

Changes is constant, software development as well. Do you know the development of mobile phones, starting from Motorola DynaTAC (1973) to Iphone 6 (2014). How about the software? The new versions are released with new improvements. Software is not always able to automatic repairing. Therefore, software should be changed frequently and we need responding to changes. source:  http://answers.microsoft.com/ In working software today, how about customers' collaboration or requirements? We ignore the fact that many customers don't know what they want . We ignore the fact that when they know what they want, they can't describe it . We ignore the fact the even when they can describe it, they often a proposed solution rather than a real need . We ignore, that a lot of customers g ive us a solution but not the problem . source:  http://accelerateddevelopment.blogspot.com/ And, in working process, earlier founded bugs are cheaper. Manifesto for Agile So