The Tangram Challenge: An Agile Workshop

It is difficult to conduct team building exercises that demonstrate the effectiveness of Scrum in virtual teams. Now that the ‘new norm’ is set, it is very hard to conduct team building exercises with your scrum team. Most, if not all, require face to face physical interaction like the Agile Paper Airplane Game, Lego for Scrum Games, and Agile Battleships.

After teaching my kid her math tangram exercises, I thought that the tangram could be a great Scrum Team-building exercise. A Tangram is a Chinese geometric puzzle consisting of a square cut into seven pieces that can be arranged to make various other figures.

Left Photo: Tangram Pieces, Right Photo: Tangram figure

Tangram Exercise Goal:

A tangram demonstrates the power of time-boxing and teamwork in a fun way. You are required to build as many figures from the given tangram blocks in a certain time, for example, five minutes.

Sprinting : Run the exercise in 2 to 3 sprints. What I did is to give my teammates the following time-boxes:

1. Give 3 minutes for Sprint Planning
2. Give 5 minutes for Execution
3. Give 3 minutes for Retrospective

Rules of the Game:

1. The tangram pieces are to be evenly distributed among the participants.
2. Each participant can only move their own pieces.
3. Participants should be able to create multiple figures out of their own pieces before being able to build the next figure.
4. The facilitator should have a different set of patterns for each sprint.
5. The facilitator should only share the patterns during execution to avoid the team building the patterns ahead of time.

Materials Needed:

1. Shared virtual whiteboard: I use Miro – board for virtual exercises. As the facilitator, you need to prepare the shapes on the board for the team members to move around in order to create a figure, like a cat. You may need to teach the users how to navigate the virtual whiteboard. Teach them how to move, rotate, and duplicate the shapes.
2. Set your tangram figures: a simple google search will show several figures that the facilitator can share and the participants can follow. Sample figures are shown below:

The above patterns are from freepatternsarea.com

Debrief the participants after the exercise

• Talk about what made them improve over the sprints.
• Talk about how waterfall may be different from what they have done.
• Talk about what would have happened if the time box was not there.

Best of luck! Enjoy playing the game.

Please share your experiences with this tangram method in the comments below.

-agile pinoy

Conducting a Sprint Review Survey

At the end of each sprint, I make it a point to capture the feedback of the stakeholders on the product increment and the demo presentation. This is a great insight for the development team in the succeeding sprints. It can be used as a KPI for the team to monitor regularly.

To do this efficiently, I make use of available online forms services such as Google Forms and Microsoft Forms. Make the survey easy to fill-up. The survey should be answerable in 2 to 3 minutes with up to 5 questions.

See the sample questions below:

Sample Sprint Review Survey

To track the progress overtime, I use a spider or radar chart:

Sprint Review Survey Results Over several sprints

As usual, I provide free templates! Download the template for the Sprint Review Demo Survey Graph below.

Sprint Review Survey Radar ChartDownload

Please do share some questions you may ask your stakeholders during a sprint review in the comments below.

– Agile Pinoy

Paying Your Consultants

Following from Contracting Consultants? article, it’s now time to pay their services. A consultant can be paid on a per hour basis or on a per deliverable based on agreed upon price.

The consultant should issue an invoice or a billing statement. According to Wikipedia, an Invoice, a bill or tab is a commercial document issued by a seller to a buyer, relating to a sale transaction and indicating the products, quantities, and agreed prices for products or services the seller had provided the buyer. Payment terms are usually stated on the invoice.

As usual, I give free stuff, download the INVOICE template below.

Template: Consultant InvoiceDownload

In order to bill properly, there should be visibility on how effort are measured and the equivalent output. There are several online services, to measure the time spent by consultants on each activity. We use Clockify.me 100% free time clocking software. I find it very useful to integrate time tracking with a backlog management tool. For Jira users, try Time Doctor.

After receiving the invoice from the consultant, the company will issue a Payment Voucher. According to business dictionary, a payment voucher, is a document which can be used as proof that a monetary transaction has occurred between two parties. In business, a payment voucher can be used for a variety of purposes, sometimes taking the place of cash in a transaction, acting as a receipt, or indicating that an invoice has been approved for payment.

As usual, I give free stuff, download the Payment Voucher template below.

Template: Payment VoucherDownload

