0 penilaian0% menganggap dokumen ini bermanfaat (0 suara)
150 tayangan57 halaman
Daily Stand-up is a wonderful communication tool where all the team members are on the same platform to communicate the status. You need to keep a list of all the action items, issues and follow up items in the Microsoft Notes under the sprint # page. If you are executing project in distributed environment, you need to have a conference number, skype, GoToMeeting tools for the effective daily stand ups.
Daily Stand-up is a wonderful communication tool where all the team members are on the same platform to communicate the status. You need to keep a list of all the action items, issues and follow up items in the Microsoft Notes under the sprint # page. If you are executing project in distributed environment, you need to have a conference number, skype, GoToMeeting tools for the effective daily stand ups.
Daily Stand-up is a wonderful communication tool where all the team members are on the same platform to communicate the status. You need to keep a list of all the action items, issues and follow up items in the Microsoft Notes under the sprint # page. If you are executing project in distributed environment, you need to have a conference number, skype, GoToMeeting tools for the effective daily stand ups.
How to conduct the Daily Stand-up / Daily Scrum meeting effectively?
As a scrum master, this is one of your most important daily activities to hold the daily scrum meeting same time and same place every day. But believe me it is not that easy as you are thinking. You need to think that how this daily stand up can bring value to the project. You should always try to create some tools, methods, practices by which you can bring more and more value in the project. This is a wonderful communication tool where all the team members are on the same platform to communicate the status.
There are some rules for this meeting: 1. Who should participate - Product Owner, Scrum Master and Team. Other stakeholders can also join the daily stand up sometimes but they do not have right to speak. Only the PO, SM and team can speak in the daily stand up. 2. Duration: 15 minutes meeting - if meetings are going beyond 15 minutes then SM need to find out ways to finish it within a range of 15 min. 3. Agenda of the meeting: Some points that each team member to answer: 1. What did I do since last meeting 2. What I am planning till next meeting 3. Team member to talk about the impediment if they have any. 4. I keep a list of all the action items, issues and follow up items in the Microsoft Notes under the sprint # page. I review all the open items and ask who is working on the open items. 5. Distributed Team: If you are executing project in distributed environment, you need to have a conference number, skype, GoToMeeting tools for the effective daily stand ups. 6. Burn Down Review: All the team members should update the Agile Management tool on a daily basis in terms of the effort burn, real status of the task assigned to the team members. This will be required to review the burn down in the meeting. 7. Weekly Extended Scrum: This is one of the best practice that I always perform. You need to get more information from the team on a weekly basis. You cannot finish this in 15 minutes. So I schedule a 30 minutes extended meeting on every Monday. Main agenda of the meeting will be: 1. Create/plan the current weekly goal Scrum-Agile - 2
2. Review the weekly targets set by the team during the planning 3. Review/Update the agile management tool based on the efforts, task status 8. What I always do is to make my notes every day and for my tracking I do compare the notes from previous day. This help me as a scrum master to track things better. 9. All the team members reach on time. When we expect the meeting to finish the meeting in 15 minutes then each and every second is important. 10. This is not a problem solving meeting. If you feel that there is some topic that needs more discussion then as a scrum master, you make a note of it and discuss it post scrum and only required participants can stay in that meeting. Ideally daily stand up should happen in the morning time so that team knows what is their today's goal but in the offshore-onshore scenario, it happen in the Indian evening time and US morning time.
At the end of day, the main purpose of the daily stand up is to solve and track the impediments so that team members can continue working on the engineering activities. And another one is to check the sprint health whether team is on their track to meet the commitment. Based on the information collected during the daily stand up, scrum master can plan his day accordingly.
Scrum-Agile - 3
Scrum Master Roles & Responsibilities Below is the Scrum alliance definition of the scrum master roles and responsibility at the writing of this blog: The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues. Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions Removes barriers Shields the team from external interferences Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning Facilitates the daily scrums
Scrum Master according to me is the most critical role in the project. What I learnt from my experience is that he should be a senior, mature, qualified person, who can lead the team and turn the requirements in to the working software. He should be on the floor with the team all the time. When team members are busy in their engineering task, he should keep on watching everyone and help the team members in such a way that they deliver the world class software. If you will read the responsibilities below, you will feel that we are expecting this person to be a superman, who has multiple skills. But that is what this person should be. Here are my thought on the scrum master roles & responsibilities:
1. Servant Leader - Scrum master will serve the team and product owner to turn the requirements into the working software. So as per my experience, scrum master role is a critical role in agile and one should be very cool, intelligent and knowledgeable while playing this role. Failure and success reasons will asked by this person. On one end, product owner is responsible for return on investment but execution and delivery is scrum master responsibilities. 2. Monitoring and Tracking - Team gives the commitment, scrum master has to track the progress and help the team to achieve the given commitment. Tracking is important on a daily basis so that if needed proactive measures can be taken well ahead of time. Ultimate goal is to make the sprint successful. There are various ways or rather I would say that it depends on the individual to create their own way to make things successful. Scrum-Agile - 4
3. Reporting & Communication - All the reporting about the progress of the sprint is scrum master responsibility. Risk, issues, challenges, achievements, success, failure, improvements etc will be reported by the scrum master to the higher management on both the sides customer and internally. 4. Process check master - SM is responsible for the scrum processes agreed in the project. First of all, SM creates the scrum rules for the project. Then he has to make sure that each and every process is implemented in the project. At the end of the sprint, he need to check the agile management tool at the user story level that each and every user story is completed as per the definition of done. 5. Quality master - during one of the recent discussion, I was asked whether SM is responsible for the delivered quality in a project, where project has roles like development manager, QA manager, program manager and the scrum master. If there is a bad quality, who is responsible for the quality. As per me, primary responsibility lies with scrum master and the development manager. Bad quality is the result of the process gaps, so as a scrum master you need to find out which process was not followed seriously. 6. Interface between the technical team and the business i.e. product owner. As a scrum master, you have to play a crucial role between these 2 stakeholders. One is giving commitment at the start of the sprint, but team has a dependency on the PO to provide the requirements and the clarity on the requirements. Scrum master many a times need to help team to understand the requirements also. According to me, one has to go one step forward to help team and do whatever so that team can deliver the working software's quality, volume as per the commitment. 7. Resolves impediments - scrum master need to be there on the floor all the time with the team. Scrum master will resolve all the impediments and team should concentrate on the engineering tasks. Then only team will deliver the working software at the end of the sprint. Some of the example of the impediments are requirement dependency, wireframe dependency, environments down etc. 8. Resolves conflicts - resolving conflicts between the team members. Agile does not have any room for negative conflicts. We have limited time and we have to deliver the committed work. You cannot afford to lose any time otherwise how will you manage the time. So be in touch with the team members so that as a scrum master you can sense the conflicts early and resolve them. Coordination is critical here. I have seen people do not coordinate in one team. So you need to talk to them, if they agree to work as a team then it is fine otherwise put the team members in other team. 9. Lead all the meetings in the project - as a scrum master, you need to lead and guide all the team members in all the meetings proposed by agile like preplanning meeting, planning, daily scrum, review and retrospective meetings. So all in all you need to be on top of everything. 10. Shields the team - So the ultimately you have to make sure that team gives at least 6 hours of engineering productivity. For all the external interference, scrum master should stand in front of the team. 11. Team formation - This is one of the difficult work. Agile team formation is not an easy task. Specially when you are working in big teams. I have learnt that if you are forming the team, never ask the team member that which team does he want to work. He will put himself in a team where you will not require him or every team member will try to work in some particular team. So as a meta scrum master or scrum master, you put your thought and off course some logical thinking and go ahead. Everything will be fine after 2-3 sprints. 12. Estimation - scrum master will coach the team on how to estimate. Further scrum master will also participate in the estimation during the planning meeting. 13. Performance Appraisal & Feedback - scrum master will provide necessary feedback about the team members during the appraisal. Delivery unit head or whoever is the responsible person will take care of the rest. But as scrum master is working with the team on the floor, scrum master will have most of the information on the individual performance here. 14. Improvement - Find out the ways to improve on the quality, velocity, value to the business. Team is working on some product since last 1 or 2 years, scrum master need to show the improvements quarter Scrum-Agile - 5
by quarter. Team will say that they are doing fine. Quality is fine, velocity is fine but scrum master need to find out some different ways for improvements.
This is just a start. I will keep adding more responsibilities here in this list. But I need your help also here. Please suggest what all things are missing in the list.
Scrum-Agile - 6
Agile Sprint ETVX When you are starting any new project, you need to know each and every activities that you are going to perform in the project. First thing before the project kick off is the sprint 0 activities that I have discussed in my previous blog on sprint '0' activities. Let's talk about the activities during the sprint. What I have done is to group the activities based on the phases/milestones like Release planning, pre- planning meeting etc. Let discuss them one by one:
Release Planning Before the sprint planning meeting, release planning is a critical meeting where product owner will show the release backlog to the project team for the first time. This backlog need not be completed. But at a higher level, product owner should be able to explain his vision about the product to the team. User stories will keep adding into the backlog even at the later stage. Below table shows the major activities that should be planned in the release planning meeting.
Phase Input Activities Output 5 to -10 days prior to kick off Prioritized Release Backlog by Product Owner Agile team will understand the release goal. This is the first time when team will have a look at the release backlog. Before start working on the user stories, team need to understand the key objective behind the release. Understand the business requirements at a higher level. Understanding the core purpose for the project and the release. A prioritized set of user stories that will be developed in the release. A coarse estimate for each story. A date for the release Draft Release Backlog
Pre-Planning meeting One of the main purposes of the pre-planning meeting is to identify the dependencies for the upcoming sprint. If team can resolve the dependencies in coming 3-5 days then these user stories will be part of the sprint backlog otherwise these user stories will be dropped for the coming sprints. Team will discuss the user stories to have an understanding and then estimate the user stories. Phase Input Activities Output -5 to -3 days before the sprint start date Product Owner is ready with prioritized user stories (well above the teams base velocity) with acceptance criteria All pre-requisite e.g. data model, UI mock up, Wireframe should be available Sprint Backlog prioritization by product owner User stories walk-through by product owner Technical complexity explanation by application architect Discuss and confirm all pre- requisite e.g. wireframes, localization requirements, HTML dependency, Webops dependency, database dependency etc. Wireframe reviewed with UX team Point sizing of user stories
Draft Sprint Backlog High level point sized user stories Prioritized user stories Inter team dependencies should be agreed upon and time lined Scrum-Agile - 7
Planning Meeting Planning meeting is the key milestone for the upcoming sprint. If team is able to do the planning effectively and efficiently then sprint will be completed smoothly. But we have a dependency on the functionality and technicality details of the requirements. Phase Input Activities Output Day 1 of the sprint Product Owner is ready (well above the teams base velocity) with user stories with acceptance criteria All pre-requisite e.g. data model, UI mock and wireframe should be available
Kick-off meeting Capacity planning by the scrum master User stories query resolution with product owners, modeling team, UI design etc. User story walk-through by Product owners for newly added user stories Vertical slicing of user stories Determine Sprint defect backlog target Point sizing of newly added user stories and defects Refine Point sizing of user stories due to added complexities/unknowns to data model/wireframe Inter team dependencies should be identified and communicated Task planning, estimation and allocation Agree to sprint commitment Sprint Backlog with point sized user stories Teams Capacity Plan Task and related Effort Allocation Team Commitment List of Sprint risks and dependencies All dependent user stories should be moved out of Sprint scope
Sprint Execution/Daily Work Details of the daily work is given here. Close tracking of the tasks that are planned in the planning meeting is very important. Daily scrum meetings will give you a chance to talk about the progress and raise your concerns over the roakblocks, dependencies.
Phase Input Activities Output Sprint Execution/Daily Work
Sprint Day 1 committed user stories/Sprint backlog Scrum Master
Daily Scrum meeting Burn-down tracking Roadblock and dependency resolution Risk identification and mitigation plan
Team
Scrum Master
Daily Status to Meta scrum master Risk & Issues or any roadblock
Daily scrum meeting Ongoing/as needed query resolution / discussion with PO and application architect Collaboration meeting with onshore team (technical discussions) Internal user stories demo before PO Acceptance Preparation of acceptance schedule Product owner acceptance demo
Development Activities
Design discussion & review Heuristic review as soon as UI is done Code development & review JUnit/NUnit tests are written and executed Where ever applicable Deployment to QA environment Defect fixing
Testing Activities
Preparation of acceptance criteria Test case design creation (automation + manual (if needed)) and review Test case execution and automation script review Logging/verify the functional defects into the agile project management tool. Unit test cases (If applicable) Test Design document Automation script or Manual Testing result for all the applicable user stories as per the PO acceptance scenario Acceptance Demo to PO as soon as User Story is complete
Sprint Review So here is the last day of the sprint. Team need to give a final demo to the customer of the functionality/features that are just developed in the sprint.
Scrum-Agile - 9
Phase Input Activities Output Last day of the sprint Completed Sprint Accepted user stories Provide demo to Product Owner and other stakeholders PO to share any feedback. Prioritized defect fixes will happen based on the timeline available in current sprint, if not consider for next sprint /moves to product backlog. Review the accomplishments Track all requirements completeness Traceability matrix Demo output Updated Requirements Traceability matrix
Sprint Retrospective How to improve on quality, productivity is something discussed in this meeting.
Phase Input Activities Output Last day of the sprint OR 1 st week of the next sprint Completed / to be completed Sprint Conduct retrospective meeting with team with focus on What went well, What did not go well & Action plan for improvements Prepare action plan for improvement areas Identify any spike and learning opportunity Knowledge sharing across scrum teams Retro Notes Improvemen t Plan
These are the high level thoughts that I have put together here. If you need any more details on any of the activity then please left me a comments below and I will talk to you for the same.
Scrum-Agile - 10
Agile Fix Price Projects Agile in a fix bid? Is that possible?
This is happening in almost all the service delivery organizations nowadays. I am not sure how and why companies commit and propose the fix price model in Agile projects. When you do not have requirements clarity upfront, how and on what basis companies commit the fix price that is something beyond my imagination. I have been asked by many delivery managers to help the projects which are in deep RED during the execution.
First of all, let me write my own feelings on this topic. I personally do not agree to provide a solution in the Fix price/fix bid agile. It is not in alignment of the agile manifesto. At one side, we are saying that agile team should be self-organized, transparent, honest and on the other side, we are compelling team to finish task within the set timeframe and cost. Team need to be happy while working on the project, only then they will be able to deliver the project with very good quality and creativity.
Here are my thoughts if at all you don't have any option other than the fix bid then following points should be taken care of while executing the project:
1.
Scope of work or Requirements: We all know that if requirements are not ready up front then Agile is the best methodology for the software development. Requirements will evolve with the product development. So we should always try to convince customer to go for:
Option 1: Time & Material type of the contract. Option 2: If customer is not willing to sign the T&M contract then second option should be the T&M with cap Option 3: If customer does not agree to any of the above 2 options then that means we do not have any option other than the fix price.
Under option 3, if detailed and stable requirements are available up front then you can do a kind of Function point estimation and can give a fix price quote. You will be able to manage the show in that scenario. But what if there are no requirement available at all. What should we do in that case? Keep on negotiating. There might be some middle way by which you can save your self and deliver the required product.
At this stage what I am thinking is to propose a one time 2-3 months of requirement phase, where vendor and customer together dig into the requirement and create the detailed requirements. Once you get the requirements, from there on you can adopt agile. There are still so many benefits agile will bring into the development and testing. Customer will still be able to propose changes or reprioritize things along with the development.
Ultimately, while adopting agile whatever requirements team is receiving need to be concrete, detailed, stable and accurate. Scrum master need to make sure that these requirements do not Scrum-Agile - 11
change. If at all they need to be changed, it should be tracked and reported in your sprint summary report to the higher management on the both side i.e. customer and vendor. This will help the scrum master during the crisis situation.
2.
Change control board need to be in place like we have in all the waterfall projects. I have already written on blog on the Agile Change Management. Please have a look at the blog from the following URL: http://amitsinghmalik.blogspot.in/2012/07/agile-change-management.html Requirement changes are welcome but we need to keep a cap on that. A very close change control board need to be in place all the time.
Apart from that here are some more points on the CCB. I got these points while browsing through the Google. I do not remember at the moment where from I got these lines. But below 5 points do not belong to me. Change Control Board 1.
The client can replace any requirement that the team hasnt yet started working on with one or more of equal total size and complexity. 2.
Priority shifts are free of charge if the total estimate for the entire work does not change. 3.
New features can be added to the backlog if low-priority items of equal work are removed from the backlog. 4.
The client may request interim releases at any time and will be charged an agreed-upon time and materials cost. 5.
If the clients business goals are satisfied early, they may terminate the contract early for a specific percentage of the remaining unbilled contracted amount.
3.
Involve customer on your day to day operations during the collaboration hours. Usually, in fix price contract customer try not to be part of the team but try to convince the customer by explaining him the benefits of him to be part of the team. This will help in the long run because customer will speak on your behalf most of the times because he already knows the issues/challenges team is facing on a daily basis. But don't forget that he might not help when you will need him the most. 4.
Risk Management: Very close watch on the project's risk. Scrum masters need to focus on the risk all the time proactively. Provide an open and transparent platform for the team to raise the concern/risk immediately. Give them the authority to float the information to everyone as soon as they sense any risk. This can be done easily in your weekly team meeting. Make sure that you have Risk as an agenda in your weekly meeting. If you will discuss anything in the meeting, I am sure you will get what you wanted to achieve in the meeting specially from the team members. 5.
Critical Path: I like this concept very much from waterfall projects. You have to identify the critical path (may be at high level) and keep a close watch on the critical path. If you are able to complete the critical path on time. Most probably you will be able to complete the project on time. 6.
As I wrote in the introduction that while implementing Agile in Fix Bid, we are going against the agile principles.Sprint Demo is one of the most important tool in agile where customer provide his early feedback. But you know this is where customer suggests lot of requirement changes. Scrum Master Scrum-Agile - 12
need to track it to save his project cost and time to keep a cap on that too. Each and every change in the fix bid need to be analyzed for scope, schedule and cost. If any change has a business value, it should go into the coming sprint backlog despite any impact. Take a help of the change control board here. 7.
Release: If you have already planned the requirements implementation in form of smaller releases then you will have some mid point checks on project progress. If not then please do so as soon as possible. Create the virtual releases in the project, you might not send the code into the production but at least you can send the release for UAT. Planning at release level and sprint level will help project to meet the deadline at release level. This is one of the ways by which chances of the project success will increase. Proactive measures can be then taken after each sprint and releases.
What I would also like to suggest that if we can propose the fix price quote on the release basis. Try to complete the rough estimate for the 1st release. Once you complete the first release, project will have data by which you can actually do some kind of the estimates based on the sprints completed during release one. 8.
Estimation: You can commit something here. That something is available in form of hours. After doing the high level resource loading, you will get to know the number of developers, testers and architects for your project. Now calculate the productive hours per sprint wise. Based on this you can do some mathematics. As a customer, you can commit the available hours to the customer. X amount of hours worth of work will be delivered to the customer. Now it is up to the customer how does he want to manage these hours? A kind of staff augmentation project. 9.
Velocity: This is difficult at this stage. According to me, there is no way that you can calculate the velocity without completing at least 2-3 sprints. Velocity has a dependency on items like team members, technology, domain, complexity etc. So I would not like to comment anything on this.
I believe my thought will help you in some way or other. Please do provide the feedback so that we together make the points complete on this topic. I will also try to put some lesson learnt from some of the team who has already burnt their fingers in similar kind of projects.
Scrum-Agile - 13
Sprint Zero Activities In one of my recent assignments one of the customer, who earlier wanted to implement the project in waterfall, now wanted to execute the project in Agile. Reason to adopt agile was non-availability of the requirements up front. I was asked to check if we could adopt agile in given scenario. I did a quick assessment and found that it was a perfect fit for the agile implementation. During the assessment, I had to create the agile implementation road-map for the customer. While preparing the sprint '0' activities, I thought that sprint '0' was the most critical sprint for any project. If we do not plan it with greatest focus, it will be very difficult to make changes later on. Sprint '0' is the foundation for any project. We all know that foundation for anything should be very strong. So let us focus on the sprint '0' and try to make it a robust one. Sprint Zero is usually kept for the readiness for the sprint 1 and for all the up coming sprints. Management has to make things like requirements, infrastructure, people etc. ready for the up coming sprints. Duration of the sprint zero is something that needs to be decided by the project team and has a dependency on the procurement of all the required items. So what I did, I broke sprint '0' into 2 sprints. Sprint 0_1 was for procurement, architecture, product backlog etc and sprint 0_2 was actually a rehearsal for sprint 1 i.e. POC, where team actually done the coding and testing to check if everything is as per the plan.
Sprint Zero is also called as Iteration Zero. Activities listed below will make the team ready for the sprint 1. It is a kind of the preparation for kick off. Product Backlog/Requirement: These are the product requirements that team will be building in the coming sprints. Product owner and Technical Architect need to work closely here to prepare the backlog for the team. Product owner should be ready for the release plan so that team can visualize the PO's vision from the product perspective. Product Onwer's Vision on the product Product Owner should be ready with the Release Plan Preparation for sprint Planning Requirements freeze at least for sprint 1 and 2 Prioritization for sprint 1 & 2 Decision on Definition of Done Scrum-Agile - 14
Infrastructure readiness: Without the infrastructure, team will not be able to progress on anything. So a high dependency on the systems, software, licenses, environments etc. Delivery Manager need to work with the infra stakeholder to get these things done. Network requirement Connectivity if there are more than 1 location is involved Minimum environments readiness; to start with team at least need dev and QA environments System readiness with all the software installed Logistic requirements like phone, video conference etc All the tools up and running Design/Architecture: High level architecture management plan that talks about the technical architecture of the future product from the technical architect. Next step will be to convert the architect plan into the architecture solution i.e. the coding platform for the developers. High Level Base architecture should be ready Decision on the coding framework and make it ready for the team Decision on the tooling & IDE Coding standards & processes Review Process Automation Testing framework readiness Team Readiness: Creation of the team as per the resourcing plan. You do not need the entire team on day 1 of sprint 0. But you have to make the team ready with the training, tools, systems configured for them for coming sprint. People hiring Team ramp up R&R from each role Each developer and tester will also make their system ready with all the required software POC: Developers and tester should make their self ready for the sprint 1 with some kind of POC where they will actually code and test. This exercise is very important so that they can make the sprint productive. From sprint 1 onwards team is start delivering the working software. Training: Training will make team ready for the development/testing. These trainings are critical to project success. I would also recommend that these trainings should be recorded for the future use. Recorded sessions will be utilized during the ramp up period for the new associates. Domain Technical Architecture Development Framework and Process Testing Framework and Process Tools Project Management Plan: Comprehensive project management plan will be the bible for the project team members as far as project processes are concerned. Agile PMP document is different than the traditional PMP. Here critical items are the test and defect management plan. You should clearly write down the process of testing in the project. What kind of testing?; which environment will used for which testing?; how many types of defects?; how will team fix the defects?; all these questions should be answered by the test strategy. Agile Management Plan 1. ETVX 2. Each and every step for implementation; basically an agile Bible Scrum-Agile - 15
Test Management Plan 1. Test Strategy 2. Test Plans 3. Templates 4. Performance Testing 5. Security Defect Management Plan Continuous Integration Process Risk Register Roles & Responsibility of each role like scrum master, project manager, agile coach, delivery manager, developer, QA, sponsor etc Other Plans Well, I feel this should be good checklist to start with. However, apart from the checklist, I would also recommend to have a daily scrum call right from the day 1 of the sprint '0'. There should be an action items list that should flow on a daily basis with the clear ownership for each of the activities listed above. Having a war room will be a great idea during this time because this is a planning period where lots of things gets clear while having the brainstorming within the war room. Once you start, things will shape up automatically as you will proceed further. All the best!!
Scrum-Agile - 16
Agile Coach Roles & Responsibility
When you are starting a new project in Agile and team does not have agile knowledge. It is one of the scenario, where you need an agile coach for the project. Project sponsor should involve agile coach in the project as early stage as possible. Agile coach will set the ground rules and regulations and will create a winning strategy for the project from the initial phase of the project itself. This is a critical role that needs to be played by a senior experienced person, who has executed projects on floor. Theoretical knowledge will not work here.
I have been playing this role in two of my previous projects. I found coach role very exciting and challenging. Coach, Train, mentor people and make them ready to play the game on the ground is not that easy. There are various challenges while playing this role. I think "Challenges while transitioning into Agile" will be a topic for the next blog. Right now, I am posting the roles and responsibility of the agile coach. Help me to make this list complete. I am just posting the first iteration and will keep on adding the more bullet points under the list.
Agile Coach Role & Responsibility
1. Facilitator: Facilitate the team with the knowledge so that team can start the project. 2. Trainer: Provide training to the team on the agile process; training will continue all the time during the project execution on agile and continuous improvement on velocity, quality, processes etc. 3. Help in preparing the overall planning of the project that means he will work as a consultant. He will provide various ideas, suggestions, strategies. 4. Make sure that team is following agile processes in each sprint at user story level as per the Definition of Done (DoD); However this is the responsibility of the Process Check Master but if project does not have a role of process check master, this activity should be handled by the agile coach. 5. Help team to answer all the questions on the agile process during the project execution; that means agile coach need to be on the ground so that he can answer the questions immediately. 6. Identify project risks and raise them immediately Scrum-Agile - 17
7. Make the winning strategy according to the ground conditions 8. Mentor: Focusing on people and Continuous Improvement all the time; provide team a platform for improvement not only during the retro but all the time. Create a safe environment for healthy conflict and meaningful collaboration. 9. Identify process issues and improve them 10. Help product owner to write user stories 11. Help team on the estimating of the user stories and prepare them for the same 12. Help scrum master to plan meetings like 1. preplanning, 2. planning, 3. daily scrum, 4. Review & Retrospective 13. Provide capacity calculator template for the team 14. Provide the common tasking codes for the team for better tracking on technical front
As I wrote above, this is not a complete list but should be sufficient to start with. Every project has different dynamics and this list can be customized according to the need.
Scrum-Agile - 18
Transition Steps - Version 2.0 In my last blog on transition from waterfall to Agile, I wrote some details to adopt agile. Now I am writing more steps, when you have chosen the project, which will be a kind of pilot project. Following are the steps, that one has to follow in any project while transitioning to Agile. 1. Identify Agile Coach: According to me, this should be the first step. You need to identify an agile coach, who will help you to dive into the agile concepts for initial couple of sprints. He will also help the team to train with Agile concepts. 2. Get Agile Knowledge 1. Training: This is the first step for the team. Team should be well versed with the agile concepts. For that you need provide them at least 8 hours of training. Training should be a instructor led class training. After completing this 8 hours of training, team can go through some recorded sessions and read some agile books. 2. Training should focus on the rehearsal of the daily scrum and estimation methodology. 3. Agile Books: Buy some agile books for the team. As I wrote in another blog. This is very important to gain more knowledge on agile. More knowledge team will have, more easy will be to implement the Agile. 4. Change the mindset: The biggest challenge is to change the people's mindset. But as an agile coach, you have a target to change team's mindset as soon as possible . PM, Tech Lead will try to keep their powers with them. However, we have to set the people free so that they can create more value in the project. Freedom, trust, honesty, matured team members are the pillars in the agile transition. 5. Print Some agile posters and paste around the wall in the war room or on the floor where team is sitting. This will help to create great ambiance for the team. 3. Define Rules & Guidelines: Now, agile coach has to create the rules and guidelines document for the agile execution. This document will help entire team including product owner, scrum master, application architect and team to proceed with agile execution. Document will contain the what, how of the agile. This should be a working document that can be updated regularly by scrum master and agile coach. When I created this document, team was not sure why was I creating that document. But I knew the important of that document. Once finalized, document immediately became a hit within the team and at account level. Because this document had almost all the details for all the stakeholders including acceptance criteria, test management plan, defect management plan etc. This document can also be part of the project management plan. 4. Create Inventory: Following artifacts will be created before we kick off the first sprint. 1. Selection of the agile project management tool like Rally, JIRA etc 2. Selection of the automation testing tool like QTP, RFT, Selenium etc - cannot survive without it. 3. Code development and deployment procedure 4. Identify all the environments that team is going to use 5. Capacity Calculator 6. Common task codes 7. Analysis and Design template 8. Definition of Done 9. Product Backlog Creation 10. Prioritized sprint backlog 11. Estimation methodology like Planning Poker Scrum-Agile - 19
5. Creating Product Backlog/Home Work for the sprint 1: Before going to the pre- planning meeting, scrum master, application architect and product owner need to sit together and make the sprint backlog ready for the team. 6. Estimation: As per my experience, initially team members face difficulty to understand the concept of the story points. Most of them do not understand the concepts of story points and its complexity. Team members always feel comfortable estimation in terms of efforts. What I do for initial couple of sprints till the time project has its own standards. I give them some relationship of story points and efforts to complete 1 story points of work. How many hours will be a right fit against 1 story points that you can take a help from team members. You can ask team members that how much time it takes to complete the smallest activity in the project. That should be your 0.25 SP of work. If you can multiply it by 4, you will get around 1 SP relationship in terms of hours. When team is estimating any work, that includes every activity before UAT. That means analysis, design, coding, unit testing, test cases creation, execution, defect fixing, defect verification and all kind of reviews should be included in your estimates. Note: Remember this is just to kick off the sprint 1. After a couple of sprint, team should be able to understand the complexity of the user stories and then they should be able to estimate the stories without worry about the efforts. 7. Preplanning Meeting: Now entire team is there in one room to discuss all the user stories one by one & to estimate each story. The main agenda of the preplanning meeting is to estimate the user stories and to identify the dependencies/preconditions for the stories that team is going to target in the coming sprint. After this meeting, team will have prioritized and estimated sprint backlog. This meeting will be scheduled around -3 to -4 days ahead in case of the 2 weeks sprint and -5 to -6 days in case of 4 weeks of sprints. Question: How much work to pick in the sprint? I would recommend that you under commit the work in the initial couple of sprints. As soon as you complete the committed work, you can ask your product owner to pick another set of user stories. 8. Planning Meeting: Duration of the preplanning and planning meeting should be 2 hours each for a 2 weeks sprint. Main agenda of Planning meeting is to : 1. Re-evaluate the newly added user stories from preplanning meeting 2. Assign user stories to the developers and QA 3. Tasking the user stories and efforts against each task. I would like to give one suggestion here. When you are putting efforts against each task. You should not keep the story points in your mind while doing the tasking. That may affect the efforts. Just keep on filling the efforts on actual basis. That is how you will get the variations for analysis after some sprints. 9. Testing: There are some difference in the waterfall and agile projects testing. Let's talk them one by one: 1. Writing test cases: Testers should write the test scenario rather than detailed test cases. Remember, agile manifesto also says that we need to have minimum documentation. No need to write each and every small common sense test cases. We should write the business test scenarios only. 2. Automation: continuous integration is the core pillar of the agile projects. As soon as a user story is completed. It should be tested with the overall software that is developed so far. You have to test the entire functionality with the newly added Scrum-Agile - 20
piece of code. So you have to automate your testing, otherwise if you will think about the manual testing, you will be killed. Try to automate all kind of testing in the project right from unit testing till the integration testing. 3. Developers and QA collaboration is one of the pillars of the agile success. They need to develop and test the code together. 10. Daily Scrum: This is where team members will face a lot of pressure initially. But as a coach, SM, you need to bring every team member on a comfort level so that they become transparent, honest and proactive in order to raise the concern/issues/risks. 11. Daily collaboration meetings: Team need to have around 2 hours for collaboration on a daily basis. They can use this platform for: 1. Clarification of the requirements from PO 2. Dev and QA will have a detailed discussion of the requirements before starting the work on the story 3. Dev will discuss the analysis and design 4. QA will get the test scenario reviewed by PO 5. Review demo of the work 12. Sprint Review: At the end of the sprint, team will give demo to the work that they have just developed. Senior management, sponsors, end users will also attend these demo and see how their product is growing sprint by sprint. One of the advantage of the agile is to have minimum surprises. If stakeholders feels that this is not what they wanted, they can immediately provide their feedback and things can be corrected in the next sprint
Scrum-Agile - 21
Sprint Process Flow I wanted to create a simpler sprint process flow diagram for my training purpose. We all are seeing the mountain goat picture since a long time. And may be the most widely used picture across the globe. I, myself is using that picture to explain the sprint. Below is the picture that I have created which not only talks about the various activities that we use in the project but also includes the owner of those activities and output artifacts from each stage.
Scrum-Agile - 22
Scrum-Agile - 23
Below picture represents another view of the above process flow. The first box represents the major activities in the agile projects. In front of each box, there are activities within those activities, who all should present in the meeting and what is the outcome of that exercise?
Scrum-Agile - 24
I hope this representation will help the people who are new in agile world. I tried to make things simple here. Please let me know if I am able to succeed in my thoughts
Scrum-Agile - 25
Agile Testing
Testing approach in Agile projects and in traditional waterfall projects is different. We were struggling in one of our Agile project once upon a time. That time, we did not know, what all things should we do in testing while executing the project using scrum? We continued learning things on our own and kept our focus on the Quality of the deliverable all the time. Over the period of time, we got good hold on the testing practices in Agile project. But there still some questions those are debatable and should be customized based on the project nature.
Some of the questions I had were: 1. Developer Vs QA ratio 2. How much to automate? 3. Should we log the internal (exploratory) defects? 4. What should be the frequency of the regression and sanity suite run?
The different types of testing that will be carried out during the project, and each plays a critical role in the projects ultimate success. The testing strategy includes:
Unit Testing This is the first level of testing that is done in any software development project. Developer complete with his coding and then does the unit testing in his local/development environment. Purpose of unit Scrum-Agile - 26
testing is to make sure that individual components are working as per the requirements. Remember we are not targeting the integration testing here.
As Agile has a limited time, we have to automate everything coming in our ways to save time in future. That is the reason, automated unit testing is recommended. JUnit for Java should be created for all the test cases wherever possible. Another important thing is the testing coverage, As per the definition of done there should be a target coverage % of unit testing test cases. This unit testing coverage should also present in the Definition of Done.
There are some tools available in the market like EMMA, which measure the % coverage.
Functional Testing Now is the time to test all the individual components together. This is where a tester/QA will fold his/her sleeves and will be there on the floor to test the developers code in QA environment. The main purpose of the functional testing is check if one use case is working properly as per the requirement.
There is a need to test chains of transactions that flow together and which reflects important business processes and scenarios. Scenario testing will be performed for each module separately as and when the development or customization is over for that module. During subsequent integration testing these small scenarios can be used to build larger end-to-end scenarios.
There could be 2 types of functional testing i.e. Manual and Automation testing. As the name suggest, manual testing is something when a tester jumps on the keyboard and test the functionality manually if everything is working fine. Automation testing is done with the help of the tools like QTP, RFT etc. Here tester does the coding to test the scenarios with the help of the tool. Primarily, this code becomes part of the regression suite. Regression suite is run in the coming sprints to check that the existing functionality is not broken by the modification of the current sprint coding.
Regression Testing As soon as sprints are complete, automated and manual test cases are added into the regression test suite. Sometimes, bigger projects keep 2 automation suite i.e. regression and sanity test suite. Sanity suite is around 10% of the regression suite. Usually, sanity suite is run on a daily basis and regression suite is run twice in a sprint. A high focus should be given on the regression and sanity defects. As soon Scrum-Agile - 27
as, any defect is detected, it should be assigned to the particular scrum team. Defect status should be floated as a weekly status report. Apart from that, sanity and regression suite run status should also be floated as soon as suite execution is complete with the pass/fail status.
When project is large, a separate QA team is formed to maintain the regression/sanity suite. In my last project, we had a separate testing team apart from the development teams, who had dev + QA. My development team was using scrum and QA team was using Kanban. Main responsibility of the QA team was to: maintain and run the regression and sanity suite. to add more and more acceptance scenario to the regression suite to complete the pre-conditions for the development QA teams based on the pre-planning meeting to follow up on the open regression defects so that they can be closed asap and to fill the development team's QA capacity shortfall if needed due to some emergency.
I do not think that you need this team from day one. We created this team when we sensed that we were not able to manage the regression suite and needed somebody full time to manage the team. After the creation of this team, our defect management and running of regression suite became smooth. We got several benefits out of this team.
Regression Testing will be done before making any release to a controlled environment to ensure: That the application works as specified even after the changes/additions/modification were made to it The original functionality continues to work as specified even after changes/additions/modification to the software application The changes/additions/modification to the software application have not introduced any new bugs
System Integration Testing System Integration Testing (S.I.T.) is the testing of the sub-systems, as a whole, to ensure that they work as a system. Final integration testing is accomplished through the execution of predefined business flows, or scenarios, that emulate how the system will run. Integration Testing involves cross-functional integration points and end-to-end business scenarios. This also includes testing of all peripheral devices (like scanner, digicam etc) that are integrated with the system.
System testing consists of technical tests and performance related tests. The technical tests aim to validate that the technical components of the production environment are working properly. These tests include validating the system for: Response time Fail-over Test Availability Test Disaster Recovery Test Backup and Restore Test System Administration Test Security Test Performance/ Load Test
User Acceptance Testing User Acceptance Testing is the final step before rolling out the application. This will be conducted by the selected end users, who will be using the applications test the application before accepting the application.
Usually, business users who provide the requirements to the development team does the UAT. They have a separate environment to check if everything is working fine.
Scrum-Agile - 29
Tools used throughout the SDLC
I thought to prepare this list of tools, used throughout the SDLC many a times, but could not make it earlier. Now when I was struggling myself in one of the assignment, where I had to suggest some of the development tools. I thought, this is the time. I started writing it down. I also thought that if I write all the tools then I will end up with a really long list. So here is the list of tools that are most widely used. One more point, this list can never be frozen. It should be a working list which might need an update every quarter or so. So whoever is reading this list. Please suggest me to improve the list. And I will keep on updating it for the larger group. So here is the list that you can refer to:
Requirement Tools: with the help of these tools, requirements of the system will be IBM Requisite Pro - I believe this is the most widely used tool. Contour - J2EE-based requirements management tool by Jama Software. Cradle - Systems engineering and requirements management tool by 3SL. Dimensions RM - Requirements Management Tool by Serena Software. Concerto - Concerto is a software project and requirements management platform by Parasoft. Analyst Pro - Software Requirements Tool by Goda Software Design Tools IBM Rational Rose MS Visio MS Office Agro UML Magic Draw Scrum-Agile - 30
Rational Software Architect (IBM) Project Management tools MS Project MS Office Customized Project Management tracking tools - for metrics Configuration Management Tools IBM ClearCase VSS SVN Java development tools (IDE) IBM's VisualAge for Java development Borland's Jbuilder for Java development Eclipse is from IBM Nebeans is from Sun/oracle Spring source tool (STS) IntelliJ from Idea Rational Software Architect (IBM) Code Review Tools Code Collaborator Cast Eclipse Sonar Microsoft development tools (IDE) Visual Studio Application Servers Jboss Glassfish (Open Source) Apache Geronimo Applications Server IBM - WebSphere Application Server BEA WebLogic Server Web server Apache Web Server (65% applications are hosted on apache) Internet Information Server (IIS) - 15% applications are hosted on IIS. Nginx from Nginx hosts around 12% of applications. GWS from Google (5%) Zeus Web Server iPlanet Web Server Roxen Web Server Jigsaw JRun Sambar Server Sun Java System Web Server Portal Server Websphere portal server Oracle WebCenter Adobe LifeCycle Middleware tools Mule ESB Scrum-Agile - 31
IBM Tivoli SOA Based tools SalesForce Amazon Web Services (AWS) Windows Azure Google BPM Modeling tools JBPM Activity WPS Websphere process server Build Tools Apache Maven is the build engine Rake Ant +Ivy Gradle Gant Buildr Agile Project Management Tools Rally Jira Redmine Extreme Planner VersionOne TargetProcess AgileTrack Bamboo Testing Tools QTP RFT Test Manager Selenium Concordian JMEter Jprofiler Jprobe Loadrunner Defect Tracking Tools ClearQuest Rally - Online service for agile project management, requirements and test case management, and defect tracking. Consulting for agile project management. Located in Boulder, Colorado, USA Jira BugZilla Continuous Integration Hudson Cruise Control TFS (MS First Sight) Hot deployments Scrum-Agile - 32
Lesson learnt is the key activity in the software development. Continuous improvement is something that every product/project company is focusing nowadays. Agile provides one important pillar i.e. retrospective meeting by which team is able to grow and mature over a period of time. In my last project, we tried many new things in retrospective meetings. Every quarter, we used give a new theme to the team like productivity, quality, efficiency etc. We used to ask to the team members on these parameters for improvement. Over the period of time, we were able to improve on many things in the project. As a manager/ scrum master, you just need ask the questions from the team on the following areas:
Following are the areas that we should touch upon during lesson learnt: 1. Communication: How to improve the communication, collaboration between the distributed teams? a. Onshore offshore communication b. Offshore offshore communication c. Communication between QA Vs Dev is very important
2. Planning a. Any learning/issues/challenges from overall planning perspective? b. Are we taking adequate time for the planning meeting? Scrum-Agile - 34
c. Are we scheduling pre-planning meeting? d. Are we able to close the planning meeting on day 1 or do we have open items for the next day also where we should start the development? e. Are the entire pre-requisite ready for the stories that will be worked out by the team during this sprint?
3. Requirements a. Were all the requirements and pre-conditions available at the time of planning meeting? b. Did we take care of the NFR (response time, performance, peak load etc) beforehand? c. Were the entire wireframes ready before the planning meeting? d. Changes in the requirements and their reasons e. Requirement understanding f. Query Tracking g. BA Availability h. Definition of Done Clarity/Acceptance Criteria i. Availability of the Traceability matrix
4. Design a. How many changes did we receive in the project architecture during the execution? b. Architecture Understanding c. Impact analysis of the design change
5. Quality a. Testing overall? JUnit + Automation? b. How was the outcome of the UAT and performance testing? Did we plan both of them well ahead of time before system goes live? c. How was the change management during UAT + SIT? d. How was the defect management process? Scrum-Agile - 35
e. Was there an adequate time given to the SIT and functional testing? f. Were the sufficient people available in the team? g. Was the delivered quality up to the mark from team perspective?
6. Team Management a. Team motivation what did we do to motivate people? b. Knowledge dependency on a single person?
7. Risk Management a. How were we doing the risk management? Any learning? Did we miss any risk that we could not identify and occurred during the execution?
8. Customer Involvement a. Was PO available whenever team needed him/her? b. Query response time c. Was the completed work accepted on time d. Availability for the demo
9. Infrastructure a. Were there sufficient and adequate machines available? b. Did we have the entire environment available for the team?
10. Operational Learning + Improvement areas
11. Tools and Training a. Skill level of the people in terms of domain, technical and Agile? b. How did we plan training in the team? c. How did project take care of the ramp up/down plan? Scrum-Agile - 36
d. Did we have adequate tools in the project? If we are given an option what all tools will you suggest in the project?
12. Process a. Methodology comfort level. Did we plan any agile training for the entire team? b. Internal processes (CMMi + others) c. Review Process
Scrum-Agile - 37
Product Development Vs Project Development
I have been working in a service IT company for more than 10 years. All these times I was working on some kind of projects. In my last assignment, I got an opportunity to work on a product development. This is a different mind-set all together. In 2010, I faced one interview with adobe. There were around 3- 4 rounds and I was able to crack all of them. But in last interview, interviewer asked me on question related to the quality of the product. As per my knowledge and experience of service industry, I tried my level best but unfortunately. I could not clear that interview. But today, after working for 2 years in a product based company. If I look back and remember that question. I did not answer that question in the way a product company was expecting it to be. Answer was correct as per the project based company.
Now when, I have worked in both kinds of companies. I thought to write down my thinking about the product development and project management. Ultimately in both the cases, we are developing software. Primarily the difference lies in the peoples mind-set. Otherwise most of the things are common.
Product Development Product is developed for generating revenue and profit for some general functionality to serve to a larger audience. But initially this is an investment. End users come into the picture once there is a sale of the product into the market. Product development keeps the SME (specialist) from almost all the fields. Highly paid people will be working on the product. Domain is given high priority. People are supposed to have a good amount of domain understanding. Product Manager/Owner is the key person. He has to keep an eye on the competitors product functionality, UI, revenue, deals etc. If there is no end user for the product during the development. Product owner has to collect some information/feedback from early adopter or end user in some forum. One of the examples is to arrange a summit in the market and call all the possible end customers and give them a high level demo of the critical features and functionality. Take their feedback for the product improvement. Quality is the most important thing. There will be large testing team allocated to the product development. Most of the time, automated testing should also be in place. Quality, look and feel, user experience should be superior to the competitors product. Delivery Excellence continuous improvement on the quality, productivity etc. Product owner collaboration is required all the time. However, in project development they just give the requirements. High collaboration is not required in project development. Scrum-Agile - 38
More freedom in the team member in the product development. There are no rules in the product development. You just have to develop a much better product with highly motivated team. However, in project development team has to stick to the required quality standards and team is supposed to whatever is written in the plan. People are given more priority because this is long term assignment. People stay in the project for longer duration than projects. Projects are created by developing a product. So they have a finite life. How can team give more value to the end customers is the focus all the time. This product will serve at more than one customer. However, project is usually for just one customer. Most of the product development happens in house. Product development usually are not outsourced.
Project Development In project development, project manager has to finish the project based on the given requirements. However, in product development, product manager has to complete the requirements better than the competitor products. Time is also very important in the product development. Sooner you reach the market better will be the revenue and margin. It is all about competition. Project manager wants to finish the project as soon as possible and would like to start the new one. However, product development usually goes for a longer duration. People do not have that much importance, especially from the service oriented company; they deploy the people whoever is available on the bench. Skills do not matter that much. People are not specialist but they are generalist. Project development is outsourced most of the times. Project is developed particularly for one customer only. Project development exist usually because of the some problem that customer is facing at the moment and it is usually for some in house operations Project managers are responsible for successful delivery of the project with limited resources like scope, schedule and money. They just have to complete the project by all permutation and combination. Scope for the project is limited. However, scope for the product development is modified on the real time basis according the market conditions. So the market conditions, competitors are the most important factors in the product development.
Scrum-Agile - 39
7 Steps to meet the milestone in Agile Project!!
No matter what development methodology you implement in the project, you will find yourself multiple times in situations where you will be missing deadline/milestone. As a project manager you should be on your toes all the times. This article is primarily written by keeping agile in the mind. However, these are the best practices, which can also be applied in waterfall projects also.
I have also been into that situation in one of my previous projects. We missed one important milestone. Why did we miss that? It was a different story all together, team was not even aware of the milestone from the product owner side. Certain features of a product had to be completed by certain time. Team was not able to complete it because they did not know what to complete by what time. I was leading this product development. I decided that time that I should write something on this for my blog. Before jumping directly to the solution, let us try to find out some of the reasons for not meeting the milestones: Absence of the vision from product owner Frequent requirement changes Technical and domain complexity Quality of the deliverable is not up to the required standard Dependency Sudden absence of the key people in the sprint
Achieving the milestone and a certain amount of the functionality volume is the most important thing for a project/product development from the business point of view. I thought that the following review models will ensure that project team will be able to achieve the target milestones:
This is a top down approach. I am starting with the top and then going down level one by one.
1. Product Level Review It was a missing part in my case. Had the product owner communicated the milestone map to the team, team would have been able to achieve the goal. Product owners clearly communicate the project and milestone goals to the entire team. Product owner takes the team agreement on the milestone. Define success criteria for the Scrum-Agile - 40
sprint/milestone/project with the help of the Definition of Done (DoD). Identify all the pre-requisite of the sprint backlog during the planning/pre-planning meeting. This will also increase the chances of the sprint success as well as the milestone success.
2. Milestone Level Review Product owner and team along with the senior management should have regular milestone status meetings after every milestone. This status will report the progress against the end date of the milestone on the basis of schedule, cost and quality to avoid the last minutes surprises.
3. Sprint Management Review Project should provide a regular senior management review status to the management after every sprint. This sprint review meeting will contain the outcome of the sprint that will include the velocity (committed, completed and accepted user stories), Risks, Challenges and Issues faced in the current sprint, quality status, defect management, agreed metrics, retrospective notes (top 3 from each team) from the sprint etc.
4. Quality Management Review There should be a monthly independent quality review based on the CMMi quality standards and guidelines. Outcome of the review will be shared with all the stakeholders to ensure that everybody is on the same page.
5. Regular measurement of the project health Meta scrum master and scrum master should closely control & monitor the project. SM should measure of the project health regularly from the initiation sprints onwards. Following metrics could be considered during the development for measuring the progress after every sprint. a. Burn Down Chart on a daily basis b. Change log c. Weekly deployment plan from dev & QA d. Risk and issues e. Velocity (committed, completed and accepted) f. Quality Status (defect density, defect leakage (functional + regression) etc) g. Leave details Scrum-Agile - 41
h. Utilization etc 6. Weekly Deployment Report Scrum Master will share a weekly deployment goal status report to meta scrum master with the weekly deployment targets. Weekly targets are very important in order meet the sprint goals. Appropriate preventive and corrective action items can be taken by the scrum master if needed based on the weekly target to meet the milestone. 7. Daily Sprint Review Product owner, Scrum Master and the team will discuss the progress on a daily basis in the daily scrum meetings. This activity itself is a major contributor in the milestone and project success. Various meetings, like daily scrum, sprint demo, sprint retrospective, sprint review meeting and milestone review meeting, will be scheduled for better tracking.
Better Execution from scrum master perspective:
You have to focus on the critical path all the time You need to plan at the beginning of the sprint including schedule. One of the way is to have a weekly deployment plan. Entire project team should attend the release planning meeting
These are just the highlighters what you can plan in the project. However, there will be customized solution depending on the problem in the project sprint by sprint. So you will have to keep investing time to find better ways of project management by discussing new innovative ideas with the team. Sometimes, there will be such incidents in the project where in you might have to work extra to meet the milestone. But that is something which I personally do not like. But sometimes you do not have an option. These are some of them which I have practiced. Please let me know more ways by which we can make this content better
Scrum-Agile - 42
How to transition from waterfall to Agile?
This is a big dream. Right! This is not an engineering project, where we can train people and start producing the software from the first day itself. This is a philosophy. This is an art. This is a change of mind set of the people who will be adopting agile. Before changing the companys vision, we need to think about the people working in the company. Their buy-in is more important than anything else. If we follow certain steps and have patience, I am sure everyone around you will have a smile on their face. Lets talk about some of the steps that a company can follow while transitioning into an agile organization.
1. Vision/Roadmap Vision, mission and objective from the management is the first thing. Why does management want to go for agile? What are the short term and long term benefits/goal they have in their mind? We all know about the agile benefits. But let me write them once again at a higher level; higher productivity, better quality software, early feedback about the product/project, working software after every release/sprint, transparency between development team and end users etc.
2. Make a Transition Plan Make a transitioning Plan after having a proper brainstorming. Now this plan will talk about the how part of the transition. Management need to identify the transition approach. My suggestion is to follow the progressive and elaboration approach. Lets become agile in an agile way. Let move towards agile organization by continuous learning through retrospective from each iteration.
3. Training Entire organization has to attend the agile training. I would suggest starting the training from the top. As per my understanding, this initiative will be a successful one if the top management understands the agile. Middle managers should go for agile certification. Developers and testers can attend at least 8 hours of agile training to start with. Remember this is just to start.
Otherwise, agile is not that easy to learn in 8 or 16 hours. Every person will need to read a lot before practicing at the floor. Give them their own time to learn the agile. They will take time to wear the new skin of the agile development. Remember people will always resist any new change. People are happy with their comfort zone. So let them take some time to realize that they will not have any choice but to uncover the new ways of the development.
4. Revisit Existing Roles and their responsibility Scrum-Agile - 43
You also need to work on the modification of the job description of the different roles we are planning to transition. Project Manager will no more work as a project manager; he might be working as a scrum master. Lead will work as a Sr. developer and will work in a kind of flat hierarchy.
5. Buy Agile Books When Hubert Smits joined my project as a program director, he immediately asked us to buy agile book and ask us to circulate in the team. This is important because you are creating that environment to foster agile in your organization.
6. Paste Agile Poster All Around Another thing what Hubert did is to paste the big agile poster all around the floor. People can see them, read them even while walking. People behavior changes accordingly.
7. Agile PMP/COE Make a group of expert people who will provide the rules and regulations, policies, guidelines for the project. You can call this group anything. Traditional companies call them Agile PMO or Agile COE etc. Remember these people need to be expert. If any company does not have these people then hire them. These people will be pillars in this initiative.
8. Identify Pilot Projects Identify projects those will be treated as pilot projects.
9. Decide Sprint Cycle Start with the 4 weeks sprint cycle. As per my experience, developers and testers prefer the longer duration. They would prefer 4 weeks sprint, which is also quite good.
10. Initially, people will hesitate to give their daily status in the scrum call. So you need to make them understand the importance of the daily scrum. According to me, this is one of the most challenging parts. But we need to trust them.
11. PMO need to identify the basic path of execution the pilot projects. Some of the basic questions can be: Scrum-Agile - 44
a. What will be team size? b. What could be the sprint cycle? c. Working hours to maximize the collaboration hours? d. Basic project monitoring techniques like metrics, reporting cycle, SMR etc e. Various templates and guidelines for the project use. f. What kind of companys baseline for various CMMis parameter are they going to use? 12. These pilot projects will construct a road for other projects to drive smoothly towards agile roadmap.
Scrum-Agile - 45
Agile Change Management
What is a change? Any activity (new story, defects, scope change in the existing story etc) that is impacting teams goal or commitment should be treated as a change for the team. In agile, once team enters into the sprint after that whatever changes coming into the sprint backlog should be treated as a new requirement.
Agile Change Management Agile development welcome changes as far as they add value to the development. Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project.
Product owner is the responsible for ROI and is the owner of the backlog. It is POs responsibility to assign work to the team. Team has the visibility of just one milestone. So it is absolutely fine if PO changes the requirement priority before the sprint starts. But discourage the requirement changes during the sprint.
One of the 12 agile principles says Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. But Scrum suggests that we should freeze the requirements after the planning session as soon as team gives its commitment for the current sprint. After that any change coming should be treated as a new requirement and should follow the change management process.
In Agile, requirements are discovered and evolved during the development. Change control comprises the procedures used to ensure that changes are introduced in a controlled and coordinated manner. Every change has a cost attached to it. Should we accept all the changes coming from product owner? I dont think so. So when cost is attached then as per the triple constraint other parameter schedule and scope has also some impact. So this is quite important that we give it the adequate attention all the time.
Agile Change Control Board (CCB)
We all know that change management (of the product backlog) is inbuilt into the agile framework and does not warrant any special process. Till now, as per agile we know that the product owner is the Scrum-Agile - 46
owner of the product backlog and he is sole responsible of the backlog priority. Then why am I talking about a change control board in Agile?
Well, based on my experience and understanding, I would never give all decision authority to a single person. No one in this world would always take right decisions. Even a single decision can kill the dreams of many people, who had a vision of some product or service. Then why not to form a change control board, a set of people, who will take the decisions together whenever product owner wants a major change in the product backlog. They will meet regularly to discuss the changes. I would suggest to include Product Owner, Scrum Master, Meta Scrum Master (if exist), Team Lead to be part of the CCB. On top of that, product/project sponsor should also attend the meeting whenever he gets a chance.
Now when I am talking about a major change, we can draw a line between major and minor change based on the efforts, cost, prority and business value of the change. Minor changes can be implemented without CCB meeting and SM and lead can take a decision on that. But change process listed below has to be followed in all the cases.
Change control comprises the procedures used to ensure that changes are introduced in a controlled and coordinated manner. Every change has a cost attached to it. Should we accept all the changes coming from product owner? So when cost is attached to it then as per the triple constraint other parameter schedule and scope has also some impact.
Normal Conditions All Scrum teams work on a product backlog which is owned by the Product Owner. The user stories are prioritized in the decreasing order of priority. So at any point of time the scrum team is always working on the highest priority item. The priority of an item is based on multiple factors including ROI, Business priority, technical dependency, risks associated with the story etc. Change Triggering Points If there is a new story, of high priority, added during the execution of a sprint, change control board members will sit together and work on the updated product backlog to decide the user stories which are planned for the next sprint. Similarly if during sprint review, the Product Owner feels that a story needs to be re-worked or changed due to inputs from stakeholders or market conditions, that particular story needs to be given a higher priority and the team picks up that story as a part of the next sprint depending on the available team capacity. Steps taken in the change implementation o Product owner raises a request to add/modify a requirement/story in the sprint backlog Scrum-Agile - 47
o Impact Analysis of the change by the team o Estimation by the team o Decision by the CCB to accept or reject the request o Look at the available capacity and resource utilization o If there is no capacity available then some other user story should be dropped from the product backlog; best practice is to remove the user story that is not yet started by any of the team member. I would also suggest maintaining a change log at scrum master level per sprint. This change log should also be reported in the sprint status meeting after the sprint. And off course this is an item in the retrospective meeting.
Scrum-Agile - 48
Challenges in Distributed Agile
Distributed agile is a need of the market at the moment. But it is not that easy to implement. Distributed agile brings certain challenges along with it. But if we execute project in distributed fashion, we have more reasons to smile. Before we talk about these challenge, let's have a look at the following benefits of the distributed agile: Reduced cost at off-shore or near-shore Quick time to market because of the time zone difference between offshore and onshore Better productivity with off-course better quality Improved operational efficiency because of the competitor pressure
Co-location and coordination are the most important aspect of the agile. We need to be in touch with the basics and should try to implement the agile with the help of the principles written in the Agile books. I have worked with Hubert Smits, who is one of the agile guru, in my previous project. Hubert helped me to learn agile and gave me the term "Agile by Book". And since then I am implementing agile as per the books. Well coming back to the distributed agile.
Thanks to the available tools and technologies because of which Agile no longer requires a co-location in the physical form. With the help of the available latest technologies and tools, we can create a virtual co- location rooms that will work absolutely fine. Having said that I am not saying that I am moving away from the Agile manifesto written in 2001 on co-location. Communication and collaboration can be achieved with the help of latest technology and tools. It does not matter where they are physically located? And today in 2012, we have many success stories in almost every company in the distributed Agile environment.
Challenges in distributed agile model: 1. Working in a Shift: One of the core principles of Agile is the collaboration. This is one of the most challenging tasks, which we face while executing the distributed agile environment. Some of the team members like product owners, scrum master and application architect would be sitting at onsite and team members (Dev and QA) will be sitting at another location. One of the options are offshore/near-shore team work in shift that gives maximum overlap time to interact with onsite team.
Solution: Try to find out a collaboration hours that have at least 2-3 hours of overlap. This overlap time will be utilized by the team to interact with each other and to resolve the dependency they have between each other. Team can utilize this overlap time for daily scrum, question-answer session, planning meeting, review meeting, retrospective meeting etc. Scrum-Agile - 49
2. Communication gap/breakage within the different team: Roles like Product Owner, Scrum Master and Application Architect along with some core team like architecture team, data model team might be sitting at onsite. Communication between these team members are critical success faction for the product/application, you are developing. Better is the communication better will the product quality? Communication between development teams and these onsite teams will also be a challenge during execution because there will be a delay in the communication response during the day time at offshore.
Solution: As far as Product owner is concern, we can have a proxy product owner at offshore to help offshore development during the day time for any query related to the domain or product functionality.
Well we do not have any direct mitigation or solution of this challenge. Only thing is that we can raise the Risk in the begin of the sprint so that team have some backup plan if offshore team need something during their day time then team can continue with their backup plan.
3. Missing of Critical roles like Scrum Master and Product owner at either of the place. Solution: I propose to have both of these roles at offshore. How? Keep a full time scrum master dedicated to the team at offshore. Keeping product owner at offshore might not be a good idea. As I have written in point number 2 above, we have a solution of this challenge and that is to keep a Proxy Product Owner at offshore.
4. Lack of the agile knowledge. It is highly critical for team to have understanding of the Agile concepts. Team can be trained on agile but team takes its own time to learn the Agile concepts. As per my experience, team usually takes around 6 months to get into the Agile philosophy.
Solution: Start from at least 8 hours of Agile training for the entire team to start with. Then I would also recommend some certified scrum masters in the team. What I had also done in my previous project is to post the big Agile banners all around the floor where team was sitting. I had got some very positive feedback from pasting the banners.
5. Process compliance as per the CMMi guidelines. This is one of the most challenging parts from the offshore project manager. He will always keep on struggling with the quality group on the process implementation.
Scrum-Agile - 50
Solution: This is the most difficult part if you are working in a traditional company where Agile processes are not pre-defined. I had a struggled the most on this part but at the end of the around one year, I had some maturity in the CMMi process implementation.
6. Attrition: we should be ready to face higher attrition in the agile team. Some of you might not agree to this but this is a fact.
Best practices in distributed Agile: Work in the One team concept. Despite the team location, scrum team should be treated as One Team. It will solve so many problems in the long run. Having Proxy Product owner at offshore/near-shore is quite useful for the team members to get their query answered immediately during the day time Scrum master at offshore/near-shore: Scrum master is the shield of the team so he/she should stay with the team at offshore if team is at offshore. Teams need a leader whenever there is some breakdown or issue arises. If SM is there with the team, we will have a better productivity from the highly motivated team. Trust me! Apart from having scrum master per team. I would also suggest allocating a dedicated project manager or Meta scrum master at offshore who can handle regular project management activities from the higher site. Having Scrum of Scrum (SoS) during the collaboration hours. If you are working in multiple scrum teams to discuss the status, dependency, impediments, issues, risks etc. across locations. Integrated Environment; it doesnt matter where team is sitting. Integrated environment is the essential part of the software development nowadays. Regular travel of some team members from both side to overcome the cultural challenges. Dedicated and fixed collaboration hours between the 2 locations. Every day after the scrum team can have around 1-2 hours of meeting, in which team can discuss their progress, questions, required support from other team etc. Tools and Technologies o Wiki, if anyone is making any change, entire population is intimated by the mail automatically. All the common documents are also uploaded here. o Tools for code review (code collaborator), configuration management (clearcase) etc. are very important for distributed team o Good internet speed for audio or video communication o Agile project management tool like JIRA, Rally, Assembla o Screen sharing tools like Mikogo,WebEx o Instant communication tools like msn, skype etc Co-location is a must! Does not matter if it is with the help of the virtual rooms and the tools mentioned in the above point. Similar hardware & software setups Crisp, clear and continuous Communication. Face to face communication is considered to the best communication method in Agile. So you can use video chat either daily or weekly depending on the project situation. Scrum-Agile - 51
Tech Lead Roles & Responsibility I was doing an engineering gap analysis of one of my projects. During the analysis, I got to know one critical gap i.e. technical lead roles and responsibility (R&R) in the project. Though, R&R was already in place under the project plan but it was not a detailed one and leads were not referring to what was written in the project plan document. I thought to make a list of activities where leads were involved in their day to day work. But what next, I thought to make it a detailed one, something like a reference point for the leads. I started Googling, and found that this is one of the interesting topics to discuss online. I got a new topic for my blog.
So, who are the technical leads? Lead programmer, senior developer who are technically way ahead of their teams. Who can visualize the project architecture better. Ideally, he should be superior, in terms of productivity, quality, maturity etc, than all the team members. I have divided the R&R into 2 sections:
1. Project Responsibility 2. General Responsibility
Project Responsibility: 1. Own the Responsibility of the overall sprint or iteration outcome 2. Use projects best practices and coding standards 3. Prepare and help team to prepare the design; should have a very good understanding of the project architecture 4. Coding and unit testing including JUnits 5. Conduct peer review and provide feedback 6. Remove the technical impediments 7. Update regular associates RAG (Red, Amber, Green) status; discuss the Red cases on the immediate basis with the project manager to help the manager in the attrition management 8. Update sprint tracker with accurate information to identify the risk and issues proactively at the sprint level 9. Conduct project risk identification and mitigation action planning with the PM at the project level 10. Participate in CAR and help in preparing the data 11. Conduct FIR; Process check master to make sure that his team is following all the listed procedures 12. Constantly looking for ways to increase the teams velocity/productivity by eliminates the waste. This should be one of the discussion points in the annual appraisal. 13. People management & Technical management 14. Help PM in the annual and mid-year appraisal process 15. Assist project manager in the project coordination/management 16. Report the status with alarms, explanations and solutions; Promptly escalate issues to the reporting manager Track and resolve issues 17. Target - Zero surprises; proactively react to the surprises with the detailed written explanation 18. Last but not the least, tech lead should be a reference book for your team members Scrum-Agile - 52
General Responsibility: 1. Interface between team and management 2. Write quality code, set an example of quality in front of the team members 3. Gain the teams respect with the quality of your work and by doing what you are preaching 4. Define early on what success means for you, the team and the business Set reasonable expectations in front of the team 5. Should be part of the design team Should have design vision and understanding 6. Be firm but fair 7. Admit your mistakes 8. Build and maintain high team morale 9. Should not be biased towards any individual professionally but personally you can 10. Task assignment should be fair Tasking should be done with the team together Match people and tasks based on their skills and their personal preference Work the estimate with the team 11. Try to become a role model for the team 12. Take necessary measures to avoid centralization of knowledge. There should not be any dependency in the project on anybody. 13. Mentor people; It is your job to raise the education level of your team 14. Quality with on time delivery of agreed deliverable 15. Team can approach lead any time for any functional or technical concern Tech lead requires balancing between technical and leadership talents. 16. Lead should Motivate/encourage the team members Especially when team is under pressure with the tight deadline 17. Lead should share the limelight with the team 18. Dont blame anybody publicly for anything 19. Work as hard or harder than anyone else in the team 20. Focus on the technologies associated with the software or application you are building. Learn those technology thoroughly 21. Flexible enough to work under different work environments settings 22. Fun @ work At the end, always say WE instead of I
Scrum-Agile - 53
How to Improve Projects Deliverables Quality?
Effective project management and quality management is the success parameter of any of the project success. As a project manager, if I have to tell 1 thing that I have to take care all the time is the QUALITY. Quality should be the success parameter of any of the project. It should be given the at-most focus in all the phases of the project. Below are some of the ways to manage, control, and improve the quality of the software development.
Scrum-Agile - 54
Human Factor Project Atmosphere: As a project manager, we are responsible for fostering a positive environment so that every associate foster for the better quality deliverables day by day to the customers. Try to sense the stress of the associates, if you find that associates need a break, give them a break. This is important because this can lead to frustration, low morale and reduced quality output. Try to engage associates in the overall improvement. Seek feedback from them to make the atmosphere better and their commitment towards quality deliverables. Training: Invest in the associates training. This is an investment for the long term. I have identified one training coordinator at project level who directly works with the training department. We have a monthly goal on the training. Engineering Processes Pre-planning and Planning meeting is the base of the functionality that the team is going to deliver in next 4 weeks cycle in case of the scrum based project. Team member should attend the planning with complete details. Adequate timing for the planning is important, 4 weeks sprint usually have a 4 hours of planning meeting. All the pre-conditions, pre-requisite should be identified during the planning meeting and should be clearly circulating to the concern person. Team should try to avoid picking up the user stories those have some dependency on other tasks. Scrum-Agile - 55
Estimation: Proper estimation is the key of the good quality of the deliverables. As per Agile methodology, estimation should be done by the team together by some standard methodology like planning poker. If estimation is correct then team will develop good quality software and they will take the required time as per the planning and estimation. Standard WBS/Tasking: While doing the tasking, each and every team member should use common WBS codesin the project management tool. Common codes will help to bring uniformity at the project level. It will also help to extract a report, which will have the % of efforts that your team is spending against each activity for your future corrective or preventive action. Acceptance Criteria: First and the foremost thing, is to have the Acceptance Criteria or the Definition of Done (DoD) defined clearly. Every team member should have the understanding and visibility of the DoD all the time. This will help team members to see their daily goal as per the deliverables. Their behavior will change accordingly when they will come to see the final goal of the product all the time at their desk. Test Cases/Acceptance Scenarios: Test cases should be reviewed by the product owner because these test cases are the acceptance test scenarios against which PO will accept the user story. These test cases should be detailed enough to cover all the critical scenarios. During the development, if dev or QA comes with the new scenario that is not written in the test cases, it should be immediately bring into the PO notice. Analysis & Design Document: Agile says we should have minimal documentation and we should give more important to the working software rather than having detailed documentation. Analysis and Design is one of the artifacts that should exist for each and every user story. It does not matter in what form do you create the artifact? It might be a simple thought or an approach that you are applying in this particular requirement but it should be documented against the user story. What I am doing in my project is to write simple notes in project management tool for simpler user stories and proper design document in case of a complex user stories. Code Review: Code review should happen at 2 levels. One is the peer code review at developers level and another one is at application architect level. It is mandatory to have a common and standard coding guidelines and checklist for each developer and tester. All the code review defects should be logged and should be reported at sprint level. Testing Unit Testing: JUnit or NUnit are important or rather I should say is the most important thing. Unit testing should be done diligently. As Unit testing is the first level of testing, we should try to identify all the defects at this stage itself. Cost of the quality at level is lowest in the software development life cycle. JUnit should be reviewed by the application architect. Functional Testing: QA role starts from here. QA is not only the tester but also a developer in Agile projects. He/She has to develop the automation script code. All the functional defects should be logged into the defect management tool. There should be review process in place for QA code also. Whatever code QA is developing, that should be reviewed by the QA lead. Scrum-Agile - 56
Integration Testing: This is done by the regression suite all the time. Regression suite should be given the highest priority in the Agile projects. There should be a dedicated team that should work primarily on the regression suite. Adding more automation scenario, refactoring, execution of the regression and sanity suite, logging and tracking of the defects should be the prime responsibility of this team. If there are more defects that are coming by the regression suite than meta scrum master and scrum master should take some action on it. As I said earlier, it should be given highest priority. If you are developing software that is not working software that means the whole objective of the project is lost. Testing Coverage: Quality of the product is also dependent on the testing coverage. Higher management need to have a vision and goal of the testing coverage. Developer and tester should keep this in mind and should always create JUnit or NUnit and tester should try to cover more and more acceptance scenario to have a better and better testing coverage. Unit testing can be measured by a tool like EMMA. Sprint Review Demo: As per the Agile process, team gives demo to the product owner at the end of the sprint. But intermediate demos are quite helpful to build the final product. It will also help to reduce the rework if team will continue showing the in-progress user stories to the product owner. Build Process: Before deploying to the main environment, developer should make sure that the newly created build is working properly. It is going to reduce the idle time in the project.
Quality Management Completing Quality Processes: o Regular project audits from your SQA and external SQA o Regular team meeting to discuss the overall improvement points o Peer Code Review o Code Review o Defect Logging Process o FIR or all the processes related to the Definition of Done o Metrics after every sprint o DAR Process o CAR process Defect Management Logging Internal Defects Scrum-Agile - 57
o Introducing 1 defect sprints per quarter o Keeping some capacity available for defect fixing Logging and tracking the External defects