Deriving a backlog for large projects

When executing a large project, that involves hundreds or thousands of people, it’s important to have a vision and a plan for achieving your project goals.

Before initiating a project, following are the essential artifacts which are vital before development team can be introduced.

1. A high-level vision of the end product includes

a. List of capabilities

b. Constraints

c. A set of targeted customer segments

d. Supported scenario or

e. Or an announcement on project end date to key stake holders or a date for major press release.

2. A high-level architecture, lists various components that interact to achieve product vision.

3. A high level schedule

High level schedule consists of milestones, these milestones can be further classified as Internal or External.

a. Internal Milestones are internal to project team and should have dates for key event like finalize user interface, internal stakeholder approvals, beta launch, etc. 

b. External Milestones are key event dates out side the project team, these external milestones could be press release date, conference announcement dates, etc. 

In-short, a high-level vision, architecture and schedule is important for project success, but it can not be overdone. Too much upfront planning tends to be a wasteful, since there are many unknowns and requirements often change.

Once you have initial high-level plan, development team need to know their contribution to the vision, architecture and schedule. This knowledge is essential to derive each team’s work backlog. 

Let’s look at architecture and vision to derive this information.

Here are two approaches to build backlog for each team, refer to figure as well.

• By Scenario, each team owns a different scenario described in the vision (such as book a flight ticket, auto upgrade preferred customers to business class )

The team creates components on need basis, the components get refactored by other team on need basis.

The scenario approach ensures complete end-to-end experience, but it may result in poorly engineered components constructed by too many hands.

Team’s backlog is derived by breaking down the team’s assigned scenario into individual features or stories

• By component, each individual team owns a component laid out in the architecture (such as build library, enhance performance, etc.).

The component approach provides clear boundaries for teams but may lead to in-complete end-to-end experiences. 

Team’s backlog is derived by breaking down the team’s assigned component into individual features or requirements.

Top 10 Dev Ops Book by Ernest Mueller and James Wickett

In this article, I am going to share my learnings on the top 10 books recommended by Ernest Mueller and James Wickett who curated the DevOps course “DevOps Foundations with Ernest Mueller, James Wickett” on Lynda.  

This is a republication from the content of the video.

Number 10,  Visible Ops. 

Visible Ops by Gene Kim is one of the bestselling IT books of all time. It boils down ITIL into four key practices that his research shows to bring high value to organizations through a Lean implementation of change control principles.

Number 9, Continuous Delivery. 

Continuous Delivery is the book on continuous delivery. It was written by David Farley and Jez Humble. This book is so chock full of practices and principles along with comm antipatterns that it really was useful along that journey. 

Number 8, Release It! 

This book's premise is to design and deploy production ready software with an emphasis on production ready. Release It! has given much of the industry a new vocabulary. Author Michael Nygard provides his designs patterns for stability, security and transparency. It won the Dr. Dobb's Jolt Award for productivity in 2008. 

Number 7, Effective DevOps. 

It was written by Jennifer Davis and Katherine Daniels. This features lots of practical advice for organizational alignment in DevOps and it makes sure to fit the cultural aspects alongside the tooling. This book has all the interesting case studies they did.

Number 6, Lean Software Development, An Agile Toolkit. 

Mary and Tom Poppendieck authored this seminal work on bringing Lean concepts into software development, and exploring the benefit of value stream mapping and waste reduction. They explain the seven Lean principles applicable to software and cover a wide variety of conceptual tools, along with plenty of examples. This book is the single best introduction to the topic of Lean software. 

Number 5, Web Operations

This book is edited by John Allspaw who gave the groundbreaking 10 Deploys a Day presentation of velocity back in 2009. 
This book is a collection of essays from practitioners ranging from monitoring to handling post-mortems to dealing with stability with databases. It also contains medical doctor Richard Cook's amazing paper How Complex Systems Fail.

Number 4, The Practice of Cloud System Administration 

