24/02/2012

Tips for handling changes in one sprint

I have been working across several development houses. Changes have been forever topics for both SCRUM teams and no-SCRUM  teams. As a SCRUM Master, I have tried to stopped any changes into sprint. But attempts failed and it caused business loss too.Hopefully, my experience will help you guys and in the same time, please post comment if you have any suggestion or think my ideas are shit. So how have I been handling change in one sprint?

First of all, as SCRUM masters and product owners who works in startups and small development house,  we should "expect change" in all manners instead of resisting it as most of customers are very important to business growth.

Now we are expecting change, what we should do next? Should we just let changes in? Of course not,  team can't finish anything if you let all changes into team directly.
1. Let Product Owner know,  change will slow down projects and team productivity will be lower comparing with teams without changes.  But team will expect changes if it impact business values. Some items need to be exchanged from sprint backlog to backlog.
2. Working with team to teach them about proper feeling of urgency in fixing bugs
3. Have a tool and even specific tags/categories to track changes in one sprint
My personal feeling is most of bugs should be fixed straight away if it impacts customer and bugs which don't impact customers can be fixed in 48 hours. And tracking changes in one sprint will help you finding proper

I have found that for small startups, there are often requests of features or changes directly to development team. It must be stopped. And they should send requests to product owner instead of team members.

Now changes come and product owner agree to put that in current sprint for business reason. I have few tricks, you may want to use:
  • Ask requestor and product owner standing in front of backlog and move other stories out before move "changes" in
  • Ask requestor and product owner send email to business about there are some stories to be postponed because of new "changes"
After two or three sprints, normally I will have a feel how big of "changes" will be with tracking tools (even just with Excel). I have tried three ways after that:
  1. Leaving space for bugs and feature requests
  2. Leaving space for bugs and bug exchange feature request for stores in sprint backlog
  3. Still as before must exchange stories in sprint backlog for changes like bugs and feature requests
For different environment, the outcome are different. 2 & 3 are better than 1 from my personal feeling because with 1, some team may not have enough stories to work with some time because that there is no bugs and much fewer bugs.

 Now, we are here. Will we let every change in? Definitly not. Good product owners will block most of change request doesn't fit product strategy and business value. From my personal experience as project manager, I am intending to block most of changes which are not related with current sprint stories if they are in a big size. How big is big? Every team will have its own definition.

But finally, tracking tools will help you team decide what to do and what to try. Some companies with legacy software and experiences lots of bugs, first important to solve "changes" in one sprint is to increasing test coverage and focus on best engineering practice like code review, pair programming and others. Rewriting part of systems may be good option. Every team will have their own way to handle that because problems are mostly different from one team to another. And team with lots of changes as feature requests, shorting sprint length and splitting stories are good options. And of course. SCRUM Master needs to discuss with team members and product owner to find solution for that.

13/02/2012

SCRUM/Agile/Lean Team Building for Fast Growing Startups

Introduction


Fast growing startups face unique difficulties for building development and operation teams. Although I haven't had fully successful experience, I will share my experience across few different startups. There are successes and failures.

Difficulties


There are unique difficulties for building agile/SCRUM/Lean team for fast growing startup. The ones are on top of my list are:

(1) Uncertain about how big team will be in 3 months, 6 months, 12 months
(2) Lots of pressure from business to catch opportunities
(3) There are not enough senior team members which faciliate growth of business
(4) It is hard for business to find right candidates
(5) What is strategy for team growth, splitting team or build a new team
(6) System developed is a "Legacy" system although it just has been developed from 1-2 years ago

Of course, there are lots of others. If you want to share your experience, feel free to post here.

My Solutions


I will post my solutions and ideas here for broad discussion. And hopefully, with that, we can work together to find few best solution fits for several scenarios. Feel free to give critic and feedback. I love to hear them.

Agile Way to Find right candidate