In the Philippines, the company contracting the consultant withholds tax based on graduated tax rates of 5% to 32%. For simplicity, the company can withhold 10% of the consulting fee and let the consultant consolidate the taxes during their yearly filing. The company provides BIR Form No. 2307 that the consultant can submit when filing taxes.

For the company, it is very important to get acknowledgement receipt of the payment voucher by signing the payment voucher.

– Agile Pinoy

It is important for your startup business to be compliant with BIR and other regulatory requirements. Contact sales@singlesprintsolutions.com for our accounting services and business registration requirements. Visit www.singlesprintsolutions.com for other services.

Contracting Consultants?

In a project, we won’t have all the necessary expertise to get the job done efficiently. It is sometimes more cost-effective to get external help from individual consultants. It is also a good idea to onboard part-timers on a project-based or time-based engagements to help out on those peak moments.
To formalize the engagement a contract is required.

I made a contract recently with a software developer to help me in a project. I am posting the template here in case you ever get to need one.

You don’t need to develop everything. Outsourcing and subcontracting can be a better alternative.

Here is the TEMPLATE for Consulting Agreement.

Enjoy and stay safe!

—-

Are you a consultant looking for opportunities or are you in need of Software Development Specialists to help you with your needs? Contact sales@singlesprintsolutions.com and let’s develop together.

Everything Retrospective Check-in

Retrospectives can be monotonous and ceremonial. It is crucial for the Scrum Master to change and mix the format once in a while so members can look forward to the next retrospective.

In this article, I will write about all the CHECK-IN Activities that I know and use. Check-in s a good way to start a Retrospective. It warms up the participants to discuss openly.

Check-in activities are a way to gather how participants feel about the meeting and the previous sprint. It is an opportunity for the team to get to know each other better and it can influence the tone of the retrospective discussion. Check-ins are conversation starters for the group.

I am very grateful to the Scrum Masters who have shared their knowledge and experience on check-ins.

Retrospective Check-in Activities/Questions

• Teammate Appreciation: share who among the team you are grateful for in the sprint. Write a thank-you note to them.
• One-Word: describe in one word, what you currently feel
• Gift-Giving: What present will you give to each member of the team? This will show how well you know each team member. It also a venue for the team to get to know each of the members.
• Expressing Admiration: Tell a teammate what you admire about him/her. The 1st person expresses admiration to the second person until the last person expresses admiration to the first person.
• Superpower: What is your superpower that no one in the team knows about?
• Superhero: What is the most heroic thing you have ever done?
• Personal Wishes/Preferences Questions/Personal Facts
  • If you are going on a vacation, where would you go and why?
  • What is your favorite dessert?
  • What is your favorite quote?
  • What would you do if you win the lottery?
  • Who do you admire and why?
  • If you could pick up a new skill, what would it be?
  • What are you reading now?
  • What was the first thing you bought with your first salary?
  • If you wake tomorrow as an animal, what would it be and why?
  • What is your favorite color and what does it make you feel?
  • Are you sunrise, daylight, twilight or night? Why did you pick that time of the day?
  • What item that you don’t have now and would like to own?
  • Two truths and one lie: each person to tell 3 facts. The selected member will determine which one is a lie.
• Draw the Sprint: each member to illustrate how the sprint went. This can be a drawing per person or the team will share the whole whiteboard.
• Sprint Metaphor – describe the sprint as
  • Food (Fruit/Drink/Dish) and why
  • Car (Model or type) and why
  • Animal and why
  • Season (Sprint, Summer, Autumn, Winter) and why
• Rate the sprint: Rate the sprint from 1 to 5 (5 being the highest) and explain why
• Setting Expectations: What is your goal for this retrospective? What do you want out of this meeting?
• Safety check: how safe you feel in this retrospective in terms of sharing your ideas. 5 being most open and 1 being most restricted.
• Happiness Radar: how happy everyone is about the Process, People, and Technology
• ESVP: determine the engagement of participants in the meeting and guide the discussion for the team to be more of an explorer or shopper
  • Explorer: Are eager to discover new ideas and insights. They want to learn everything they can about the iteration/release/project.
  • Shopper: Will look over all the available information and will be happy to go home with one useful new idea.
  • Vacationer: Aren’t interested in the work of the retrospective, but are happy to be away from the daily grind.
  • Prisoners – feel that they’ve been forced to attend and would rather be doing something else.

As always, I will update the list when new things come up. Please do share your Check-in questions and activities in the comments below.