This book, written by Tom Limoncelli is a textbook on system administration topics that continues to be updated. 

It has an entire section on DevOps,  and is recommend to a sysadmin or ops engineer.

Number 3, The DevOps Handbook

Subtitled, "How to create world-class agility, reliability "and security in technology  organizations." 

This book is by Gene Kim, Jez Humble, Patrick Debois and John Willis. 

It was under development for five years by these leaders of the DevOps movement, and it's the standard reference on DevOps. 

Number 2, Leading The Transformation 

One book that deserves special mention for enterprises is Gary Gruver and Tommy Mouser's book, Leading The Transformation, Applying Agile and DevOps Principles at Scale. 

This is a book for directors, VPs, CTOs, and anyone in charge of leading IT organizational change of any size. Gruver describes leading DevOps transformations at HP in the firmware division for printers, and at the retailer Macy's, both with incredible success.

Number 1, The Phoenix Project

This is the bestselling book by Gene Kim, George Spafford and Kevin Behr. It's a modern retelling of Goldratt's The Goal. This is in a novel format and it walks you through one company's problems and their transformation to Lean and DevOps principles. 

Agile Project team Kick off meeting framework

     Current working environment

1. We work in an ever-changing environment and the only thing constant is “change”.  It must not be an un-common scenario when new agile teams are carved out/created to deliver a solution epics  OR a reorganization leaves you with an option of creating new Agile teams.
   
2. In this topic, I will list down important agenda items to be covered in an Agile Project Kick-off.  This helps the whole team to be aligned with Project/Product Goals.

When to conduct Agile Project Kick off?

1. Team receives a new feature/epic development.
2. Re-organization of Agile teams.
3. New teams are created/carved out.
4. Major policy, process changes around the environment we operate (agenda of the meeting will slightly vary).
5. New enhancement or a fresh project has to be started

Why we do an Agile Kick off?

1. Sets/Re-set ground rules for the team.
2. Baseline's team understanding on the project environment.
3. Introduce team members, operations, processes and shared artifacts.

Agenda and time box

Meet and Greet

Example of introduction

Outcomes of Meet and Greet

Project Overview

Provide project overview to the team so they help us achieve business objectives. Following are few topics which we should cover 

1.  Business Objectives
2.  Customer agreement: milestones with agreed dates
3.  Delivery approach: Any specific methodology Agile (Scrum, Kanban, 
4.  Scrumban, etc.) or Waterfall
5.  Estimates: Person days and revenue
6.  Key contacts: Name and email addresses of key project stakeholders
7.  Ownership and location:
8.  Risk and mitigation plan: Highlight any risk and available mitigation plan
9.  Issues: Highlight any current roadblocks to the success of project 

Development Process and tools eco-system

This part of the meeting should highlight the process of development, this may differ from team to team.  Based on few of my projects, I will have the following topics:

1. Discuss common tools and process and share the process for accessing these tools.

Example: 

Agile methodology adopted(Scrum/Kanban…), DevOps infrastructure and related tools, Bug tracker or QA tools.

2. Highlight the engineering process adopted by team.

Example: Code reviews, Pair programming,  Refactoring.

For example
QA team member provides initial data setup and hypothesis for the development)
Developer agrees to show demo and pair with QA and BA.

Comments

Share your thoughts and do update me what you do in your kick off meetings.

Agile Retrospective Ceremony

In this article, we will go through the most interesting and challenging ceremonies of agile. This article will provide an structured way of executing retrospective meetings and lists down what worked for me to get optimum results.

Phase 1

Kick off your retrospective by showing following metrics to the team, which is the reflection of how we did in current sprint vs historical sprints. This is critical for initiating a conversation between teams. At this stage, i do not encourage team to ask any question or start a conversation immediately, the scrum master should take few minutes summarizing the iteration. While scrum master is speaking, every other team member is visualizing this data generating constructive thoughts around the data points.

