Agile in One

When I provided some internal training about Agile Scrum in my current company, I was often being asked that since there is no standard way for Agile adoption, why it is still recommended to follow some practices, like Daily standup in Scrum as well as other activities. Since team has the right to figure the best way to work, why the team is not recommended to remove some activities.

My thoughts are that, the answer about the questions is not say NO to make changes for practices, but about when you may change it. Yes, an Agile team can choose the way for their practices, but it should based on the right understanding about Agile value.

It really like people to practice Yoga. For a beginner, he/she should follow the guide of the coach to practice the very basic exercises. Those exercises will help the person to practice how to control his body through smooth breath and motif and then to achieve the inner peace. Coach will also requires the students to follow the guideline even most of them will feel uncomfortable at the beginning. With continuous practices, people will feel their body to become more relax and soft. They may start to be able to control their breath and thoughts. Then they may start to practice new exercises or even start to create some exercised by themselves in order to achieve higher level.

For new Agile team, it is very similar. They may not understand the Agile value very well at the beginning. They also may not understand the behind reason of many Agile practices. But if they may insist to practice with good coach and guide as well, they may gradually get the point. Then they may start to try to figure out some better way to realize Agile values by changing some practices.

The similar philosophy is Shuhari what is like “"first learn, then detach, and finally transcend”.

Recently one of my friends asked me to give an introduction about Agile for a company who is developing embedded system. I have no experiences in embedded system development. So there are some questions in my mind about it.

1. What’s the major difference between embedded system development and other software system development?

   I think the major one might be that embedded system development needs to deal with some hardware directly through low level I/O talk. So that means the only way to validate the system is completed or nor is to upload the implementation to specific hardware and check the hardware status.

2. What’s that difference going to impact the agile adoption?

   Just a guess, I think the major impact will be the definition of DONE. Ideally we hope the team may be able to create releasable functions incrementally iteration by iteration. But for embedded system, it will be impossible to achieve it because most of time it might be very difficult to have the relative hardware by ready to test the codes. Many of cases, hardware design team is separately with software implementation team. Also it might be very expensive to create hardware with iterative and incremental way.

So, how does a embedded system development organization to adopt Agile practices? My thoughts are

When I introduced TDD in the company, for example, organized Code Dojo for some teams, one of the most common question was, how to deal with complex system? would it cause technical issues if just start from a test case but not architecture design?

Many times, when people tried TDD, they considered intuitionally that TDD just kicked design out and implemented system piece by piece. I think it is a misunderstanding about TDD.

I used to drive in Australia along Great Ocean Road started from Melbourne. Before I starting off, I asked help to people of car renting agency about the way. The kind young man drew a way on a map and told me to follow the guide. Then I began my travel. On the way, my wife sat aside me and guide me with the information like “turn left next corner”, frequently. And she would also help to check the road sign to see if we were on the right way. Even this, I still drove to the wrong way in a small town. In order to find the right way again, I stopped the car and asked a local woman for the direction, based on her guide, I found the right way soon.

Software development is very similar with this situation, especially to implement a complex system. Before we start the implementation, we still need to have some degree understanding and agreement for the big picture. So some design is still necessary. But it is impossible to predefine everything in advance, even you spend many times on that. Just like, you will never be able to sure the real road on the map. So the most important thing is to drive on the way as soon as possible when you have a map to the destination. So we may get to know the real situation earlier. When we are driving on the way, even there is a map, it is still highly possible to lose the way, may caused by invalid map information, or a mistake and etc. So, in order to make sure we won’t drive on a wrong way too far, we need to check it frequently. The way of checking will be something like checking road sign, asking people and etc. Actually all of those are the feedbacks to tell us if we were on the right direction or not. In software development, the test, especially automatic test, like the road sign, is one of the important feedbacks to tell us if we did right or not. In TDD, we will write the test case first to set up the expectation first, so the test case will tell the code where the expected behavior is. Then the code should be implemented to pass the test. If it was failed, then we know that the way is wrong and need to go back immediately. So it will prevent us to go on the wrong way too far.

