Agile Scrum case study

Example case:

You work for a bank company, with roughly 40-persons on the mobile apps department, that wants to create a new electronic wallet mobile app. These people are going to come from a traditional mindset & structure but they need to create this service to test if by working in an agile method they can develop things faster and connect better with their customers, as they need to engaged with the customers again, to try to stop the six months of continuous decreasing in customer satisfaction surveys.

Example case should answer:

What framework would you use?

What agile techniques and practices to use?

What are the main roles involved in the framework?

What value does this example bring?

How would you implement it?

Agile Management Example Assignment

Mobile application Department – Banksy Banks

?

?

1) Agile Scrum Framework

Scrum Framework

Scrum is quite well known in IT circles in general. It has been around for many years and was a buzz word in IT for several years. Although none of our staff have worked directly with Scrum, they are slightly familiar with its main concepts and processes. Scrum is also one of the simpler Agile methodologies to implement as it is not overly complex to form, however like all Agile frameworks it can be hard to do right! Scrum is an agile method to manage and execute a project. More precisely, Scrum is a framework for managing a process. Primarily Scrum was used in the development of software. In addition, Scrum can and is now used in a wide variety of areas for project management - wherever a team is working on a product or service. Scrum is Lightweight, Simple to understand & Difficult to master.

We are suggesting this framework as we believe it would be easier for our staff to change their mindset and mentality from a traditional waterfall approach, given that some aspects of Scrum are similar to waterfall, mainly incremental iterations are like mini/rapid waterfall iterations. We also do not want to confuse the staff with an overly complex methodology and would prefer to implement one framework well than multiple complex ones in part. We think that this is the best way to have one fully functional Agile framework implemented inside our team.

?

?

2) Agile Techniques and practices

Product Backlog

The Product Backlog is the holy grail of the product development process and arranging the Product Backlog should be one of the most important tasks the team should focus on. A good practice is to fill in the product backlog together with stakeholders. The stakeholders can contribute effectively in creating the product vision, and must be involved with the inputs of creating the product backlog. During the negotiations on the backlog and while re-prioritising tasks, the team and stakeholders can come to a better understanding of the vision and what is expected to be delivered by all. The Product backlog is a list of everything that the product should provide. It is never complete, and is ordered from top to bottom by priority. The Development team is responsible for all the estimates on the backlog.

?

Backlog estimation

a)?????Planning poker for estimation

Planning poker involves each estimator (developer) having a deck of cards with estimate times on them. For each story, the estimator selects a card with his/her estimate.

b)?????or T-Shirts Relative

T-shirt relative involves using t-shirt sizes XS, S, M, L, XL or XXL to define the estimate of each story.

c)?????And Velocity

Velocity measures how many user stories were completed by the team, on average, in previous sprints. It assists in estimating how much work the team is able to accomplish in future sprints however it should not be used to measure progress or compare teams.

Backlog Prioritization

a)?????MoSCoW

We would suggest to use MoSCoW which simply breaks down the backlog stories into groups of: M - Must have, S – Should have, - C – Could have, W – Won't have.

b)?????Dot Voting

This is a simple technique that lists all the stories and then marks them with a dot to identify the most important ones. Each participant has the same number of votes (Dots) and this number depends on how many people are participating and also the number of stories to choose from. At the end of voting, the stories with the highest number of dots are selected, and this makes the priority list.

?

Backlog definition

Creation of user stories which is a description of the functionality written on a card or post it. It’s a way to describe user requirements, often indicating wishes or requests for functionalities. However, we always need to be careful that we separate the Product & Sprint Backlogs. The product backlog is the complete list of tasks that need to be done till the product is ready for final release while sprint backlog is the set of tasks that will be taken up in a certain sprint. Having a clear backlog definition by using user stories, helps to: 1) Focus on describing the WHAT and never the HOW 2) Represents the business value and the people involved 3) Is something that brings value as a user 4) Is a description of functionality from the user’s point of view and expresses the value that brings & 5) Ensure that the description is short and understandable by everyone involved.