– agilepinoy

Benchmarking your IT Service Management

As a Software Developer, I did not have a complete view of how my piece of code can provide value to its users. After every successful sprint, I move on to develop new functionality. I always thought that software development takes up the majority of activities in developing and operating software products.

When I moved to IT Service Delivery, it donned on me that creating the software is just a piece of a bigger whole of IT Service Management. Creating software is just the beginning, operating and maintaining the software is a different challenge altogether. A software product may have great and cool functionality but may fail on its promise when deployed to its intended environment. All sorts of problems may occur when deploying software into production,

• The system slows down, it does not have enough capacity to service the volume of transactions
• The application does not function properly for certain users due to incompatibilities with other systems such as the user’s browser
• Fails to connect to other 3rd party services
• Previous functionality fails after an update
• Long downtime to fix an issue
• Attackers are exploiting vulnerabilities in the system
• Downtime, downtime and more downtime

To avoid sleepless release and deployment milestone dates, the team (the organization) should establish the processes and the discipline for effective IT Service Delivery. Benchmarking with industry practices is a great start. I included in this article a gap analysis checklist that I use whenever our company plans to engage in IT services or for auditing existing services. It is very useful for assessing the risks of the engagement and to identify opportunities to increase our scope of work.

How to use this checklist:

1. When you already have an existing service, start with Incident Management, Release Management, and Change Control processes. These are critical processes for your IT Operation.
2. Work on Risk Management, Service Continuity Management, and Monitoring and Event Management.
3. Then continue with the processes where your team or organization is weak at.

Evaluate each process, identify gaps, and create workable action plans to fill the gap. Always work on those high impact but easy to improve items. This is to build momentum on your journey towards excellent IT Service Delivery.

Download: ServiceManagementChecklist(ITILv4) – Gap Analysis Check

If you need help in assessing your team and coming up with a workable improvement roadmap, please don’t hesitate to contact me – agile.pinoy@gmail.com

– Agile Pinoy

DevOps Journey: Analyzing the impact of Components to Services (CFIA)

To ensure maximum uptime of services, there is a need to identify the components, resources, and configurations that enable the smooth operation of the service. IT systems and their configurations are growing in complexity as more services, components, and people are added into the mix.

To map out the relationships of services to other services or components, I use the Component Failure Impact Analysis (CFIA) matrix. In the event that a particular component (or configuration item) should fail, the CFIA Matrix helps me determine the potential impact on service delivery.

CFIA is a visual tabular view of services and their component items. It is part of a proactive Availability Management process. With this visual matrix, the IT decision makers of your organization can optimize the capability and capacity of the IT Infrastructure and resources. It can also identify high-risk components where the failure of those components will impact many inter-dependent services. It is a useful tool to justify upgrade or purchase of IT components.

How do you start with CFIA?

Given a service, identify the components that the service is dependent on. Determine the impact of your IT components on the service based on your pre-defined levels. Impact level can be 1) DOWNTIME(X), 2) WARNING(O) where the service is still operational but with reduced capability, or 3) NO IMPACT(Blank Space). Start with the basic services, then build up the list as you identify more components, services, and resources.

With the above illustration, it is easier to determine the relationships of the services, components, and resources.

Visit our download page to get a copy of the CFIA (Component Failure Impact Analysis) Matrix Template.

– agilepinoy

DevOps Journey: Service Monitoring – Learning from Service Failures

Coming from a Development background, there are several concepts that you need to learn in your journey to become a DevOps engineer. You need to be familiar with the operation side of things.

Being Developers, you are more concerned with ensuring your code works according to the acceptance criteria and the definition of done.

In ITIL, the set of features and functionality are called UTILITY.
— UTILITY: Fit to purpose, or utility, means that service must fulfill the customer needs. It is summarized as what the system does.

The value of your software won’t be realized until it is ‘Fit for Use’.

In ITIL, the set of qualities that define ‘Fit for Use’ are called WARRANTY. In Operation side of things, IT Operators are not only concerned with UTILITY but also WARRANTY.
— WARRANTY: Fit for Use is a promise or guarantee that a product or a service will meet its agreed purpose by being available when needed, with enough capacity, and dependable security.

In this article, I will discuss the reliability attribute and how each service failure can serve as an opportunity to continuously increase your skill as DevOps engineer.

