Agile in 2 minutes
 

 

Agile software development framework refers to the time-boxed, continuous iteration of development, and testing to build software where the solutions evolve throughout with incremental development via collaboration among self-organizing teams. Agile helps organizations to expertise and respond to continuous change resulting in continuous improvement.

As shown in the above diagram, the vision and feasibility are the most important factors to be considered before starting a project.  In this phase,

  • We identify whether we should consider doing a project or not
  • What is going to be ROI (Return of investments) for a project?
  • How do we get funding?
  • Is it worth taking risks? Staffing?
  • what is the value the project brings in?

You use this phase to break the idea into individual functionality items called features or user stories.  If this looks positive, the next step is to create a product roadmap document.

The product backlog is created by leveraging the product roadmap document. The release planning results in a release backlog. The individual sprints are defined to accomplish upcoming release goals. The Agile Roadmap blog defines the entire project in more detail.

The sprint ceremonies are listed as

The sprint roles are (The details are listed in Scrum Roles and Responsibilities blog)

  • Product Owner
  • Team member
  • Scrum Master

The core sprint artifacts are

  • Burndown and Burn-up chart
  • Sprint Backlog
  • Product Backlog
  • Increment
Sad Mad and Glad Retrospective – A powerful team retrospective tool
 


One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges or too busy to do other things that they don’t have time to focus on employee morale. There are obviously pros and cons but making it work truly helps you to achieve more. In my personal opinion, the number of positives what you have with this retrospective is far higher than challenges hence it’s worth doing it.

Prerequisites :-

  • Your team and your presence
  • Sticky notes (Three colors)
  • Enough Pens
  • Open minded motivated teams

In this retrospective, you ask your team to get into a room.  Every colored sticky note represents Sad/Mad or Glad respectively.  You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!

You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!

You can start your meeting with a positive note. Ask individuals to participate freely and openly. Once the stage is all set, you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad) on different color sticky notes. I always recommend individual team members to write their names on each sticky note else there are good chances that it would become a political battle. You should always give an option to do go with anonymous though.

I have seen instances where team members just write some crap either because they did not have good appraisal last time or not in line with others due to personal issues. If you find an item which has something written in sad or mad while an individual who wrote it is not willing to even talk about it then you can very much assume either that’s fake or written with the wrong intention hence discard it. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern.  Just to avoid the frustration as manager, anything written as an area of concern and individual is not willing to open up personally or with the team, you can safely scrap it.

Once everyone is done with writing, spend an hour or so reading every item and discuss that with the team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.

Things to remember while doing Sad/Mad & Glad:-

  • You should be reading every item loud or make it visible to every individual unless there is a derogatory remark which is not acceptable.
  • Team to think of the success of team and project rather considering this as revenge material.
  • Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.
  • Refrain from making comments about an individual if you don’t have supporting material. The world is not perfect. The goal is to identify the improve system over making it worse
  • BE MATURE
  • Should not be anonymous.
  • Don’t abuse it. It is conducted to the best interest of an individual and improves as a team. It should never be used as a tool to fulfill your political battle.
  • Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.
  • Don’t try to fix the problems during this retrospective.
  • Constantly read the issues/concerns raised and strive to fix as much as you can.  Provide updates to the team around the issues you committed you would work on.

The benefits I see with this retrospective are:-

  • Gives lots of motivation to the team when going over “Glad” items.
  • Give an opportunity to an employee to express their challenges.
  • Bring in open culture
  • Reduce attrition as you really know challenges and definitely a lot of which you can work on.
  • It gives 360 views in terms of how the teams are progressing.
  • One of the biggest “Glad” item I would say is that your organization is conducting it.

The challenges I see are:-

  • It may become a political battle if your team is not mature and willing to go for an anonymous survey.
  • Excessive sad mad and glad would unearth issues which are not really problems while making other team members think it’s a major problem.
  • Sometimes very happy team morale goes down as well as when you have an opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.
  • What I was written must be addressed and fixed “Myth”. You may not like the tile color in the washroom but that cannot be really changed.
PMI-Agile Certified Practitioner
 

Project Management Institute – Agile Certified Practitioner

The Agile Certified Practitioner formally recognizes your knowledge of agile principles and your skill with agile techniques. This is one of the most valued certification when it comes to Agile.

You can get all the information around this certification at