Following are some of the examples of data point you can use for  a typical software development project.

a. Sprint Velocity Historical vs Current Sprint

b. Carry Over Stories Historical vs Current Sprint

c. Defect Density Historical vs Current Sprint 

d. Defect Leakage

e. Bugs Story/Sprint/Release Historical vs Current

f.  Lead time or Cycle time

In Phase 2 of the iteration, I'll cover a formal and well-structured approach running retrospective. The 5 stages of Retrospective are illustrated and explained in Phase 2.

Phase 2

I discovered a structured way of executing retrospective, which worked for me and I use this methodology in coaching and training too.  This is derived from book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

The five stages of retrospective are:

1. Setting stage

2. Gathering data

3. Generating Insight

4. Defining what to do

5. Close 

This article provides a quick overview of what we do in each of this stage.

Setting stage

During this stage you should start by asking team's interest in retrospective, understand the top  two or three outcomes which they want as a take away from this discussion. 

There are times when team are routinely running common questions in retrospectives which becomes ineffective over a period of time and do not result in any outcomes.

Encourage teams to have open ended discussion on variety of topics, some of the examples are

1. Benefits of XP practices inducted from last iterations.
2. Ideas on improvement to current automation.
3. Gather training needs.

It is of vital importance that we focus on following:

1.  Inquiry over Advocacy
2.  Dialog over Debate
3.  Conversation over Argument  and 
4.  Understanding over  Defending individual points

This needs to be taken care very amicably. Based on few experienced scrum masters, some members take it as they are being questioned for in-competence directly.

Gathering data

This stage is carried out by looking back on the sprint and team members should do a self-retrospective. The data point or facts presented in Phase 1 is a key in data gathering. 

Generating Insight

Good data is the foundation for the process. Data collected from above phases Phase 1 and Phase 2 (Generating data) helps us get an insight on past performance and improvement areas.

This stage helps us

1. Generate shared understanding
2. Identify the underlying causes by performing pattern identification or root cause analysis

Defining what to do

This chapter of the ceremony contains 

1. Actionable items

2. Owners and 

3. Due date 

Identify maximum two improvements we can do as a group in next iteration. This may be an experiment. But remember to pick an improvement which will benefit the whole team and is aligned to product/feature development.

Following are few examples of next steps

Engineering focused 

1. Focus on XP practices 

        a. Give more attention to pair programming

        b. Spend more time refactoring

        c. Increase the quality of code coverage 

2. Increased quality by reduced defects and re-work

3. Increased focus on Continuous Integration 

Team focused

4. Have more frequent on-shore offshore meetings

5. Meet on a VC rather than phone call (This we had in our retro, we followed & it really helped)

Tips to prioritize and finalize improvements which will be taken up by team

1. Create an idea board of commitments which team has shortlisted

2. Get vote on each one of the idea

3. Pick top 2 or 3 improvements areas which received maximum votes.

4. Assign this next step to a team member along with a due date followed by regular checkpoints on progress.

Close 

Review all the above steps and do not forge to monitor this during scrum call. Typically, retrospectives should last no more than 1.5 hours for a two-week sprint.

Out comes

Few outcomes from running effective retrospective are listed below

• Higher Trust and Moral among teams and team members
• Improved capability of team
• Improved capacity of team
• Improved efficiency of team
• Improved Quality of product delivered by team

https://www.yodiz.com/blog/agile-retrospective/
https://www.youtube.com/watch?v=w8w-dFrmovQ
https://www.scrum.org/resources/what-is-a-sprint-retrospective
https://slideplayer.com/slide/6054927/

Contributions

Pavas Malviya, Scrum Master, Sapient Consulting
Amit Kumar, Scrum Master, Sapient Consulting

Scrum Master Interview Questions

When i am involved in any interview, i focus on a holistic approach.  Each answer is derived based on many factors and these factors differ from team to team and organization to organization.