?

Scrum Meetings

Scrum meetings must be well defined. Their frequency, their duration, and what stakeholders participate in them. Scrum meetings are best done standing up also, the reason why the daily meeting is normally called a Stand-up is because people are expected to stand up, and not sit down! Typically, meetings where everyone is standing up are shorter and get the expected results, while sit-down meetings tend to drag on and on. Most scrum meeting frequencies are daily, and happen in the morning. The duration is normally 15 minutes, short and sweet.

?

Agile approach: Iterative

The method of working that we have chosen is an Iterative approach. This is not hugely different to the traditional waterfall which employees are familiar with as the waterfall method uses 1) Requirement Analysis, 2) Design, 3) Implementation, 4) Verification and 5) Maintenance whereas the Iterative form uses 1) Evaluation/Planning, 2) Requirements, 3) Analysis & Design, 4) Implementation/develop, 5) testing and 6) Deployment (If all OK). The differences between the two ideas are not huge, and we believe that the team will be able to grasp these new concepts quite quickly. We see the Agile Iterative Approach as a slimmed down and rapid version of the older waterfall method. Craig Larman is one of the best leading voices on Agile Iterative Model and he explains it excellently in his book “Agile and Iterative Development – A Manager’s Guide". Larman explains that the model functions on an ADTC Wheel (Analysis, Design, Code, Test). Each cycle is a reduced and faster method than traditionally and it means to say that each iteration cycle incorporates the Analysis of the plan, the Design, its Code and simultaneously the Test. The ADTC wheel is more technically referred to as the PDCA (Plan, Design, Check, Adjust) cycle.

?

Sprint Planning

Each sprint should last at most two weeks. Sprint planning must happen only once the product backlog has enough items for at least two sprints. Otherwise, the project could suffer from a scope creep, an uncontrolled growth in a project scope because the scope for the nearest sprints wasn’t fully defined in the product backlog. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people (Stakeholders) to attend Sprint Planning to provide advice.

?

Sprint Retrospective

This is set at the end of the sprint. The retrospective goal is to discuss what went wrong and what went well during the sprint in regards to people, relationships, processes and tools to better align the project progression with goals. Outputs or results of these meetings are to identify and order the major items that went well and potential improvements and to create a plan for implementing improvements to the way the Scrum Team does its work. Main stages of the Sprint Retrospective are 1) Set the Stage 2) Gather the data 3) Generate insight 4) Decide what to do and 5) Close the retrospective.

?

Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. Having a clear and commonly agreed upon DoD is vital to correctly functioning groups releasing quality products/services to the client/customer.

Sprint Goals

Sprint goals help make sure that the team and the customer align their objectives. If the goals for each sprint are not clearly laid out, it could become very difficult to prioritise the tasks in the backlog. Sprint goals are the single objective for the sprint. It creates coherence amount different stakeholders and also creates focus on what is needed to be delivered.

3) Roles

Product Owner??

For the Product Owner we are suggesting an existing employee who has been the go-to guy in terms of our current service offerings. His knowledge and expertise are exceptional, and many of the other employees turn to him for help or knowledge when they can’t resolve the issue themselves. He is relatively young, 33, and has worked with the company since he finished university at the age of 22. He started as an intern in the company, and has worked his way up to a senior position. He is ambitious and would relish the challenge of being Product Owner. The Product Owner is the person who creates the Product vision, sets the direction for each sprint, and acts as the bridge between the team, customers and stakeholders. The PO maintains and manages the Product Backlog which determines the progress of the product development.

?

Scrum Master