http://www.pmi.org/certifications/types/agile-acp

You must earn 21 PDUs (Professional Development Units) to be able to appear for this exam. You are expected to earn at least 30 PDU every three years in order to main the status of this certification.

PDU – One PDU can be earned with one hour of activity (training). As per the PMI “The professional development units(PDUs) are the measuring unit used to quantify approved learning and professional service activities.”

 

 

What is “Pair Programming”? Is it worth doing it?
 

Pair programming is an agile software development technique in which two programmers work together at one workstation and share the same keyboard. One person (Driver) writes the code while the other person (Navigator) reviews it and at the same time thinks about the big picture. If you want your partner to expand their knowledge in programming, you can even give them one of those gifts for coders.

How to do it right

  • Understand the requirement well before you start. Spend few minutes and discuss with each other.
  • Agree on one small goal at a time.
  • Support each other
    • If you are a driver, focus on small tasks and quickly complete it avoid bigger issues.  Trust navigator to your safety gate.
    • If you are a navigator, constantly review the code and think of a big picture. You don’t need to dictate the code.
  • Celebrate victory when the task is completed or you resolve a problem.
  • Changing roles few times in a day helps (Driver to Navigator and vice versa)

Do’s

  • Encourage pairing. Do not worry about slight productivity loss in beginning. This is something I have seen many teams when new teams are formed as they don’t have experience in the pairing.
  • Start with a trial. Do not force individuals to pair. Let them decide who wants to pair with whom.  Changing pairs constantly helps.
  • Pairing for more than six hours a day is not advisable.
  • Individuals should switch driver and navigator role when they get bored.
  • The Large monitors and good leg room are essential along with co-location which is absolutely mandatory.
  • Trust and support each other.  The team culture plays a critical role.

Benefits

  • Improves software quality without impacting time to deliver.
  • The focus and energy involved are much higher hence chances of making mistakes reduces significantly.
  • The better articulation of complexities and hidden details of coding tasks reduces the human errors.
  • The requirement elaboration and definition of done usually be better understood.
  • Build trust and help individuals to be better skilled.
  • The partners can switch when frustrated or stuck. The work doesn’t get compromised. The change in responsibilities once again adds energy to work.
  • New recruits come up to speed more rapidly in a pairing environment.
  • From a developer standpoint, pairing is enjoyable and valuable activity. I have seen developers who resisted pairing the first time, eventually loved it and found it to be much really useful in terms of learning, more engagement, better quality and successful careers.

Challenges

  • It’s social skill and it takes a time to do it. The best pair programmers exactly know when to say let’s try your idea first. Do not expect the outcome of pair programming from day one. It takes some time to do it in right way.
  • No benefits are expected if both the programmers are not actively engaging themselves. It’s “programming it loud’ methodology” hence it is essential that the driver and navigator constantly communicating. The silence kills the benefits of pairing.
  • If the two people have personal challenges, the pairing cannot be forced upon. The trust and mutual understanding between the two people is absolutely necessary
  • Experience mismatch is another bigger challenge. The senior programmers often want to have more control and give a little room to junior programmers.
  • View pairing as one person watching, the other person doing the actual work. That becomes boring and disengages the person watching, eliminating any real benefit from this practice.
  • Pairing should be avoided for very simple tasks or tasks which are very clear and can be done in little time.
  • Pairing needs to be done by two. The moment the third person added to it,  it cannot be called pairing anymore.
  • The co-location is absolutely mandatory. The absence of co-location where the work is shared between two programmers is called sharing over pairing.
  • Force the pairs or identify them ahead of time which may not be right in many scenarios. The best approach is to let the pairs form and swap by their own.

Myths

  • The pair programming is mentoring while it should never be. Programmers often pair with somebody with the goal to learn technology and domain. That is called either mentoring or knowledge transfer. This should be treated as a knowledge transition and expecting less than one person productivity is a fair expectation.
  • Two people working on the same story but different tasks individually is considered pairing while IT IS NOT! It is sharing the work but not pairing.
  • I have often seen individuals complete half the task and hand that over to another team member in the evening sitting in a different country and assume that it’s pairing. This is again the sharing of work and comes with an extra cost due to unknowns, handoff, and understanding each other’s work.
  • Doing agile requires pair programming. The reality is Agile manifesto never talks about pair programming.
  • The initial resistance of programmers that pairing is not the right thing to do. Most programmers like it when they try it.  Others don’t do it right and start believing it’s a waste.
  • The pairing would reduce productivity to half. This is one of the most debated topics.  I have personally experienced that when it is done in the right way, it improves the overall productivity of more than two people working individually.
