Agile Playbook — 2021
a practitioner’s perspective
“Often we work harder in teams, but not necessarily smarter. Agile is common sense, empathy, communication.
As a Product Owner and an Agile Coach, my thoughts consists of plans and actions to effectively deliver a product or a service.” ~ Satish Velagapudi
People, problems, and products (shippable software) matter over tools and processes.
Building Agile Culture
Imbibing Agile mindset — imparting a set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change.
“The number one challenge facing a leader in an agile culture is letting go of fears related to losing control and not being needed”.
How OSI actually did it
Started with one small and one big project
Instead of having the entire organization and all projects beginning to follow agile, it worked well to start small without re-organizing a lot of things. Having only a few people join a mission-mode agile transformation program is less disruptive to an organization.
Secured Senior Leadership Commitment
Had a single senior executive sponsor facilitating program success and established a communications structure to facilitate communication top to bottom. Identified a capable program manager, product owner, and Scrum Master
Empowered the Team
A product owner and an agile coach provided the decision-making authority
The other roles, ScrumMaster and Agile Team, were also created and empowered to become self-managing and collaborative. As the project/product was incrementally developed, prototypes, and demonstrations were used to facilitate the development of the right product. Changes are made near real-time, and priorities are updated with each iteration. Collaboration and involvement of all the stakeholders at the appropriate times kept the product on track.
Built Collaborative Culture
To facilitate the culture of collaboration, all the core team members (Product Owner, Scrum Master, Architects, Team Leads) were physically co-located or connected virtually. This means if physical co-location is not an option; the team participated in all daily Scrum meetings through video conferencing using Microsoft Teams enabling virtual face-to-face meetings.
Acquired an Agile Coach and Trained the Team
Trying to do the agile transformation with resources that have no experience greatly impacts your ability to be successful. It definitely helped to have an experienced Product Owner, Agile Coach, ScrumMaster, and at least 20% of the team with agile experience.
Selectively transitioned from waterfall to agile
Our clients eventually loved agile processes because they got to review deliverables and offer feedback at the end of every sprint. At first, however, managing a more collaborative process got tricky. The time commitments required to execute successful agile projects were initially daunting, especially they were used to waterfall practices, where deliverables are much fewer and further between without as many opportunities for input.
Here’s an example of the Agile workflow within a single sprint
- The Product Owner — the one responsible for its completion — reviews the incomplete tasks in the Product Backlog. The obsolete tasks get removed while the new ones get added
- The Product Owner establishes the scope of the new sprint and the goal it aims to achieve.
- The Product Owner has a Planning Meeting with the Architecture and Development Team. They create user stories, which are decomposed into the tasks for the sprint
- The Development Team holds daily meetings, during which they keep themselves updated about the progress of each team member;
- Once the timeframe of the sprint runs out, the sprint is considered complete. The unfinished tasks are moved back into the Product Backlog; In exceptional cases, a sprint end-date can be changed by a Product Owner.
- The Product Owner holds a demonstration for the Customer and shows the work done during the sprint.
- The Product Owner holds a retrospective meeting with the Development Team, where the results of the Sprint are reviewed. The team establishes what was done well, and what processes can be improved in the next sprint.
- The Product Owner facilitates requirements stories and UX (only if applicable) readiness for customer approval at least a sprint ahead of actual development
- The next Sprint begins.
The regular review of the Backlog helps to maintain the relevancy of the features in the Backlog. The limited scope of Sprints and their pre-established goals help the developers complete meaningful work on time. The continuous showcases of new features keep the customer happy and able to provide feedback by doing an extended QA (you may read as pre-UAT)
As part of planning, the product owner works with the project/product sponsor, functional, technical teams to create the following
- Executive Intent & Solution/Product Vision.
- A roadmap. is a plan on how the solution/product should evolve to achieve the above vision
- Release Plan defines the list of features that will be delivered in the decided timeline
- Iteration/Sprint Plan involves user story creation and backlog grooming
Planning is to be diligently done at the beginning of the project, before each iteration, completion, and beginning of a program increment (PI)
*In product companies, themes at a program increment and major release level influences the features, epics that go in
User Story — Follow the Format
Remember user story is not just for current sprint development but a “single source of truth” for the requirement.
“A good well rounded user story will serve well in the future (after months/years) and also in times of disagreements.” ~Satish Velagapudi
1. Clear title for user story that we could find easily by search
2. Story description — leave nothing for ambiguity. Include
a. Use cases
b. Write for both functional and technical members of the team
c. Provide reference URLs — detailed spec document, API, UX/UI screens/link, etc
d. Write about ‘architectural impact’
e. Write about ‘business value’
f. Write about ‘dependency/impact on current features’
3. Acceptance Criterion — remember this is the baseline for expanding into test case scenarios. Include performance and security aspects as relevant
Laws of Planning
1. Hofstadter’s Law
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
Takeaway/Solution — poker or pick points democratically that are widely accepted by the team
2. Murphy’s Law
“Whatever can go wrong, will go wrong.”
Takeaway/Solution — build in some level of contingency. Generally, a 10–20% contingency over the original estimate is not only recommended, a lot of the time it is expected.
3. Parkinson’s Law
“Work expands so as to fill the time available for its completion.”
Takeaway/Solution — keep extra time separate from the original estimates. cut through the unnecessary.
4. Sturgeon’s Law
“Ninety percent of everything is crap.”
Sturgeon’s law often helps simplify things when it comes to estimation and being mindful of the most important 10%.
Takeaway/Solution — we don’t want to go too granular, otherwise, we will never finish the current process, but we don’t want to be estimating too large of tasks either.
5. Brooks Law
“Adding manpower to a late software project makes it later.”
Takeaway/Solution — This law, of course, is an oversimplification, as there are many cases where it does not hold true. For example, if the resource joining the project is already familiar with the codebase and the project, they could hit the ground running and have an instantaneous benefit. Additionally, if the deadline for the final deliverable is many months down the line, the extra resource might have time to turn things around.
Estimating Story Points
- Involve the team as a whole when it comes to estimating upcoming work to increase the sense of collective ownership and better validate the estimates.
- Always try to estimate smaller pieces of work (within reason), to have better estimates.
- Always add some contingency to project work to cater to the unexpected.
- Keep the contingency separately from the rest of the estimates and do not distribute it to each piece of work.
- Be careful when adding extra resources to an already-late project as they can lead to the project being delayed further.
Expectations/Assumptions/Misconceptions to be careful with
- Expectation: team to work harder and deliver more story points, or compare number of teams with ‘past v/s present story points produced’
- Assumption: “well, last time Resource X made five story points per week, so that means a story point equals one day.”
- Assumption: one five-point story takes the same time as five one-point stories or we decided one story point equals one day for one person.
- Misconception: features are user stories and user stories should be big enough
What should we do to make it right?
1. Educate: as a rule of thumb, a team that is too big is 10 or more people and a story that is too small is around one day’s effort or less
2. Adapt: out of Fibonacci (1, 2, 3, 5, 8, 13, 21) sequence for story points — 13 and 21 are for extreme and complex cases. otherwise, always stick to 1, 2, 3, 5, and 8 point story sizes
3. Adapt: give a range whenever the customer is asking for guesstimates with unfinished stories
○ ex: we could say 5 points but could be 21 if they asked for every bell and whistle and if a few things turn out to be harder than they expect.
5. Adapt: the role of story points is also to measure complexity. how much complexity can the team handle per sprint? that is simply not the same thing as time.
○ so, if a story has five points, it does absolutely not mean it takes five times as much time as a one-point story. It means it’s five times as complex as a one-point story
6. Adapt: have one complexity per scrum team per sprint that the team can handle.
pls note: adaption cannot happen without sincerely educating the customer
OKRs — Objectives and Key Responsibilities
Improve capacity utilization of all resources loaded
- Requirements: user story detailing, comments, discussions, additional referencing information. Target 90% adherence to the template as a start. Remember 4–2–1 formula; 4 sprints worth feature backlog, 2 sprints worth groomed stories, 1 sprint worth approved (development-ready) backlog at any time.
- CX/UX: implement CX/UX monitoring tool and conduct surveys. reduce the CX/UX issues by 50% while improving visibility and metrics around 5 top UX KPIs**
- Trust factor: weekly/monthly reports with more detailed/accurate (task) descriptions (PPT/doc/dashboard), weekly data (metrics) driven discussions/meetings (PPT/doc), visual reporting/dashboards through agile tools
- Code quality and unit test coverage: increase unit test coverage to 85%. reduce bugs found during sprint development by 50%, individual developers contribute to peer code reviews by the end of every sprint
- Architectural decisions: Lightweight Architecture Decision Records (LADR) — Sample Decision Record
- Documentation: improve internal as well as client-facing documentation
Maintain consistent agile process
- Design and implement workflow graph
- Zero miss of scrum ceremonies
Improve employee engagement and satisfaction
- Reduce employee attrition
- Interview employees and measure their satisfaction levels
- Make sure every manager/lead is working on a 2-way feedback loop
Complete all employee reviews and training on time (project-specific)
- Collect performance data from all the leads on time
- Implement performance reviews once every 3 sprints
- Review the training needs of all the newly loaded employees
- Organize regular training/orientation sessions for employees
- Gather feedback from all the training activities going on
**5 top CX/UX KPIs: (How long will it take the user to accomplish the task/most important tasks, How many users fail to accomplish tasks? How many users get frustrated along the user journey of the product? How many users are delighted by how easily can be the goals can be easily accomplished? Where all the users came from?
Production Support: Application and Infrastructure Management Service
Improve the efficiency of the support team
- Better roaster/rotation
- Bi-weekly switch between development (enhancements) and support (bugs/fixes)
- Maintain a weekly performance report
Track and monitor all the critical support metrics
- Identify the number of new tickets and resolved tickets per day
- Track and monitor the average resolution time
- Track top 10 issues and build solution playbook
Deliver higher customer support experience
- Implement SLA agreed with the customer
- Each support engineer to have a personal goal of resolved tickets
- Conduct interviews with top customers to improve performance
- Maintain loaded resources efforts and make sure they are adequately reflected and reported
- Identify tasks and pitch ahead of time
- Create and demonstrate POCs around solutions that bring unique value to the customer and get a buy-in
Essential safety-nets for times of despair and unexpected circumstances
- Involve leads/core offshore team into preliminary escalation meetings
- Present and agree on a plan with the customer first before executing a resolution
- Close monitoring and actions around resource/team utilization, constraints, skill-gaps
- End Customer/User Experience (CX/UX) KPIs (mandatorily dedicated and ongoing)
- Automation (mandatorily dedicated and ongoing wherever possible — testing, performance, security)
- Proactive production system monitoring
- Proactively address/ask customer’s core team concerns, ideas, and thoughts with no-delay
- Reactively address customer’s Executive Team concerns, ideas, and thoughts using metrics/data-points
- The communication gap between onsite and offshore in understanding and resolving technical issues
Ongoing Innovation Backlog
Visibility/Transparency/DIY initiatives — very important to keep the juices flowing and create innovations that will not only contribute to the project but also to the organization in general.
- Run innovation sprint — not to mix this up with tech debt, the intent is to hand-pick resources and create things that we didn’t think before and bring in the unique value
- Cognitive AI-based Automation — testing, DevOps
- Advanced Analytic Dashboards — CX/UX KPIs, Infra & Application Health Monitoring
It can become easy to fall into various traps with software engineering. Sometimes it is using Jira when sticky notes or a spreadsheet would suffice. Other times it is adhering to various prescribed meetings that aren’t working. If you get value out of the entire team meeting for stand up then that’s great, keep doing it. If you find stand-up not helping boost team collaboration or keeping everyone informed then don’t feel bad about canceling it.
When team members sign up for tasks they feel a greater sense of individual accountability toward those tasks with their names on them. Seeing my name next to a particular task will make it more likely I complete the work on that task. A team will be at its best with a strong sense of team accountability (everyone is accountable for all the work). But it’s hard to create team accountability without having individual accountability first.
When it comes down to it, you’d be surprised how much we can get done with a few motivated individuals that enjoy working together and understand the problem well enough to collaborate with customer teams.
OSI Digital’s Agile Teams
Provide dedicated sprint teams comprising motivated individuals as your co-development or independent development partners. We provide agile-engineering as a service (create and manage backlogs and sprint teams for you) where you would also get discounted T&M-based coverage from senior product owners, architects, and OSI leadership/senior technical management teams.
Agile Delivery — Prioritize and produce critical business initiatives
Automation — Software release operations and testing
Quality Engineering — Continuous testing enabling faster delivery
DevSecOps — automating and managing your DevOps including security
- Mckinsey Article — Doing vs being: Practical lessons on building an agile culture, Retrieved from https://www.mckinsey.com/business-functions/organization/our-insights/doing-vs-being-practical-lessons-on-building-an-agile-culture
Content provided in this blog is purely personal experiences and for educational purposes only. Any similarity with what you read before is purely coincidental. All trademarks, service marks, and company names used are the property of their respective owners. Images courtesy: stock.adobe.com, unsplash.com