The Scrum Master is the one who holds things together, helping the PO to define value, and communicating that value to the team so that they can deliver it. He or she creates and facilitates an environment that is conducive to Scrum success. As the Scrum Master is an extremely important role in the world of Scrum, and it is also something which takes time and experience to master, we are proposing that one of the new hires (See section 5 for more information) will be an expert Scrum Master. In this way, we believe that we can hit the ground running, and would not have any delay to be able to implement Scrum correctly. Conversely, if we were to appoint an existing employee to be the Scrum Master, it would take time for them to learn the role, and to do training sessions and also take time to build up experience in working as a Scrum Master. To avoid all of those delays, we believe that hiring a specialist in this area would give our team a real advantage, and push them closer to being able to work in an Agile manner

?

Developers (Scrum Team members)

For the rest of the team, roughly 38 people, these will make up the Scrum Team as developers. The Scrum team is a cross-functional, self-organising group of developers who are jointly responsible for product delivery. These teams usually comprise of not more than seven people, who are required to communicate and collaborate well together. In our case we will have a mix of teams of 7 and 6 people. There is no hierarchy on a Scrum team, and the Scrum Master is considered their ‘servant leader’ and not their manager.

?

?

4) Value

It is the Product owners’ main responsibility is to maximize the value for the Product. Value can be defined in many different ways, as different stakeholders have contrasting ideas of what value means to them. Value can also change, from iteration to iteration. An example could be that the board feel that people downloading their app is value. But when this is satisfied, they then think that people using the app brings value. So, value is not set in stone, and keeping in touch with different stakeholders and understanding what they consider as value is important.

That said, in relation to Value, we can say that value can be defined in two ways: 1) The importance, worth, merit, or usefulness of something. 2) A principle or a behaviour standard. With this in mind we looked at value from the perspective of the business/board, Technology and Usage. In the following passages we will list the tools linked to value creation and also, we will list what each stakeholder values. Also, in section 2 we listed many tools that would also ensure to drive and deliver value although we will not repeat them here. We will just state that correct implementation of the tools in section 2 would help create value.

a)?????Business/board (Investors, board, sponsors) - There main metrics of value derived from the new product are Profitable & Affordable.

b)?????Technology (Architects, engineers, designers) – The main value brought by technology from the product is Functionality and Consumable.

c)?????Usage (Customer stakeholders) – Regarding the usage of the new product, the main value given is from being Usable and also Useful.

One of the tools that the team should use to maximise value would be by implementing Epics. Epics are linked to business value and strategic vision and purpose.?An Epic can be defined as a big chunk of work that has one common objective. It could be a feature, customer request or business requirement. We can consider them one big User Story. They help bring value normally by enabling a customer to manage products.

Another method to help increase value is by using Features. These are events/characteristics of the product or service. They should be clearly linked to value to the user in order to maximise satisfaction, quality and of course the value obtained by the customer from the product/service. A Feature is something your product has or is. This is typically functionality offered by a software program that enables users to do something, bring value with it.

User stories can also help with identifying and delivering value. One key activity in user story creation is story Splitting. To do this, each user story is broken down to understand and separate the high value from low value. What we are looking for here is the Pareto principle of 80:20 rule. If we have a story that has 80% effort and 20% result, it is not a high value item. Instead, we are looking for those stories that take 20% effort but return 80% result.

?

Outside of what has been stated previously, in order to provide Value-driven Delivery, it is important to meet a few requirements. First, those involved in a project should understand what adds value to customers and users, and should prioritize the high value requirements in the Prioritized Product Backlog. Second, those involved in a project should decrease uncertainty and constantly address risks that can potentially decrease value if they materialize; it is important to show product increments to project stakeholders at the end of each Sprint, enabling effective management of changes. Third, those involved in a project should create deliverables by producing potentially shippable, value-based product increments during each Sprint so that customers start realizing value early in the project.

Lastly, a great way to actually measure value is by implementing KPI’s or OKR's. It is important to classify what the stakeholders consider as value (As already pointed out) and once this is done it is then possible to use OKR's/KPI’s to measure that value to the stakeholder. Example KPI’s that could be used are: Sprint Goal Success, Team Velocity, Time to Market, ROI & Customer Satisfaction (Using NPS).