For whatever reason it is, my personal experience with few startups are that team member growth and budget are uncertain. Most of time, recruitment will be managed by top level management who has technology exposures like General Management of Technology, CTO or others.

We have personally tried or experienced following ways:

- Start with contract and then moved as full time
- Have a graduate who gona graduate in next 6 months, and have him onboard fulltime after his/her graduation
- Interview someone and have he/she onboard if he/she is right candidate
- Buy a company for its development team members

Every way has its own advantage and dis-advantage and it fits for different purpose:

(1) Start with a contractor give business an opportunity having a look at candidate's skill set for a high pressure. It fits that there are spike for one or two major projects which have hard due date and current resource can't handle the project anymore.
(2) Have a fresh graduate or someone who gona graduate is big fun and interesting. Most of them love technology and work very hard with my experience. Most of them are willing to stay if company can offer reasonable salary package. It fits for projects which require unique skills. The advantage of this way will be low cost and outcomes are normally very good. The dis-advantage is that there are risks that developers may leave in short time and it takes time educate. If there are enough senior team members, this way will be best going forward. I have successfully mentor most fresh in past 3-4 years.
(3) Have someone full time after interview. I always am keen to recruit right employee instead an employee. For fast growing company, it should never stop looking for a best candidate.
(4) Buy a company which has unique skills that we require. There are many companies who have big budgets are doing these. The advantage is that new team members can pickup skills very quickly. Disadvantage is that costs are too much. Google even just throw product away and have team members to do other things.

The "Agile" way that I want to prompt is to try different choices and add team members one/two at once. My personal preference is (2) because most of time, the outcome is fantastic.

Cope with uncertain of team size


Uncertain of team size has been a big problem for me all the time. But it has been natural for most of startups.

There is a rule that I always follow "always solve current resource shortage" instead of "trying too hard to solve future problem".

I personally find out the "cumulative" diagram are extremely helpful to decide whether current resources can cope with workload that we have.

Senior VS Junior Candidate


For any company, it is good to have as many senior members as possible. But the reality, it is hard to rightful senior candidate for a startup working in niche market. Most of time, senior team members are familiar with other technologies which are different from the technologies you gona to use. At the moment, I am more towards to team members with 0-2 years experience which can be trained to use technologies which you are familiar with.

With my experience, a candidate without experience and lots of passion on technologies and business are far better than a candidate with more than 3 years experience and has not progressed well in career.

But the skills that you need to look out for are:

(1) Communication
(2) Over-Engineering (lots of candidate are intended to do over-engineering. It is hard to change the habit.)
(3) Be able and willing to talk with users directly
(4) Strong skills and knowledge background

Team Growth, Splitting or Build a new team


There are arguments about splitting or build a new team while team grows very quickly. I am more towards splitting team, the following are my points:

(1) The most important part for development to spread is "domain knowledge". Without splitting team, it is very hard to do so esp for startups
(2) The most concerning part for splitting team is bond and connection. If we can keep most of one team unchanged, the impact is small.

My solution for agile team growth are:
(1) Let a team grow to 8-10;
(2) Split 2-3 team members out as base for new team
(3) Try to train new team leader / SCRUM Master while team growth period

Legacy System


The startups that I have worked with have the same problem, a legacy system. There are general two ways to get test coverage up:
(1) Get test written for new jobs
(2) Write a new system from ground up and make sure that at least 95% test coverage

Difficulty of first way is the difficulty in calculate test coverage. But I am strongly towards first way as risk on re-write a system from ground up. But an alternate solution would be enforcing test cases on new jobs on old systems and write test cases on new systems to make sure test coverage if there are architecture problem in old system.

I am personally find that it is very easy to use the first method if you are able to get test coverage for existing system. Ironically, sometimes, I am able to easily calculate test coverage for one system but it is very hard to calculate for another. I just find it is very hard for most PHP systems.

If you are starting new projects and want to choose a framework, you need to choose a framework with test written.