So, TDD doesn’t mean no design. Design will provide a map to the implementation and so that the team may know the big picture and destination. TDD will be able to let the team start to work on real things earlier, you won’t need (actually you cannot) to have everything be designed in advance. All of the test cases will provide very quick feedbacks to tell if it was correct or not when you try to implement the system step by step.

Today we organized a coding dojo in the company as the first time. We invited some colleagues who were familiar with C# and TDD.

Coding dojo is a kind of activity that let people to sit together, code together and learn to each other. Basically it will involve about 5 ~ 20 people in a meeting room with at least one computer, a projector, a round table and enough seats. The way of coding together is follow some simple rules

1. Pair programming
2. TDD
3. Baby steps of implementation
4. Time box for each pair
5. More coding, less talking. Share your experiences or knowledge through coding

There are 3 roles during the activity:

• Judgment: Control the time, facilitate, help the procedure be smooth
• Driver: Control the keyboard, implement the solution
• Pilot: Site with the driver, discuss with the driver about the solution

Since it was the first time for us to organize this kind of activity, the major purpose for us was to let people be familiar with the process and get their feedbacks. So, the way of our organization was

• Choose a not-so-challenged topic. Today we decided to implement a FIFO queue with C# plus NUnit;
• The time box for each pair was 20 minutes. After it, there were 5 minutes for discussion and comments;
• The way of rotation was that, the pilot of previous pair would be the driver of this pair. One new people would be the pilot of him/her;

This first time dojo took about 2 hours, and completed 4 rounds of pairs. The FIFO queue was fully implemented with 100% test code coverage.

During the short retrospective, some questions had been raised:

• How about the negative impacts on productivity for pair programming?
• What will happen if we try deal with real challenge topic?
• It seems that there will be many efforts on test cases’ maintanence, is it a good idea to have a test cases list document?

Almost everyone agreed that this was a interesting way to share the expereinces, for next dojo, some good suggestions are

• Organize one coding dojo for one team and try to resolve a real challenge topic in the project;
• Organize coding dojo that cross different teams and try to resolve more challenge topic, like “Dug Mine”;
• Prepare answers for some common basic questions, like TDD concept;
• Have a principle that only ask questions that related with current pair’s coding and leave other questions to be asked during the 5-minutes interruption. That will be helpful to let current pair be focus;
• Prepare a whiteboard to log the questions;
• Give clear introduction of topic requirements to reduce the discussion about the criteria of delivery;
• It will be better to start from a pair who were familiar with coding dojo and TDD

Today I found a blog posted by Ron Jeffries on 2004 and the topic is “A metrics leading to Agility”. In this artical, Ron suggested a metrics for team which one actually would help the team to be Agile. Its name is Running Tested Features (RTF), and it will measure the number of passed acceptance tests for each iteration from project day one till the end.

• Running means that the features are shipped in a single integrated product.
• Tested means that the features are continuously passing tests provided by the requirements givers — the customers in XP parlance.
• Features? means real end-user features, pieces of the customer-given requirements, not techno-features like “Install the Database” or “Get Web Server Running”.

With Ron’s point of view,

• RTF requires feature count to grow from day one. Therefore the team must focus on features, not design or infrastructure.
• RTF requires feature count to grow continuously. Therefore the team must integrate early and often.
• RTF requires features to be tested by independent tests. Therefore the team has comprehensive contact with a customer.
• RTF requires that tests continue to pass. Therefore the tests will be automated.
• RTF requires that the curve grow smoothly. Therefore the design will need to be kept clean.
• With RTF, more features is better. Therefore, the team will learn how to deliver features in a continuous, improving stream. They’ll have to invent agility to do it.

And an idea curve of this metric will be like

