Can We Use Agile in SDLC Projects?

Sneaky Scrum

17 September 2013



Introduction

I am a project manager executing projects in an SDLC (systems development life cycle) environment. These are application enhancement projects, which are executed in an offshore/onshore model.

My current project and organizational environment does not allow me to shift to Scrum. So the question is: Under this constraint, can some of the learnings from Scrum be used to reduce/eliminate my current project challenges? I am sure that there are many other project managers in the same boat as I am. My current project's challenges are:
  • A very high-level requirements document is provided to the development team, which keeps becoming more and more detailed during the analysis and design phases -- and sometimes till the end of build phase.
  • The development team responsible for analysis/design/build and testing of application is located at an offshore site. The client/business analyst is at an onshore location. Communication flows from the offshore technical lead to the onshore technical lead to the client/business analyst. The whole chain is as weak as the weakest link. This is leading to loss of information and knowledge and a time delay, which is affecting project time lines and quality.
Let us look at Agile practices and principles and see whether they can be used to solve current project challenges, to deliver better quality and add value to the business.

Scrum team

Product owner
Principle: The product owner is a single person who owns the product backlog and is co-located with the development team.
 
Project environment: This role is being performed by a business analyst, who is located at the customer side. If the role is performed by the customer, then access to the product owner is often limited to just one or two team members. Therefore we lose the advantage of frequent face-to-face interactions between the development team and the product owner.
 
Suggested approach: The project environment does not allow co-location of the development team and the product owner.
  • Someone from the team should wear the hat of the product owner. Then any impediments in the communication path between the designated product owner and business must be removed. Communication can happen through regular emails, dedicated phone lines, screen-sharing tools, and virtual meetings.
  • During planning, budget for travel so that the designated product owner can work alongside the business team during the initial phases of the project.
Development team
Principle: The development team has between three and nine team members. Each team member is expected to perform multiple roles, so they must have a high level of maturity, and the team is expected to have the skills and maturity to produce a potentially shippable product.
 
Project environment: The project setup may have a single role assignment (designer, programmer, or tester) for each team member. Generally the product moves through the cycle of design, build, unit testing, integration testing, and system testing (mini Waterfall).
 
Suggested approach:
  • Use the concept of pair programming (two people should work together on each sprint item) in projects. This will ensure that the desired quality of the deliverable is maintained.
  • If possible, the same people should be involved in the design/build/testing of a sprint item, but the final decision about the same should be left to sprint team. This will ensure team ownership of an item and remove the time spent passing on information from designer to developer.
  • Task assignment can be done in consultation with the team, and flexibility can be given to move the assignments during execution.
ScrumMaster
Principle: The ScrumMaster serves the product owner, development team, and organization. He removes impediments and ensures that Agile principles and practices are being followed.

Project environment: He must perform the dual role of project manager and ScrumMaster, which will have conflicting requirements in some scenarios.
 
Suggested approach: He must be skilled as a project manager and be a proficient ScrumMaster. He needs to decide between monitoring and controlling the SDLC and letting the self-organizing development team execute the sprint in its own way.

Scrum events

Sprint
Principle: The sprint is timeboxed from one to four weeks
 
Project environment: The project duration is more than four weeks.
 
Suggested approach: Splitting the project between multiple development teams may not be feasible due to resource constraints. Splitting a project into multiple sprints may be difficult as requirements may not be prioritized. The project can follow an iterative approach and deliver some of the modules early. Feedback can be sought on the same, and any changes, enhancements, etc., can be spun off as a new project.

Sprint planning meeting (what and how)
Principle: The sprint planning meeting occurs at the beginning of the sprint to decide the scope of the sprint from the product backlog, plus how the requirements will be executed.
 
Project environment: The scope of the project is already defined through the requirements document. The project has defined milestone dates for design and the rest of the project phases. The team will have some flexibility to decide the "how" of the sprint.
 
Suggested approach: A requirements walk-through from the product owner is required so that the product owner and development team have the same understanding of the requirements.
  • If the project has a defined milestone for design, then the team can decide the "how" just for the design phase. However, this approach will lead you to mini Waterfall development instead of Agile.
  • If the sprint timebox exceeds one month, the team may not be able to do complete justice to "how" in the defined timebox of four hours. The team has multiple options at this point. The team, along with the ScrumMaster, can choose any of the available options based on consensus. The options are either to increase the timebox for the meeting, or to conduct multiple meetings, or to cut the scope for current sprint. Note that by using some of these options, you are moving away from Agile due to current project constraints, and all decisions should be made while keeping that fact in the picture and deciding what is best for the project.

Daily Scrum
Principle: The daily Scrum is a daily 15-minute stand-up meeting to answer three questions: What did you do yesterday, what do you plan to do today, and are there any impediments to your work?

Project environment: These team meeting are generally longer; they are usually status meetings, and the project manager controls the meeting agenda.
 
Suggested approach: The daily Scrum meeting should be conducted as per Agile principles to maximize its value. The ScrumMaster should ensure the same and focus on removing impediments.

Sprint Review
Principle: The sprint review is for reviewing the work done during the sprint.
 
Project environment: Generally this meeting does not occur.
 
Suggested approach: You can conduct this meeting by including the internally designated product owner and any other relevant stakeholders. This will help identify and resolve issues (if any) before the product is delivered to the client.
 
Sprint retrospective
Principle: The team inspects itself and creates a plan for improvements.
 
Project environment: This meeting is generally called the "lessons learned" meeting.
 
Suggested approach: Overall, the objective is similar between a sprint retrospective and lessons-learned meeting.
 

Scrum artifacts

Product backlog
Principle: The product backlog is a prioritized list of product features.
 
Project environment: A requirements document is present, in which the requirements are not prioritized.
 
Suggested approach: Requirements can be grouped and delivered in iterations. This will enable the client to see his product early, and it will reduce the risk involved in the project.

Sprint backlog
Principle: The sprint backlog is the set of selected items from the product backlog for the current sprint.

Project environment: There is no sprint backlog. The requirements document is used to produce design and other project life cycle artifacts.
 
Suggested approach: The sprint backlog can be created from the requirements document and used by the team per Agile principles.

Conclusion

The current project or organizational environment may not allow you to use Agile methods in their entirety. It may still be possible, however, to use some Agile principles and practices to solve your current project challenges.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Glen Wang, CSM, 9/18/2013 3:32:48 AM
This sounds like a bottom up approach of agile transformation.

You must Login or Signup to comment.