A good friend of mine has recommended me to convert slides into a LinkedIN post and I liked the idea of doing it. The information on Agile/Scrum prepared below is based on the materials from Dr. Jeff Sutherland and Ken Schwaber, both of whom have inspired and led me in Agile practice for many years. In Asia specifically, Adrian Lander, another friend of mine, has been a great inspirer for me in Agile/Scrum.
I have originally prepared these slides to support Agile/Scrum methodology in a mobile application development scenario where both Agile and non-Agile teams existed.
First and foremost, I would like to point out that TRUST is one of the most important element for success. If there is no TRUST in the team it doesn't matter whatever methodology you use. In case you are in a situation where you need to build trust, Agile has the highest level of transparency to support this.
Scrum Summary
Scrum is an iterative, incremental framework for projects and product or application
development. It structures development in cycles of work called Sprints. These iterations are no more than one month each, and take place one after the other without any break.
The Sprints are time-boxed – they end on a specific date whether the work has been completed or not, and are never extended.
At the beginning of each Sprint, a cross-functional team selects items (requirements) from a prioritised list (backlog). The team forecasts to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change. Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining.
At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates what it has built. People obtain feedback that can be incorporated in the next Sprint. Scrum emphasises working product at the end of the Sprint that is really “done”; in the case of software, this means code that is integrated, fully tested and potentially shippable.
3s of Scrum
Roles
- Product Owner
- Scrum Master
- Developers
Ceremonies
1.Sprint Planning
2.Sprint Review and Retrospective
3.Daily Scrum Meeting
Artefacts
1.Product Backlog
2.Sprint Backlog
3.Burn down Chart
Phases
In an enterprise environment it is easier to explain Scrum in phases where majority of stakeholders are engaged in waterfall projects with phases.
1 - Pre-game (time-boxed to 2-3 days)
- Planning
- System Architecture/High level Design (Keep it high level.. No big upfront nor complex designs and avoid recipe style approaches!)
2 - Game ( time-boxed to 6 sprints (for this scenario) aka release 1 / first release / minimum viable product )
- Sprints
- Develop (Analysis, Design, Develop)
- Wrap
- Review
- Adjust
3 - Post-game (time-boxed to 2 days to 2 weeks * depends on your approach,support model and context)
- Closure
Scrum Process
Mobile Application Team Workflow
Business Units > Product Owner (1 person!) > Development
Business Units here represents all stakeholders that includes internal and external units or teams.
Example : General manager, unit manager, operational team members.
Product Owner means a person who :
- Defines features and prioritise
- is Fully accountable for the product
- Review results in 2-4 weeks iterations and accepts/rejects these results
Development is set of activities include and not limited to :
- Design
- Build
- Test
- Deploy
Proposed Team Structure
Product Owner : Business unit member
Scrum Master : Internal IT staff (this could be anyone with solid Agile/scrum knowledge who can protect and ensures the scrum process is being followed.)
Developers : Internal IT staff (Senior mobile developer + 2 mobile developer + 1 UX/UI Designer) The team was blended with cross functional developers and designer who can cover all the areas required to be able to deliver the working software.
In my case, I have added another unit under support to ensure that the team who is working on this also is learning and being coached closely by an expert Agile coach.
Support : External Agile Coach was critical to the successful implementation of Agile/Scrum where Scrum was new to the organisation.
Product Owner Timeline and Role
Having created a timeline to ensure it is clear what level of time commitment would be required from product owner. I have found out that In organisations that does operate in waterfall or waterfall like methodologies, it is critical to present and provide upfront the high level timeline to get the required support. Basically, this means that you should be prepared to be able to "talk in their language" . In my case, therefore I prepared a high level project plan to show how much time might be required from product owner. It was planned to have first release in 4 sprints and each sprint was 4 weeks.
Below is what it looked like :
*Please note that term "Sprint 0" is not part of scrum, it is a term used to get people familiar with the concept of having the planning session done in a time-boxed manner as in a "sprint"
Product owner role will require at least 10 percent of sprint time (2 weeks sprint means 10 days / 80 hours which is 8 hours minimum for that sprint) There is no single recipe as this is to give some insight regarding to the "how much time required from product owner ? "
To make things more clearer, as the product owner you might end up spending more than 8 hours in a sprint to refine a product backlog/OK backlog items and feedback.
I have grouped the activities under planning and review for product owner in this context to make it easier rather than breaking into detailed tasks as in waterfall methodology.
Product Owner Role :
- Interact with the development team to review/accept/reject results in 2-4 weeks iterations.
- Accountable for mobile application product and has full authority on the product.
- Represents the desires of business and community
- Single authority to prioritise/order or change product backlog.
- Decisions done by product owner must be respected by the organisation.
Development Approach
I have created two development streams who would work in parallel due to the current scenario. In this scenario, front end will be driving the development required at backend via product backlog. All teams are located onshore and backend teams are operating under waterfall methodology in this scenario.
My ideal scenario would be merging the teams and creating multiple scrum teams using Scrum of Scrums approach.
I have also created a high level timeline and time-boxed it as below.
I have put definitions for Scrum Phases as below from Jeff Sutherland's scrum papers located at this link.
Planning:
- Development of a comprehensive backlog list.
- Definition of the delivery date and functionality of one or more releases.
- Selection of the release most appropriate for immediate development.
- Mapping of product packets (objects) for backlog items in the selected release.
- Definition of project team(s) for the building of the new release.
- Assessment of risk and appropriate risk controls.
- Review and possible adjustment of backlog items and packets.
- Validation or re-selection of development tools and infrastructure.
- Estimation of release cost, including development, collateral material, marketing, training, and rollout. *Verification of management approval and funding.
Scrum Phase: High Level Design
- Review assigned backlog items.
- Identify changes necessary to implement backlog items.
- Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements.
- Refine the system architecture to support the new context and requirements.
- Identify any problems or issues in developing or implementing the changes
- Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.
Scrum Phase: Development
Develop: Defining changes needed for the implementation of backlog requirements into packets, opening the packets, performing domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation.
Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements.
Review: All teams meeting to present work and review progress, raising and resolving issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined.
Adjust: Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.
Scrum Phase: Closure
When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase.
The closure phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
Controls in Scrum Methodology
This was the material I have added to bring down the noise of people who mix up Agile/Scrum with cowboy style coding.
Backlog: Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items.
Release/Enhancement: backlog items that at a point in time represent a viable release based on the variables of requirements, time, quality, and competition.
Packets: Product components or objects that must be changed to implement a backlog item into a new release.
Changes: Changes that must occur to a packet to implement a backlog item.
Problems: Technical problems that occur and must be solved to implement a change.
Risks: risks that affect the success of the project are continuously assessed and responses planned. Other controls are affected as a result of risk assessment.
Solutions: solutions to the problems and risks, often resulting in changes.
Issues: Overall project and project issues that are not defined in terms of packets, changes and problems.
Scrum Metrics
I just want to make it clear, this is really for hyper-productive teams so do not try to apply all these metrics right away into a new formed scrum team. Based on my experience, most scrum teams need at least 2-3 sprints or more to be able to hit their peek level of productivity. I suggest not to bombard your team right away with such metrics. Team dynamics has to be in place to be able to start measuring and improving below areas. You might also consider some or all of these items to be a part of your Scrum retrospective session such as accuracy of forecast.
Below are the scrum metrics for hyper-productive teams by Jeff Sutherland and Scott Downey.
- Velocity
∑ of original estimates of all accepted work
- Work Capacity
The sum of all work reported during the Sprint, whether the SBI toward which the work was applied finished or not.
Focus Factor
Velocity ÷ Work CapacityPercentage of Adopted Work
∑(Original Estimates of Adopted Work) ÷ (Original Forecast for the Sprint)Percentage of Found Work
∑(Original Estimates of Found Work) ÷ (Original Forecast for the Sprint)Accuracy of Estimation
1-(∑(Estimate Deltas) ÷ Total Forecast)Accuracy of Forecast
(∑Original Estimates) ∑ (∑Original Estimates + ∑Adopted Work + ∑Found Work)
Targeted Value Increase (TVI+)
Current Sprint’s Velocity ÷ Original VelocitySuccess at Scale
For each Point on the Fibonacci Scale (Fp), the formula is: (∑No. Accepted Attempts of scale Fp) ÷(No. of All Attempts of scale Fp)
- Win/Loss Record : Each Sprint is a Win only if:
a) A minimum of 80% of the Original Forecast is Accepted
b) Found + Adopted Work During the Sprint remains at 20% or less of the Original Forecast.
References:
Scrum Guide - Ken Schwaber & Jeff Sutherland