To maximize the up-time of your services and keep disruptions to a minimum, reliability metrics (failure metrics) should be tracked. Tracking the reliability of services is a challenge when you do not have automated CMMS (Computerized Maintenance Management Systems). I provided a simple excel tracking template to track the services you deployed. (see Download Page: look for Service Monitoring-Sheet for IT Managers/DevOps).

As soon as your software is deployed to production, you will encounter several error conditions that are not in your test matrix!
Deployment issues, that are rarely considered by developers with minimal delivery experience, will occur. Best to track these to continuously improve on the reliability of your services.

Availability and Reliability Metrics

In general, we speak of availability in terms of “nines.”
– Two nines, 99%, allows 3.65 days of downtime per year (100%-99%)*365
– Three nines, 99.9% is about 8 hours of downtime
– Four nines, 99.99% is about 53 minutes of downtime
– Five nines, 99.999% is about 5 minutes of downtime, <– Our BHAG (Big Hairy Audacious Goal)

Downtime is measured from the time of failure until the system is back in operating condition.
<In the given template, this is ‘Monitoring’ Sheet Availability Column.>

In order to increase reliability, failure metrics should be tracked and monitored as well. The common service/device failure metrics are MTTR, MTBF, and MTTF.

1. Mean Time to Recover (Average Downtime)

• FORMULA: MTTR(Recover) = Total Downtime / Number of Failures
• It is the goal of IT operators to quickly recover from downtime
• Mean Time to Recover is from the time when the failure occurs until the service resumes operations

<In the given template, this is ‘Monitoring’ Average Downtime Column>

2. MTTR (Mean Time to Repair – the average time to repair the system)

• FORMULA: MTTR(repair) = Total Repair Time / Number of Failures
• It is the goal of IT operators to repair systems at the quickest possible time with minimum cost
• Mean Time to Repair includes the following time: Repair Time, Testing Period until Return to Normal Operation
• It does not include point of failure and diagnostics
  <In the given template, this is ‘Monitoring’ MTTR Column>
• For each downtime, log an incident list to indicate Downtime, Time To Repair and Manhours to Repair
  <In the given template, this is ‘Incident-List’ sheet.>

3. MTBF (Mean Time Before Failure)

• FORMULA: MTBF = Total Operation time/number of failures
• The goal is to have longer operation hours before failure occurs through effective preventive maintenance
• Mean Time Before Failure does not account times when servers are down for maintenance
• It is the average time between failures

<In the given template, this is ‘Monitoring’ MTBR.>

4. MTTF (Mean Time to Failure)

• These are for measuring the reliability of equipment that is not repairable. Example of these are light bulbs, memory modules
• Simply put, this is a measure of the lifespan of a device (Device Starts working -> Device Failure Occurs)
• FORMULA: MTTF = Sum of all units hours of operation / total number of units
• This metric, although not included in the template, is useful when the operators need to estimate how long a component would last as part of a larger piece of equipment that they maintain

Logging the above metrics with historical information on how each incident occur, their root cause, corrective actions, and preventive actions will continuously improve the reliability of your systems. While this article is mainly learning from your past incidents, it is recommended that you build reliable systems upfront through resilient architecture using a fully reliable infrastructure.

– Agile Pinoy

Requirement’s Journey: Illustrated

As a supplement to Scrum Exoskeleton from scrum.org,

I use the illustration below to map the journey of a requirement from their sources to their deployed form. My teams use this to describe the flow of value and to easily determine what activities they should perform to complete a requirement.

The flow of requirement to a working product passes through filters,

Filter 1: The Product Vision Test

Requirements should pass the Product Vision test before it is considered to be included in the Product Backlog

• Are the WHYs and the WHATs of the requirement clear?
• Does the requirement contribute to the product vision?
• Does it add value (benefit, risk reduction or opportunity enhancers)?

When all the answers are YES, the Product Owner will write the related Epic/ Themes to the Product backlog. Else, the requirement should be removed.

Filter 2: Definition of Ready

Before a requirement is considered for implementation, it should pass the Definition of Ready. This will vary from team to team. At the minimum it should be:

• CLEAR: everyone understands the WHAT and the WHY of the Product Backlog item
• SMALL: the product backlog item can be implemented in 1 sprint that complies with the definition of Done
• TESTABLE: acceptance criteria can be defined

The themes or epics from Filter 1 should be broken down, decomposed, and refined. I prefer user journey mapping technique to identify user stories of a given requirement. The output of this filter are READY user stories.