Personally I think this is a very good one because it will measure both quality and velocity. And provide rich information for the team. And another very important thing is that, everyone, include customer and team, will really care about it. Unlike some other metrics, rare person or team will game this one.

You may find the original article here.

In software project management, more and more teams start to practice Agile in the project execution, Scrum, XP, FDD and etc. But, what’s the Agile mean when we say we are using Agile process? Is it mean that the process will be faster than traditional way with higher productivity? Many of new practitioners will put equal mark between Agile and Fast. Obviously there are some misunderstandings. It might because of we call it “Agile”

So, let’s go through Agile Manifesto and guide principles first.

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

Guide Principles

• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Face-to-face conversation
• Working software is the primary measure of progress
• Sustainable development
• Continuous attention to technical excellence and good design
• Simplicity is essential
• Self-organizing teams
• Regularly review and adjustment

Based on all of those introduction, you can find words like "Welcome changing, frequently, excellence" and etc. But you cannot find any words mentioned faster. So, what’s Agile meaning? I found a tag cloud from internet that gives a very clear answer.

What agile  really care is about “Working Software”. That should include two aspects

1. The software should provide the functionals that users want to have
2. The software should have high enough quality that users can use it without problems

Above two, make up “Customer Value”. So, as my personal view of point, Agile is really focus on the value but not speed. To achive that, we need to

1. Deliver  customer value early and frequently
2. Respond to changes fast

Someone may ask, does “Deliver early” mean faster? Actually, not exactly. Agile team will focus on deliver the highest value funtionals to customers with high quality. For a matual team, if the team was experienced on Agile pracitices, like TDD, CI and etc., and related technologies and domain knowledge, it is possbile for them to have high productivity as well. Like ski, if we have high ski skills, we may move very fast. Otherwise we will fall down and even being hurted. It is same for an agile team. If the team is chasing the high productivity but miss the delivery quality from the beginning, the quality issues will be accumulated and sooner or later, the team will be slown down because they need to fix those issues before they can continue move forward. The team will feel difficult to have stable pace of each iteration. They will just like a low-skilled ski person to rush from the top of mountain, and will be very fast at the beginning, but fall down soon when they meet some obstacles on the way.

Welcome to visit my site. This site is used to share my thoughts, experiences about Agile and technologies that I am learning. Hope there were something helpful to you

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others?

To answer this question, the first thing we need to consider is what kind of responsibilities PD will take? From my personal view of point, it is requirements clarification. All of the works of PD actually provide a very detail information to the team about requirements. So, it seems that PD should be better to work with product owner to figure out the scope. The team structure may like this (Figure 1).

Figure 1 

In this structure, PD will be the assistants of product owner and help him/her to make the requirements. The product owner will setup product backlog and PD will provide relative design for each user story. The design may include UI, workflow and etc. During the Sprint planning meeting, team will work with PO and PD together to make Sprint backlog. And product designer could show any kind of design to the team to give detail information about the user story. It could be a flash, a MS visio doc, a PPT, a hand-drawing paper, or just write/draw on whiteboard and take a picture. PD can also help to answer any team’s questions about requirements during the Sprint implementation.

This kind of process won’t ask PD to complete all of the detail design for the whole requirements from the beginning. PD needs to finalize the design for the coming Sprint. That means PD’s work will be ahead of team’s work at least one Sprint. They can also work with a separate Sprint. The collaboration with Team just like Figure 2 showing.

Figure 2  

The benefits of this kind of process are

1. Setup very clear responsibilities to each role;
2. PD can focus on high priority requirements design;
3. Complex design documents are not required and it will enable PD to consider real value things;
4. Collaboration between PD and team is smooth and close.

Another very value thing of this process is that, after each Sprint, PD will get a workable software to do the user acceptance test. It will be very efficient way for PD to validate the design. And any issues caused by incorrect design can be found at very early stage. And the issue can be fixed in the following Sprints. This is also very helpful to provide high quality software.