?

?

?

?

?

5) Managing the change

To be able to implement Agile Scrum Methodology correctly and swiftly in our organisation we are proposing a list of steps that we recommend taking.

Hiring of new staff.

As we have a team of 40 people, who all have worked in a traditional way for many years, we suggest hiring some new staff with experience and knowledge of Scrum to help the whole team get up to speed quickly with Scrum. To balance this, and to keep the number of people at 40, we would look to??relocate 4 staff within the corporation or releasing/firing those staff (Max 4 = 10% of total). Obviously, our department would need to work closely with HR regarding the finances of that. The new hires, should all have an agile mindset. We would need to hire a person who has worked as a Scrum Master in the past. For this position we would look at an experienced person that is around 30-40 years old. For the other three people we would look as hiring Scrum developers, with a younger profile, around 20-30 years old as we hope their youth and enthusiasm would be infectious to the other team members.

?

Training/Teaching

Learning workshops for the staff would be critical. These would need to be created and delivered in the shortest timelines possible. The quicker that we can get people familiar with Scrum, the quicker we can start to deliver value to the customers with our project of a new mobile wallet application.

?

Release plan

Having a clear Release plan using graphical tools such as Gantt charts will help employees understand the timelines and objectives of the Project breakdown.

Our Product Owner is responsible for managing expectations of customers, users and other stakeholders. They are also responsible for Product Backlog Management, for deciding what to build when and what not to build. Also, they will need to decide what to deliver (release) to customers/users, in what order to deliver them to customers/users and when to deliver them. Our Product Owner will need to have a release strategy and a clear release plan for our developers to follow. Some other key suggestions for our Product Owner in managing the release plan would be:

1.?????Release early and often

2.?????Focus on goals, benefits and results

3.?????Only release work that is ‘Done’ (As defined in DoD)

4.?????Improve the release process continuously

5.?????Don’t release for the sake of releasing

?

Practices and Techniques

In section two we listed a multitude of practices and techniques used to help us implement Scrum and it goes without saying that we will rely on those to manage the change. As we will hire an experienced Scrum Master and also conduct multiple learning workshops with our staff the hope is that most if not all our staff with migrate to an Agile mentality quite quickly. On top of section two, we would also suggest the following technique:

1) Inception

This is done at the beginning of the process, like a kick off meeting. It is where a Product Owner will pull together the scrum team with the aim at getting that team across the next major piece of value that they intend on delivering. In these meetings anything goes, so any out of the box suggestions are welcome. The idea is to be able to create, innovate, and classify value for the deliverable. It is also hoped that by running these sessions, a more Agile mentality will be fostered in all of our teams.

?

Team structure

Overall, we have a 40 strong team under our control. Of these, the hope will be to have one Scrum Master and at least One Product Owner. As time passes, and other people are trained, we hope to have multiple Product Owners. To make sure that this structure was possible we consulted Scrum.Org First & Second. Knowing that this structure was possible and using already 2 resources from 40, we needed to divide the other 38 people into teams. Knowing that Scrum teams can be as big as 9-10, but that around 7 is best, we worked towards the best scenario. In the end we decided with 4 teams of 6 people (Which will have a PO and SM in addition but not counted as they don’t work directly on the tasks) and two teams of 7 (Again with the common PO & SM). Now given that we would like to have multiple Product Owners, we would obviously need to re-balance the teams in future. So, this structure is for the first 6-12months of our new adventure into Agile land.

For the six teams created, we can decide to group them in different ways:

1.?????Division by business initiative

2.?????Division by technology expertise

3.?????Division by functional areas

We suggest dividing the teams by business initiative. It means that for each initiative sponsored by the portfolio management is formed a team that is in charge of the initiative. The main reason for proposing this kind of organization is that the team has all the needed competencies to complete the initiative.

Take care all.

*Special thanks to my fellow sharer of knowledge and co-writer/creator Vittoria Ferrero