Pages

Saturday, August 17, 2013

Learnings of the first time scrum master

Agile is becoming the de facto standard for enterprise application development. I also decided to join the band wagon so I joined a agile project as a developer with only theoretical knowledge about the agile programming. The team had 3 more developers, 2 testers, 2 BA's (one of them appointed as the product owner by the business) and a project manager. The scrum master managed some other projects as well so he could not spend enough time on this project and I was asked to do scrum master role which I accepted very reluctantly because no one in the team knows agile but for organizational reasons the project is called agile project.

From the beginning the project had many issues. We have used JIRA to track user stories but since the product owner had no idea about agile or how to use JIRA, his user stories tend to be one liners like implement security, implement web service, etc. We had user requirements documents for front end (which details the various requirements, screen mock ups, validations etc), requirements for batch process,
interface specs for web services in word documents etc. Worst of all, we had very tight dead line 6 months as well for the project development. The project manager is a good guy but very soft and also don't know about agile so we had very hard time deciding the scope of the sprint, implementing it and demoing it. After some time it became clear the project is not going well and we are not going to meet the deadlines.
The issue has been escalated to the program manager and he stepped in. The project became smooth in couple of sprints.

He didn't do anything magical but some how he brought the project back on track.

Determine the size of the project:

Determining the size of the project is very important activity. We didn't know how to do it because the requirements catered in various places (JIRA, various requirements documents, white boards, excel sheets, as defects in QC). The first activity to be done is consolidate everything in one excel sheet by listing down all the requirements and creating sub tasks where possible for each requirement. If you don't know the sub-task leave it as it is. Then do a T-shirt planning. You give size for each requirement in terms of small, medium, large, XL, XXL. Take a well known and well understood requirement and give a size for that requirement. For example, creating a web service could be medium sized requirement. Relative to this requirement
decide the size of other requirements. At the end of the exercise, you will have number of requirements of various sizes. For example 10 small, 5 medium, 10 large, 2 extra large and 1 XXL. See the team size and amount of time left to complete the activities and you will get a clear idea when you can finish the project. It will give you insight of the actual size of the project. We found out that,with the current strength it will take 8 months to finish the project (we found this 4 months after the project start) So clear indication that team size has to be increased.

The team:

A very important factor for successful agile project. The team should be cross functional and should be able to handle various functional and technical tasks. The team I worked with, compartmentalized things (I will work only in front end, I will work only in the back end) and wont touch the technical items (like deployment, solving complex technical issues) etc

Politics:

IT projects are not always about technical capability but it is also about organizational politics, background and culture of the team and the challenges it brings to the project. In our case the team is mixture of developers from two different vendors so there was some tension, also the PM and Product owner are internal employees of the organization so they were not too much worried too much about the project status.

Decision Making:

The major hurdles in any IT project is also about the decision making. The stakeholders take too much time to take decisions.Technical architect thinking about whether to use Queue's or Web services, business owners thinking this way or that way. Decisions has to be made after careful considerations but there should be deadline for every decision. If the project manager or scrum master is not able to force the decisions it impacts the team velocity and at the same time, affects the morale of the team because there are simply too many loose ends and too many user stories not completed and pending in various stages. The scrum
master should be able to speed up the decision making and if not possible escalate to the right level to get things moving. Same process applicable for other dependencies (environments set up, services to external systems) deadlines have to be agreed and if not honored has to be escalated and get it done for smooth progress.

Honest feedback to the team members:

The team members though senior people, still make mistakes in terms of creating quality code, solving technical issues. One of the team members code is very bad in terms of quality, no junits & too many defects. Other team member took too much time to solve even trivial issues which should be very simple for a developer with 10 years experience. As a scrum master and with different cultural background, I tend not to discuss the issues with them but try to solve the issues by myself which turned out to be very difficult after some time. After the new scrum master came in, this developer was kicked out immediatly and the
other developer was warned. I should have spoke to these guys and asked them to improve or move out. I didn't have the confidence to do the same. I have spent long nights trying to correct the mistakes others did which is not good in the long term.

The summary of the learning's

1) Set up a good team with good technical people. Strong manager and strong scrum master is essential for team success.
2) Understand the size of the project using appropriate methods (T shirt planning for example) and see whether the team has the capacity to meet the deadlines
3) In agile team though every one is equal, The scrum master and project manager are more equal than the rest of team. They should
1) Control the team and give honest feed back to the team
2) If team member not improving, don't hesitate to replace the team members
3) Identify the impediments and resolve the impediments in reasonable time frames
4) escalate to the right levels and get the impediments out of the way on time for the team to continue
4) Understand the underlying organizational politics and subtle issues and make sure that is not impacting the velocity of the team. If not resolved
1) Teams will be divided and each one will be working as silos not knowing what others are doing
2) Team not jelled well, take more time to complete the tasks because of communication issues
3) Dont hesitate to change the team in case above approaches not working.








 
Blogger Templates