#1. How do you spent your day at work as a scrum master.

#2. Given that you are in a product backlog grooming session with PO and your project will get over in next 3 iteration. however you only have one iteration of work left. Explain what does this situation mean to a scum master.

#3. A story has 5 tasks and team is done with 90% of tasks. One of the team member raises red flag on this task, as it is non-achievable. After various discussions, PO arrives at a conclusion that this story is not needed. How, you as a scrum master deal with this situation. What actions can this team takes to avoid future issues.

#4. In your Iteration Planning meeting, Team is not able to arrive to a consensus on estimation of a specific story. There are two respectable and senior members are having heated discussion over approach and over all estimates. How you as a scrum master deal with the situation.

#5. Given that you have spent 5 iteration as a team and a team is not able to scale up the velocity and there is no sign of improvement in code quality either. Your retrospectives are not able to identify the underlying problem. How you as scrum master will identify the cause of the issues and help team identify a corrective action. Explain role of scrum master in whole process.

#6. How will you ensure and motivate a team to increase various non functional requirements like unit test code coverage or efficient UI in product delivery. 

#7. What are the top 3 metrics you use in your project to report health of the project.

#8.  My organization is moving to agile and identifies Jane, a Technical Manager as a scrum master. Based on the organization structure she is also responsible for rating team members and Jane is responsible for delivering a robust architecture. Few team members report to Jane. Jane is an ace developer and passionate about technology.

Explain, how Jane can effectively perform her roles and responsibility as scrum master. 


#9. Why stories are estimated in Fibonacci, what is so special in this series. Can we use some other series of set of numbers?

#10. Explain different kind of estimation techniques used in agile?

#11. What are top three things which you should validate before a story is moved to an iteration?

#12. What are the components of DOR in your project?

#13. What are the components of DOD in your project?

#14. How to perform a release plan in agile for long project when you do not have historical background of team velocity?


#15. How do you coach/mentor a PO when they are coming from NON agile mind set. How do you coach them to align them self with agile?

#16. How do you perform Agile retrospective with your teams?

#17. What will you do when middle of the iteration you identify that a story is either over estimated or underestimated?

#18. What are Scrum Values

#19, What are scrum ceremonies and output of each one of them

#20. Define Agile?

Trust and Communication at work place

My three problems are solved by Trust and Communication

Why are we talking about trust?

Trust is only factor which binds humans as well as animals together.   To achieve your defined success in an environment, it is important to build trust. In this article I’ll share my encounter with “Trust”.

Why are we talking about communication?
If we have a trust, it has to be communicated with team. Your trust in your team has to be visible from your actions.

Trust and Communication solved my below three issues.

1. Your team member does not deliver what is expected (Time, Quality, and Scope)
My take:
a. Gather thoughts from team member before allocating assignment or commitment on an end date.
b. Get team's inputs (ideally team should come up with Time, Quality, Scope metrics ), trust their inputs and communicate them the adjusted estimates and delivery timelines.
Outcome:Your team will have commitment to a delivery and you do not have to run around and follow-up.

2. You are contradicted in a team meeting by one or two members of your team
My take:
a. Teams should always know what is being presented in a meeting (especially during: Iteration review and Retrospective). Which will mean that a brainstorming is already done before we present ideas or facts in iteration or retrospective meetings.
b. Highlight views as “team views” and not your own. Stop taking credit of your team work.
c. Do not break a news/ideas in a team meeting, no one like surprises. Always have a conversation with key stakeholders before hand.
Outcome:Your meeting will have fewer roadblocks from your own internal stakeholders. Increased confidence in meetings/workshops or fusions.

3. Team member misrepresent a status of task assigned
My take:
a. Gather thoughts from team on definition of “Done”, communicate this to all members and trust when status is reported.
b. Gather inputs on “how as a team we gather status of task”. Formalize the process and communicate. Re look and adjust the process as we progress.
Outcome:Get near agreed status on assigned tasks and deliverable.
     

