1

Escaping Waterfall(ish) Scrum

Presenter:Nabanita Singh

Many organizations are adopting Agile approach today, but the reality of Agile adoption has changed from the original ideas described in the Agile Manifesto, with mini-waterfall (waterfallish scrum). This waterfallish scrum is not necessarily bad, but several considerations and decisions need to be taken care to realize the benefit of Agile methodology.

3

4

5

We are Agile !!!

Teams embrace the ideas behind Agile but fall short of the vision. Basic principles of agility being followed by most of the teams like- Start each iteration with a planning meeting

- Daily stand-ups

- Some defined roles

- close it with both a demo of the work

- Retrospective on how things went

But there are few common mistakes that we must overcome to make it successful.

6

TeamAlways includes

Developers & Testers

It might includeBA’s, Architect,UX

designers,DBA

Product Owner

Scrum Master

Stakeholders

-Business Analysts often play the role of a product Owner:

The main responsibility of the product owner is to own the product, this can be very difficult for business analysts, whose main responsibility is to communicate a customer’s requirements intent to the design/development team. They do not have authority to drive business and technical decisions and this requires them to wait for the real business owner to make a decision.

7

To get the most out of the Business Analyst and Product Owner relationship their roles and responsibilities should be kept distinct and well-defined. Scrum helps here as it has a clearly defined role for the PO as the owner of the product backlogThe Business Analyst can assist the Product Owner by using their in-depth knowledge of the business in a number of ways:• Gathering requirements by managing relationships

with stakeholders and facilitating those conversations;• Providing guidance on what to build when to release as

much value as possible as early as possible;• Helping the Scrum team to plan and improve their

ways of working through retrospectives• Ensuring the work done by the team aligns with the

wider business strategy.

8

Project Manager plays the role of a SCRUM Master

Its the scrum Master who empowers the team to self organize. SM is responsible for the Scrum ceremonies & ensures team focus and protects team against disruptions.

9

All planned work is not DONE in a Sprint:

Agile in a non agile organization where many activities that should be part of the Development team is kept outside-testing is a classic example of this situation. This often results in slower bug resolution, not getting rapid feedback etc..

Projects instead of Teams:

Dont assign the team members to other work.They should be dedicated and ensuring good pipeline of work.

10

Chasing Velocity

What heppens when team is pushed ?

-Team focuses on the velocity than acheving the work

-Quality hampers

-Team members start blaming each other

11

Are we really working Agile?User is giving some requirements, then design is done, then development, then testing and finally

the completed story is delivered back to the user. The cycle begins again for the next user story,

or next iteration.Each iteration looks like small-waterfall.

12

The only difference between small-waterfall and waterfall is that we are going through the cycles more often.

How true Agile looks?

13

There isn’t much difference between the two pictures , main distinction is that there are no distinguished phases as Development/testing in true agile.

Development & Testing teams work together to make the construction & testing phase as a single continuous process.

14

How do we accomplish that?

Acting agile (stand-ups, sprint planning, demo, retrospective ) is comparatively manageable .

The difficult & most challenging part is to know what makes it agile and doing them correctly & consistently .

15

The following approach to start with will help in escape the waterfallish scrum

- Shift Test to the left The developer should know what tests will be run so the tests can be anticipated as part of construction. Before construction of a user story begins, the developer and tester should discuss the kinds of testing to be performed on the story. Advising the developer on what scripted tests the tester plans to run doesn't prevent the tester from introducing additional exploratory or other variations down the line.

- Test on Development environmentA better approach is to have the tester testing on the development environment throughout the process, even before the code is fully completed and checked into the source repository. A tester who is looking at the developer's work in near real time can give earlier feedback that identifies ambiguities and prompts needed improvements. There's no reason to wait for a formal build before giving such feedback, although the formal build also must be tested.

16

- Developer’s test casetester will benefit from knowing what tests the developer has run. This will allow the tester to identify areas with and without coverage, and to make better decisions about where to invest testing time.

- Unit testing ResultsThe tester should know where defects were found during unit testing and what parts of the code seem most complicated or worrisome. Knowledge of where the developer feels least confident or what the developer would refactor if time permitted is enormously valuable to the tester.

17

-Cross training (Dev /testing)

The developer should help the tester understand the code base, along with any related test code, while the tester should help the developer understand the test suite and the rationale behind related test techniques. A tester who understands the code base will be in a better position to look for trouble spots and areas of potential breakage. A developer who understands the test suite and how to build better tests will create a stronger product and write better test code.

18

-Focus on stories not on tasks daily

Stand-up story-by-story along with the person-by-person. Now it's very clear how each story is progressing¨.

-Engage with the business. Continue to engage with the business after the requirements phase. This allows sharing of additional context and ideas and encourages shorter and higher-level initial requirements, as business owners no longer feel that requirements specifications have to be their last word on the subject. Scrum teams should therefore include on the team business leaders who can make decisions regarding the project’s direction.

19

- Accept that change can happenBy supporting change while at the same timeensuring that the team understands the impact of that change, the team will not only buildbetter applications but will also learn more about its process for future implementations.-Adding more release activities to sprints. Incrementally add to sprints release process activities such as preproduction testing, data migration, and security and performance testing Including these tests within each sprint not only gathers more rapid feedback for the team but also encourages the team to automate these processes, increasing the overall fidelity of their results while also automating governance. Consistent automation of the complete promotion model also allows release managers to better understand software status.

20

Closing

There’s no shame in [hybrid methods] if that’s what works. When you’re going through a transition from Waterfall to Agile, that may be the best thing as opposed to a sudden change without getting the right benefit.

There is nothing wrong with other methodologies. If you think your team, department and, ultimately, company will benefit from Agile then give it a shot. But if everything is working smoothly, teams are happy and

successful products are being launch on time and on budget, Agile may be an unnecessary, burdensome change

21

Before switching to Agile, take a moment to review current practices, flag the major issues you’re hoping to correct, study and fully understand how Agile development works and

objectively evaluate if Agile will help your company. Take your time switching and be sure all the key players are on-board.

Remember, it’s about embracing what works for your company, not adhering to a development methodology for the name alone.

22

23