For more information about Product Backlog Refinement, please refer to my previous article, Everything about Product Backlog Refinement.

Filter 3: Sprint Planning

READY Product backlog items are selected for implementation during Sprint Planning. The selection will depend on its prioritization (as influenced by the Product Roadmap) and its relevance to the current sprint goal.

The User Stories are decomposed further into tasks and as a whole monitored in the Sprint Backlog.

To assert the acceptance criteria, I prefer that User Story acceptance tests are written and executed in a BDD (Behavior-Driven Development) environment. Unit testing are performed through TDD (Test-Driven Development) and executed daily through a Continuous Integration Environment.

Filter 4: Acceptance Criteria and Definition of Done

A User Story is considered to be DONE when it passes its acceptance criteria and its Definition of Done. The Development Team should not wait for the Sprint Review to validate the DONENESS of User Stories. They should ask the P.O. or her representative to confirm User Story completeness.

For more information about Definition of Done, please refer to my previous article, Everything about Definition of Done.

Filter 5: Sprint Review

During the Sprint Review, the Product Owner, from the inputs of the stakeholders decide whether the completed story should be included in the Increment or placed back to the product backlog for further enhancement.

Filter 6: Release Decision

Not all increments are immediately released for deployment. It is a business decision decided by the Product Owner.

When the Product Owner decides to release the increment (cumulative done stories including those stories not previously released), DevOps/Continuous Delivery release cycle is executed to deploy the release into production.

When the product is deployed, new requirements and defects are discovered. These requirements go through the same Journey (Funnels) .

– Agile Pinoy

What makes a great Agile Retrospective?

I asked the Agile Philippines community through the Agile Philippines Facebook Group on tips for effective and fun retrospectives the Filipino way. These are my key take aways.

1. Great retrospectives are affirmative

• Facilitators set the tone to make the retrospective a safe environment to constructively discuss improvement areas in the previous sprint
• Members find retrospectives as the safest avenues where they can share their thoughts, feelings, and observations
• Facilitators know that people do not intend to work poorly, the aim of the retrospective is to build environment for sustainable operation and growth. It is not a fault-finding nor a blame-throwing event.
• The teams can have a “round-table of gratitude”, everyone gets to thank someone in front of the team

2. Great retrospectives are celebrations

• Organizers recognize the people who contributed most for the success of the current sprint by giving out small tokens or rewards (like Golden Duck Awards)
• The team can celebrate learning through the celebration grid by categorizing learning into 3 buckets: good practices (high probability of success), mistakes (doomed to fail from the beginning but done nonetheless) and experiments (learning is the highest here)
• The team knows that regardless of what they discover, they understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

3. Great retrospectives are fun

• There are at least 32 ways on how to do fun retrospectives. See Fun Retrospective for activities and ideas for making agile retrospectives more engaging
• Retrospectives are opportunities to inspect the sprint and adapt on the next sprint. The team should discuss how to make the next Sprint more enjoyable. When retrospectives become boring and tedious, it is a retrospective point that are categorized under “what needs improvement”

4. Great retrospectives have dynamic facilitators

• Sometimes the facilitator after reiterating the rules and the games of retrospective, can just go back and see the results – self-organization in action
• Facilitators do not act like a boss directing the discussion, they act as friends, and colleagues who listen, who understand, recommend and not prescribe.
• Facilitators have Retrospective Exercise Toolbox. In their book, “Getting Value out of Agile Retrospectives: Toolbox for Retrospective Exercises”, Luis Goncalves and Ben Linders detailed out retrospective exercises and when to effectively use them.

5. Great retrospectives are team-builders

• Retrospectives are team exercises and not for general consumption so as not to hinder with openness and honesty
• Members should avoid making the retrospectives as gripe/complain sessions, people will get defensive and will hinder effective collaboration.
• Retrospectives are opportunities to break barriers to effective sharing
• Retrospectives facilitate self-organization, the team can try to do other methods in the next sprint, they are the ones to correct their own processes. The team takes control of their own Agile improvement JOURNEY. There is a high buy in the improvement effort.

As an end note from the experienced members of the group, we must remember that the purpose of retrospective is to learn from the past to improve the future. There are lots of game play but productivity may get lost in the fun and the games will distract the members from purpose. Great retrospectives are deliberate and intentional.

Thank you Agile Philippines!