Category Archives: Strategy

Scrum Team Rituals

Posted on by

Refinement
Purpose: Detail a Userstory into all that needs to be done to deliver its expected value
Time Spent 4 hrs for 2 week sprint(Includes planning)
Who Needs to attend Devops Team, PO
Optional Scrum Master

Qualities

  1. Open conversation to gather all info needed
  2. Shared Decision on task and planning
  3. Shared decision on estimation

Activities

  1. PO explains the why and what of the user stories
  2. Team defines how to build and deliver these stories
    • Identify prerequsites, dependencies and risks
    • Identify Tasks
    • Identify flow of task and planning
    • Change/Update the definition of done
  3. Team plays the planning Poker, estimates the relative amount of work in a user story

Outcome

  1. Identified Obstacles
  2. Detailed user stories that make the sprint plan
  3. Estimated user stories, ready for sprint planning

Planning
Purpose Define a sprint goal and make a plan to deliver it
Time Spent 4Hrs in 2 weeks sprint(Includes Refinement)
Who Needs to attend PO, Scrum Master, Team(Developers, Testers, Devops)
Optional NA

Qualities

  1. Commitment on sprint backlogs
  2. Clear priorities and sprint goal
  3. Shared knowledge about the sprint plan – how to deliver the stories and reach the goal

Activities

  1. Define what can be done next sprint
    • Product Owner and team set the sprint goal
    • Commit to capacity and velocity for next sprint
    • Devops team selects refined and estimated stories from the sprint backlog
  2. Define how it can be done
    • Finalize the plan to build the stories and deliver the sprint goal
    • Assign stories/tasks
    • If needed adjust the sprint backlog
    • Commit to the sprint backlog and start

Outcome

  1. Shared decision on tasks and planning
  2. Sprint goal, Sprint plan and Sprint backlog

Standup
Purpose Align activities and plan the upcoming day
Time Spent 15 min/day
Who Needs to attend Devops Team, Scrum Master
Optional PO

Qualities

  1. Focus on sprint goal
  2. Enhanced communication and collabration
  3. Fast Decision making
  4. Identified obstacles and impediments

Activities

  1. Team reports progress to each other(not to scrum master) by answering 3 questions per person
    • What did you finish yesterday?
    • What will you work on today?
    • What obstacles are in your way and do you have a help question for the team?
  2. Measuring progress towards deliverable’s
  3. Define the impediments that are outside our team’s influence and ask scrum master to help, solve and escalate those.

Outcome

  1. Updated Scrum board
  2. Updated impediment List

Review
Purpose Inspect the delivered value/items in last sprint and adapt the backlog with feedback from stakeholders
Time Spent 2 hrs for 2 week sprint
Who Needs to attend Devops team, Product owner, Scrummaster, Stakeholders
Optional NA

Qualities

  1. Focus on delivered value
  2. Done is Done(or not)
  3. Open conversation about work delivered and expectations
  4. Updated Backlog

Activities

  1. Devops team shows work being done
  2. Devops team tells how they managed difficulties
  3. Stakeholders ask questions and give feedback
  4. Productowner accepts work being done or pushes back to backlog
  5. Product owner updates and re-prioritizes the backlog
  6. Scrummaster and team share common understanding of last metrics(Burndown, velocity and happiness)

Outcome

  1. Updated Metrics
  2. Updated backlog
  3. Closed Sprint

Retrospective
Purpose Inspect what went well during sprint and adapt what can be improved
Time Spent 1.5 hrs for 2 week sprint
Who Needs to attend Team, Scrum master(Mandatory)
Optional PO

Qualities

  1. Open dialogue and all voices to be hear
  2. Focus on continuous improvement
  3. Collects facts and generate insights
  4. Move forward

Activities

  1. Set the context for safety – Share purpose and structure of the meeting
  2. Evaluate the last agreements and actions taken
  3. Gather new input on what went well and what to improve
  4. Prioritize improvements
  5. Detail the top 3 actions for next sprint

Outcome

  1. Maximum 3 actionable improvements for new sprint

Frequently Asked Questions

  1. What are basic things to be taken into consideration while taking a story for refinement (or) how you will consider a story to be Ready for refinement (or) Refinement DOR
    1. The priority of story should have been decided
    2. Supporting documents(Use case documents and confluence) for the story should be available
    3. Requirement and scope of the story should have been well defined
    4. Walk through should have been done by business analyst or product owner stating how the changed version of software product should behave and look like.
    5. Dependencies with other team would have been sorted
    6. Implementation and timeline details should be well defined
  2. What are basic things to be taken into consideration when you tell a story is done with refinement (or) (or) Refinement DOD
    1. Checklist of things that needs to be done should be added
    2. The story should have been pokered(1,2,3,5,8)
    3. All the details of the story should be clearly listed
    4. Subtask should have been created
    5. Testcase design document should be ready
    6. Dependencies and impact on devOps should have been discussed
    7. Acceptance Criteria should have been listed

Innovation and Soap Factory

Posted on by

A Japanese soap factory had a problem: they sometimes shipped empty boxes, without the soap inside. This was due to the way the production line was set up, and people with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming out of it is perfect 100% of the time. Customers who come all the way to the supermarket would end up buying someone else’s product.

Understanding how important that was, the CEO of the soap factory got the top people in the company together and they decided to start a new project, in which they would hire an external engineering company to solve their empty boxes problem, as their engineering department was already too stretched to take on any extra effort.

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a soap box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

A while later, the CEO decides to have a look at the ROI of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. Very few customer complaints, and they were gaining market share. “That’s some money well spent!” – he says, before looking closely at the other statistics in the report. It turns out, the number of defects picked up by the new high precision scales was “zero” after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the high precision scales were installed. A few feet before it, there was a $ 20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.
Moral of the Story: Everyone has a “solution” sometimes requiring an expenditure of “8 million bucks”. It requires an engineer with a high spirit of innovation and ingenuity to come up with a “$ 20 – simple cost-effective solution”!

Design Thinking Take away Points

Posted on by

Design Thinking is not about problem solving. Its about making things better. Fixing a Car which got broke down is problem solving. Fixing a Car to run smoothly and fuel efficiently is Design Thinking

Key Points

  • Learn to Fail Early
  • Test your end result.Make sure you are doing the right one
  • Don’t spend too much time on Planning. Start working

Other Notable Things

  • Ask questions not with solutions which you already have in your mind
  • Questioning Basics

    • What you think about It
    • What you feel about It
    • What you do about It
  • People hesitate to tell No.So you need to change the question according to that. Eg – Petrol Bunk Story – There was high turn around in petrol bunk for special petrol when “Shall I put Special Petrol” was asked instead of asking “Sir special or normal petrol” to customer. Instead of giving option to choose from ask shall I offer that. The one which you offer is the one which you like to sell
  • Empathy – Understanding how other people feel, communicating your understanding, Apathy – a state of not caring, being unsympathetic or not empathetic, Sympathy – feelings of pity and sorrow for someone, Antipathy – Glad they have those problems
  • Convert Implicit needs to Explicit Requirements Eg – TV not clear is a Implicit need to someone and TV to be bought is a requirement to someone.Turn Implicit needs of customers to explicit needs to make it as selling point