Feel free to add details and comment!

Daily Team meeting challenges

Daily Team  meeting challenges [Morning meetings, Stand up meeting, SCRUM, Status Meeting, Check points]

In this article meeting refers to every day team connect, you might be calling them differently (Morning meetings, Stand up meeting, SCRUM, Status Meeting, Check points...)

This article have references from
a. Best practices defined by Scrumalliance.
b. Techniques and Strategies implemented by me and few of my colleagues and friends .

Lot of gyan is available online and I am adding to what is useful to me.

World is global now!

World is global now! Be it Software application development, Digital Infrastructure, Manufacturing, Sports, Education or Tourism. Many of our colleagues, partners, and vendors are situated either few miles or thousands of miles away. This global environment adds to the existing challenges of our daily team meetings

Challenges in meetings

Daily meeting play’s an important role in every day activity. Let me jot down practical issues and approach to resolve them. This list is a running list, feel free to add on the details in comments section and we can add them in here.

Your reason for every day issue can be with in this wagon wheel or it can be outside.  

#1. Infection 1: Silent Meetings - one or more team members do not report correct status

a. Team member need a COACHING and a MENTOR.

b. Sense of OWNERSHIP and ACCOUNTABILITY has to be developed.

c. Re access interest level in assignment/project/work and take corrective action

# Infection 2: A leader in my team meeting, One person provides an update for all other team members

Drug Composition 

a. This person has to shut up and let others speak. Enforce RULES and power of AUTHORITY.

# Infection: 3: A team member hesitates to speak up in meetings

Drug Composition 

a. This team member needs a COACHING and a MENTOR. 

# Infection 4: Not able to understand virtual team member(s) BODY LANGUAGE

Drug Composition 

a. TRUST is the key, believe in the answer of  team member(s)

b. Use video tools like Skype, Movi, Lyncs and other video conferencing tools

c.  Cultivate a habit of providing and getting a   Loud and clear updates (ask to repeat an answer or comments if not heard properly) 

# Infection 5: Daily Meetings do not START on time

Drug Composition 

a. Agreement from WHOLE team on the date, time and venue of the meeting.

b. A sense of ownership and responsibility has to be cultivated.

c. Provide flexibility to join the meeting (Mode of attendance – Audio, Physical or Audio- Video).

d. Respect personal time and have an appropriate meeting time (based on geographical location).

#Infection 6:  Daily Meeting do not FINISH on time

Drug Composition 

a. Topics and announcement should be published in advance. Utilize collaborative tools like JIRA, Google excel sheets, Shared Excel, SharePoint, etc...

b. New topics and announcements should be taken care either in next meeting or after daily morning meetings (schedule a separate meeting with only required team members).

c.  Implement scrum meeting guidelines. Answer the below listed 3Q

                 Q1. What did you accomplish since the last meeting?

                 Q2. What are you working on until the next meeting?

                 Q3. What is getting in your way or keeping you from doing your job?

#Infection 7: Multiple speakers suggesting a solution after a team member's status of the day

Drug Composition 

a.  Raise a STOP flag, solutions and participants to meet after daily meetings

b. Implement a RULE - One person speaks at a TIME

#Infection 8: Have to spend long hours to send Meeting Notes

Drug Composition

a.  No meeting notes for daily team meetings

b. Update of task and activities are done during the meeting on an online tools like Kanban board, JIRA, Excel sheet with task

#Infection 9:  Meeting time postponed at 11th hour

Drug Composition

a.  Big No. All should meet same time, same place and using same mode of communication. This cultivates indiscipline. If host is unavailable they should make sure some one else moderate a meeting.

Special Thanks to

Shravani  Srikonda, Lead Consultant for Commodity markets with a leading services provider

Sarat K Singh, Manager  Engineering with leading Entertainment and Communication industry