What is an Agile Roadmap? What happens before sprint starts?
 

The agile roadmap is often confused with product roadmap or scrum ceremonies. The agile roadmap is indeed much beyond that. If it is not just the scrum activities then the question arises in terms of what is agile roadmap all about?  How important is it to know what happens before sprint planning? For most of us, sprint planning is the beginning of agile project while it is not (Practically it can be considered as mid-stage). A lot happen before ‘sprint’ ceremonies.   The agile roadmap would probably answer the entire process that is being followed to accomplish the project.

At a very abstract level, the agile roadmap has 7 phases listed as below:-

Vision

  • Product Owners in conjunction with senior leadership identifies the product vision.
  • The product vision talks about – What your product is, and what it entails? How it would support your company or organization strategy and who is going to consume it.

There are many more factors being considered here including the market, complexity, feasibility etc. Typically in this phase there is little or no involvement for the core development team.

Best practices

  • Touch base with your management and be updated with the vision of the product.
  • Provide inputs whenever applicable.

Product Roadmap

  • This phase defines high level of product requirements which are written at high level (EPICs).
  • Typically the EPICs are elaboration to have clarity while the stories may or may not be written.
  • The prioritization of EPICs happen as well in this phase.
  • The discussion between product owner and other stakeholders enable PO to define
    • High level estimates (Probably ROM -> +/- 30%).
    • Priorities

Best practices

  • Try to get involved in roadmap discussions.
  • Stay in touch with product management and ensure you know whats coming. What the organization goal is and what can we do to ensure we meet it.
  • Provide as much inputs as possible to product management to ensure the EPICs are well elaborated and understood.

Release Planning

  • The EPICs are further broken down into individual stories.
  • An agile project will have multiple releases with the highest priority features being picked up in order.
  • During this phase release timing for the specific product is determined.
  • The release plan must have to be created at the beginning of the project.
  • The number of sprints, team staffing and capacity is being looked at as well.
  • The estimation here is going to be +/- 10%. This is very important as the exact cost/schedule of the product/project is determined at the phase.

Best Practices

  • Every agile team must put in efforts to get involved in this phase.  The solid understanding in this phase is core to success of the product/project.
  • Identify impediments and provide inputs for estimation.

Sprint Planning/Grooming

  • The sprint team works with PO to groom the requirements based on priority.
  • Technical and product dependencies are discussed.
  • Individual tasks are created for each requirement. The next level of estimates are created (+/- 20%). Planning poker, relative estimate, and WBD are quite commonly used to provide an estimation. Based on the maturity or project and organization in the specific area, complexity based estimation can be utilized as well.
  • The team gives commitment by looking at the capacity and next level of estimates.

Please click here to get more details

Best practices

  • If the requirements are clearly stated or acceptance criteria is not written ask PO to do the same.
  • The grooming should be a constant activity and should be done for most of the stories prior to sprint start date.
  • The goal of the planning is to ensure everyone is aligned with details for each story, estimation and sprint commitment.  The planning can be done a day before sprint start date or on sprint start date.
  • The sprint commitment, assumptions and high level discussions should be sent to whole team.
  • The previous sprint must be closed before the next sprint start date. In addition to that the summary of the previous sprint to be sent to all the team members.
  • There should be a goal of N+2 sprint readiness which is to ensure that 2 sprint worth of work is groomed in advanced.
  • Make use of capacity planner for sprint commitment.

Daily Stand-ups

  • It should get completed in less than 10 minutes.
  • This meeting should answer
    • What did you do yesterday?
    • What are you going to do today?
    • Any impediment? If yes, then what is that?
  • Please note that standup meetings are not planning or technical discussion meetings. These are neither meant for micromanagement nor a meeting to provide a status.

Please click here to get more details

Best Practices

  • The standup should be time-bound. It should get completed in 10 minutes for less for 10 member team.
  • Any design or technical discussion should happen post standup. Not everyone needs to participate unless absolute necessary.
  • The standup should happen in morning. If there is a dependency with onshore counterpart, it should happen twice in a day.

