There’s no second guess that Agile methodology and its varied frameworks like Scrum, Kanban have managed to generate everything from successful products to vast curiosity within the last couple of decades. And that we have enough case studies of Agile implementation in each products based mostly also as service-based organisations.
With this post although, i’m focusing on the current project management challenges a lot of from a service-based organization perspective.
So, a follow-up question may be if Agile is that the answer to most of those challenges, why the challenges are still there? The solution to it is:
- When torn between business pressure of using Agile and beating the age-old conditioning of using waterfall execution, several projects fall prey to the worst mid-way, that’s – mini body of water execution.
- Also, the actual fact that we’ve got a lot of people ‘interested in’ Agile than ‘knowing’ what Agile is. rarely there’s apprehension in starting the project in Agile as a result of ‘Agile’ sells. Although, having those that extremely understand or use Agile in scholastic way, is wherever the struggle lies.
The challenges highlighted below are the result of each waterfall execution also as semi Agile execution. Answer to each is,implementing Agile the proper approach.
Frequent requirement Changes: Even once the scope of the project has been talked at length, estimated and SOW (statement of work) has been signed, there are things that aren’t factored or thought of. Or very often, in the middle of project execution, consumer has new ideas or needs. This ends up in – change Requests, the (in)famous latecomers to the party. they seem when the team is towards the top of the event phase, or in middle (if the team is lucky).
The project manager although has created a project arrange for the complete length of the execution. Accommodating these modification requests is like having guests over at the top of a exhausting day. They’re ne’er welcome. Even when, these change requests come with request (or extending the analogy, these guests come with gifts).
Moreover, estimating these CRs are a challenge in itself. For example, a particular CR is also estimated for fifteen days FTE, as a result of that’s the time required to implement this transformation by developers.However the cascading impact usually is far quite fifteen days due to the extra efforts to suit in this CR. Thus even though request to the consumer is for fifteen days, the price to the company is a lot of. And therefore the resistance in accepting CRs.
People Dependency: The project arrange charts work versus folks. And changing any of those dimensions, upsets the arrange. while modification requests ruffle the work dimension or sudden absence jeopardize the people dimension. people leave organization, they fall ill, they go on long vacation and a very detailed project arrange should endure multiple changes, particularly in a very big team.
I had seen comes where the effort invested in change project arrange was same because the overall development effort. unlike real Agile teams, people usually aren’t cross-functional. So, one person filling sure the other person isn’t simple. These challenges usually resulted within the resistance to approving leaves. Eventually, the teams burnout.
Vast Documentation: The scope and form of documentation could be a project-specific issue. These are driven by what has been agreed upon with the consumer in SOW. however usually, there’s no obtaining away with a couple of normal documents like function specifications, technical style documents, Unit take a look at plans, release notes, User guides etc.
Moreover, in a very CMML5 service-based organization, there are several process-level documents to be created.There are 2 prime challenges in making these documents –
- Some documents even once created before the event should be retouched post development (Case in purpose, technical design documents and Unit test plans). it’s usually the designer or the architect who creates the technical design document within the design phase. however change the documents post development is mostly done by developers. With people ever-changing, the context changes.
- The team shrinks post development (because a project manager should reduce the team when development phase) and there’s a sudden rush of closing the documents that are in agreement in SOW (Statement of Work). Result- the quality of the documents is being compromised.
Defect Density: This challenge isn’t terribly completely different from the basic problem statement that gave birth to Agile. In waterfall model of execution, there’s no intermediate demo to the consumer, thus all the defects are being accumulated from style and development section, await to be detected throughout user acceptance testing section.
Even in several semi Agile implementation, not continually the top product of a 15 days sprint could be a probably shippable unit. a lot of usually than not, these sprints are mini waterfalls. therefore the stitching of individual sprint outcome, happens no previous in integration testing or system testing phase. The a lot of the delay in identifying a defect, the more the risk.
Why Agile (Scrum) is an answer:
Scrum welcomes modification. “Responding to vary over following a plan” is one in all the Agile manifestos. One scrum team focuses on one sprint at a time, thus there’s continually a scope to fit in the modification requests as an area of the later sprints. However, the choice of when to incorporate the modification, can lie with the product owner. once CRs build an entry in the program, Product owner can decide once and the way to include that within the product backlog as a user story. These user stories can later be an area of the sprints backlog in agreement with the scrum team.
- A scrum team could be a set of self-organized cross-functional people. therefore people aren’t expected to be tied to at least one ability. In absence of an individual with a selected ability, the cross practical team is supplied to move ahead. And this scrum team works as a unit. Absence of one team member may impact the rate of the team however not the standard.
- Scrum as a framework doesn’t specify what and the way several documents to be created except for the artifacts (Product Backlog, Sprint backlog, Product Increment and Definition of Done). Documentations in a very scrum project is derived by the requirement of the program, not by the requirement of the consumer or organization. So, consumer and merchant along come up with a listing of bare essential documents that are required for the program.
- Defect testing isn’t on hold until the top in an Agile scrum world. the top of every sprint could be a probably shippable unit. In Sprint review, the scrum team shows the coded, tested and usable unit of work. JUnit, automated test cases, auto deployment etc are the preferred methodes to fasten the testing and deployment process.