Sprint Demo

  • This is essentially the demonstration of the working product (or “showcase”). This should happen post QA or peer testing.

Please click here to get more details

Best practices

  • This is a continuous activity and should be done as and when the story is done-done.
  • No story should be mark done without a demo. In case if the PO is not available, you should give the demo to rest of the team, record the session and share with a PO.

Retrospective

  • This happens at the end of the sprint. All the stakeholders sit together and discuss
    • Things which worked well
    • Areas for Improvement or things which we should stop doing it
    • Action Items
  • This meeting should also look at the action items of the previous retrospective and see where we stand. If the previous action items are not addressed, those should be included in current retrospective.

Please click here to get more details

Best practices

  • The retro must happen after every sprint. The retro should begin with action items of previous sprint.
  • There should be owner for each action item.
  • Be open. Appreciate people and discuss areas of improvement/things which did not work.

Many times the first three phases are ignored by agile teams.  The ultimate success requires or expects that the entire agile team to be well versed with first 3 phases as well. They should be part of it from day one.

Common best practices

  • Be open and honest. Support team work over individual contribution.
  • More the co-location better the outcome. Avoid working from home and silos.
  • Constantly review burn down chart to see where we stand.
  • Pick approx. 20% of tech debt in every sprint.
  • Focus on continuous improvement. That’s good for a company and for your growth.
  • Go to with pair programming wherever there is a possibility.
Perspective Designing
 

Recently, I was working with a colleague in refactoring one of our projects. As we added tests, we found few code issues and continued refactoring. Was feeling happy as our unit tests were rearing benefits. However, we know TDD or unit testing does not guarantee clean code. As we progressed, the naming conventions consumed a lot of our time. And eventually, it brought us to a discussion about why specific naming conventions can create a better design. Thought I will share our discussions and practices here.

While we design classes for application, we often think of it as a different subject than ourselves (programmer). When I say different subject, we think of it as a different object and not as a person. When a programmer considers classes/interfaces as personalities and thinks from the perspective of the class, design can change drastically. This is what we call “Perspective designing”. Let’s take an Example:

    public interface ITotalTaxCalculator
    {
        decimal Calculate(IEnumerable products);
    }

    public class TotalTaxCalculator : ITotalTaxCalculator
    {
        public decimal Calculate(IEnumerable products)
        {
            decimal total = 0.0;
            //add total of products etc....
            foreach (var product in products)
        	{
                using(var dbContext = new ProductContext())
                {
                    var productInDb = dbContext.FistOrDefault(prod => prod.Id == product.Id)
                    total += (total * productInDb.taxRate);
                }
        	}
            return total;
        }
    }

In the above example, the name of the class and interface are perfectly fine. But they are impersonal and it’s very hard to think of it as a person and bring in perspective thinking with these names. So we refactored them to ‘ICanCalculateTotalTax’ and  ‘TotalTaxMan’.

public interface ICanCalculateTotalTax
{
    decimal Calculate(IEnumerable products);
}

public class TotalTaxMan : ICanCalculatorTotalTax
{
    public decimal Calculate(IEnumerable products)
    {
        decimal total = 0.0;
        //add total of products etc....
        //blah blah blah..
        total += (total * taxRate);
        return total;
    }
}

These naming conversions have lots of inspiration from in NServiceBus for their class/Interface names. With the new class and interface names, it’s easy to think of them as personalities. However, this does not guarantee good design. So we needed refactoring. Perspective thinking comes in handy especially while we do refactoring When my colleague and I started putting ourselves in the place of each of the classes. We had very reasonable questions which triggered our object-oriented thinking.

Example1:  As ‘ICanCalculateTotalTax’ , why I am having database related behavior?

Example2: As ‘ICanCalculateTax’, why I am having logic to find which language it needs to be presented?

These questions helped us to refactor the code to follow good design principles. When we implement these interfaces/abstract classes, we have clarity on what the class is capable of doing. So we generalized these naming conventions & questioning attitude and derived below two rules to do Perspective designing (think like a class).

  • Give personality to the names of  classes/interfaces (example: ICanCalculateTax)
  • Use the Agile User Stories way of articulating what the class should and should not do. (example: As ‘ICanCalculateTax’, I should be able to provide behavior to calculate tax)

I think, “Perspective designing” can make classes more object-oriented and best practice like SOLID principles automatically fall in line. Let me know your thoughts.