Category: blog post

agile, blog post

Leading Successful Iterations

After the iteration / sprint planning meeting, the team gets into execution mode and they work together to build the increment of the product, that is agreed to be completed during the iteration. In the traditional terminology, you are getting into the execution mode of the iteration or sprint. (the term ‘sprint’ is specific to Scrum, where as ‘Iteration’ is the generic term that fits across all agile frameworks).

During the iteration, the following scenarios can occur repeatedly, and they will have to be managed for smooth execution of the iteration. Here are the iteration challenges and the ways to overcome them;

  • Iteration Scenario#1 – Work volunteering Vs Work allocation – Who will allocate work to the team members?. Very often this question comes from the seasoned project manager in predictive project management, who is new to Agile. The answer is, the team will decide. The backbone of true agile teams is the self organizing teams, and one of the key abilities of the self organizing teams is their ability to self organize and volunteer for work.
  • Iteration Scenario#2 – Challenges of work volunteering –
    1. If the person without the right skill set and experience volunteer for a task, then what will you do?. See, this is a speculated problem. In practice, people behave rationally only. It is very rare that, people without the confidence volunteers for a particular task. In the rare event of someone underestimating the complexity and volunteers, then others should help him to succeed. This is when pair programming, or pairing an experienced person with an inexperienced person helps.
    2. If more than one person volunteers for a task, then what happens?. Scrum master should not pitch in an switch to work allocation. Allow them to solve it by themselves.
    3. If nobody volunteers for a particular task or tasks, then what is the solution. Identify the root cause. If it is a technical difficulty, resolve it. It can be because of teaming issues as well. In that case, resolve those issues as well.
  • Iteration Scenario#3 – Deviations from the iteration plan
    1. If the team is unable to complete the tasks as planned, then what to do?. If it posing danger to the success of the sprint, identify the root causes, and then decide whether to cancel the sprint, or to continue with the sprint, after removing some scope with the consent of the product owner. If there is no hope of recovery, cancelling and re-planning the next sprint as quickly as possible is the way to go.
    2. If we cancel a sprint in between, and then start another new sprint, the number of sprints will increase, but the increase in overall effort will not be that severe because the team will be able to salvage some of the completed items from the cancelled sprint.
  • Iteration Scenario#4 – Uncontrolled scope creep – Agile welcomes changing requirements – some of the project stakeholders can latch on to this point alone and try to squeeze in requirements during the sprint without any regard or respect for the development team. Last minute changes are welcomed in scrum and at the same time, it happens with consensus among the team. In fixed capacity teams, when new requirements are included within the sprint, some other requirements with same weight (story point) must get out of the sprint.
  • Iteration Scenario#5 – If the sprint fails – If somebody has given you idea that agile is the solution to all your problems, they were lying to you. Some sprints can fail. That is very normal. If failure recurs, then there is a problem to be addressed. One of the key benefits of agile is fast failure, so that one will get more time to recover.
  • Iteration Scenario#6 – Not getting improved productivity with agile – Dear friend, if you had lifted 60 Kg weight in the gym yesterday, today it can be 61 or 62, irrespective of the technique you use. Ultimately you have to strengthen your muscles gradually and over a period of time you can lift considerably heavier weights with ease. This is true with agile teams as well. Productivity gains will happen, not in the early sprints, but in the later sprints.
  • Iteration Scenario#7 – If everything is decided by the team, then what will the scrum master do during the sprint?
    1. Ensure that the agile process is not diluted
    2. Remove impediments faced by the team
  • Iteration Scenario#8 – Is the iteration duration negotiable – No way. Time is non negotiable in agile, while scope and cost are negotiable.
  • Iteration Scenario#9 – During the sprint, can the scrum master do technical work – Yes. at that time he must be wearing the team members hat, and should not dilute the scrum master role.
  • Iteration Scenario#10 If the team completes the sprint earlier than planned? – Complete additional features. In this scenario, the team will end up doing more than planned, which is good. In this case the actual story points will be more than the planned story points.

To be continued…

agile, blog post

Sprint or Iteration Planning meeting guidelines

First of all, what is the difference between sprint and iteration?. As we all know, agile is a family of frameworks, whose central and common theme is the iteration. Scrum is one of the most popular among the agile frameworks. In the scrum framework, the iteration is called as ‘Sprint’. Throughout this article, I will be using the words sprint and iteration intermittently and both refers to the Iteration only.

  1. Duration of the sprint planning meeting – For a thirty days sprint we need eight hours for effective sprint planning. If that is the case, how much will it take if the sprint duration is two weeks?. The most common answer is ‘4’ hours. Believe me, sprint planning will take a minimum of 5 hours even if the sprint duration is 5 days. That is one of the reasons why very short sprints are not very effective. Plan for 5 to 8 hours for sprint planning meetings. That is a good investment. Very short sprint planning meetings are an indication of the command and control culture within the team, where a few decides and those decisions are imposed on to the team.
  2. Time boxing of the sprint planning meeting – As already discussed, the sprint planning meeting is time boxed into 5 – 8 hours depending on the sprint duration. The sprint planning meeting is further split into two logical halves of equal duration. The first segment is for selecting the sprint backlog from the product backlog. The second segment is for decomposing the sprint backlog further into the activities that need to be performed to build those features. and the second segment is for preparing the sprint back log.
  3. The Participants of the sprint planning meeting – The attendees are the scrum master, the product owner / product manager and the development team comprising of professionals with the required skills to build the product. Additional parties can be invited to provide additional business domain or technology domain information and advice, but they are dismissed after this information is provided.
  4. Product backlog readiness – Product backlog readiness is one of the key success factors for effective sprint planning. The product owner must elaborate the prioritized the product backlog (sprint backlog) to sufficient detail to enable the team to estimate the work. This where User stories helps. As a generally followed good practice, it will be useful if the product owner can prepare the user-stories at least for the features he/she is planning to schedule into the sprint. While elaborating the product backlog entries into user stories prior to the sprint planning meeting, the product owner will get sufficient opportunity to think though the feature to be developed in detail from the functionality perspective.
  5. Product backlog sharing – It works wonders, if the product owner can share the user stories of the upcoming sprint in advance to the development team. This has many advantages. This helps the team members to understand the functionality well even before walking into the sprint planning meeting. That will trigger the ‘How to do it’ thinking resulting in research before the planning meeting. This will also act as a peer review of the story before the actual planning meeting.
  6. Product manager availability – It is always advisable for the product manager to be present during the sprint planning meeting. In the absence of either the product owner or the product backlog, the scrum master is required to construct an adequate product backlog prior to the meeting and to stand in for the product owner, provided he has the capability and product vision.
  7. Sprint backlog – The goal of the first segment, or first 4 hours of the sprint planning meeting is for the team to select those product backlog items that it believes it can commit to turning into an increment of potentially shippable product functionality. The team will demonstrate this functionality to the product owner and stake holders at the sprint review meeting at the end of the sprint.
    • The team can make suggestions, but the decision to what product backlog can constitute the sprint is the responsibility of the product owner.
    • The team is responsible for determining how much of the product backlog that the product owner wants worked on the team will attempt to do during the sprint.
    • Time boxing the first segment to 4 hours means that this is all of the time that is available for analyzing the product backlog. Further analysis must be performed during the sprint. Large-grained, high-priority product backlog with imprecise estimates might not be thoroughly understood during this part of the sprint planning meeting and might result in the team not being not able to complete all of the product backlog that it selects.
    • The second segment of the sprint planning meeting occurs immediately after the first segment and is also time boxed to 4 hours.
    • During the second half of the sprint planning meeting, the team;
      • Identifies the activities that need to be performed to construct the features agreed upon during the first half of the sprint planning meeting.
      • Estimate the effort required to complete these activities
      • Validates with the available capacity and productivity to ensure that the team can build what is committed.
    • The product owner must be available to the team during the second segment to answer questions that the team might have about the product backlog.
    • It is up to the team acting solely on its own and without any direction from outside the team to figure out during the second segment how it will turn the selected product backlog into an increment of potentially shippable product functionality. No one else is allowed to do anything but observe or answer questions seeking further information.
  8. Sprint Planning Meeting Output – The output of the second segment of the sprint planning meeting is a list called sprint backlog, of tasks, task estimates and ‘volunteered work’  that will start the team on the work of developing the functionality. The task list might not be complete, but it must be complete enough to reflect mutual commitment on the part of all team members and to carry them through the first part of the sprint, while the team devises more tasks in the sprint backlog

Some of the key challenges of sprint planning meetings

  • Under the pretext of lack of time, some of the senior members does all the estimation work and thrusts that upon the rest of the team.
  • Lack of involvement of the team – Many team members do not participate well during the sprint planning meeting. At the same time I have seen many participating well as well. The root cause for lack of participation is lack of preparation. Still I remember the youngest engineer (had just 3 months work experience) who got introduced to me as ‘The most valuable engineer’ by the scrum master. He used to contact the product owner weeks before the sprint planning meeting to collect the probable features the product owner is planning for the next sprint. Then he starts R&D work on those features. By the time he enters the sprint planning meeting, he has a very good idea about the work that need to be performed to build those features. That is the right way to go.
  • Insufficient preparation by the product owner prior to the sprint planning meeting. Because of this, very often the product owner is unable answer the team’s queries regarding functionality. Even though the scrum guide does not say anything about this, based on my experience, it will be better if the product owner could prepare the user stories for the features she is planning for the sprint before getting into the sprint planning meeting.
  • Absence of the product owner during the sprint planning meeting. In this scenario, quite often the team will get struck during the sprint planning meeting due to lack of details.
  • Insufficient clarity about the reason behind doing a size based estimate (story points), before arriving at the effort. Unless one have in-depth understanding of the scrum framework and empiricism there will be ambiguity between size estimates and effort estimates. Why cant we jump into effort estimates directly?. I will soon write a blog post to explain this in detail.
agile, blog post

Agile release planning

Let us consider a product, which has around 150 features, when it is fully developed. Then it is going to take a long time and lot of money for developing all the features and then delivering the product. Though it sounds ideal to release the fully developed product, that approach has the following risks associated with it;

  1. The owner of the product will have to wait for a very long time to start making revenue out of the product. In the process he can go bankrupt before completing the development of the product.
  2. Everyone invest and build products with the hope that markets will accept them, and there will be lot of buyers waiting to buy the product. This is a major assumption. By releasing the product in a big bang mode after developing all the features, increases this risk.

By making frequent releases of the product, these risks can be addressed and at the same time, the end user should find value in the released increment of the product. That is a tight rope walk of managing the product owner expectations and the end user expectations from the product.

Agile release planning helps to satisfy these stakeholder needs by;

  1. Doing a cost benefit analysis of every feature in the product backlog
  2. Dependency determination among the features
  3. Classifying them into Must have, Should have and Nice to have features
  4. Grouping them into release milestones (Dates of release)
  5. Defining the iterations leading to the release milestones. Multiple iterations leads to a release.

This whole process put together we call it as the agile release planning. This is a progressive process. All products starts with a product road map with major release dates, which gets refined as the product of the project emerges and the team gains more insight about the product.

blog post, certifications, Education, PMP certification, Scholarship

Scholarship for PMP Certification

To start with, every month we offer free education to two professionals, who are the most deserving based on their professional track record and the present professional status.

If you really feel that a PMP certification will improve your career prospects , and if you are committed to put in the required effort to complete the PMP preparation course, then apply. It will take approximately 40 hours to complete the course. Upon successful completion of the course you will awarded 40 hours course completion certificate by PMRI.

You can apply by contacting us with a link to your linkedin profile.

We thank our sponsors for supporting us.

Best Wishes

team @ PMRI

Note : This Scholarship covers the 35 contact hours training. The PMP exam fees is not covered as of now. Hopefully we will be able to cover that as well in the future, as we get more sponsors for scholarships.

For the course details click here

agile, blog post, Hybrid Project Management, Integrated project monitoring and control, Monitoring and control

Interpreting Sprint or Iteration burn-down charts

If you learn to interpret the iteration burn down charts or sprint burn down charts, then you have understood agile or scrum conceptually correct. This article will walk you through the iteration burn down chart of a sprint.

Day#1

The Iteration or Sprint starts with the Iteration planning meeting. The output of the iteration planning meeting are;

  • The list of features to be developed during the iteration
  • Estimated story points (feature points) for the features (Fibonacci series)
  • The activities that need to be performed and their effort estimates
  • The tracking board (kanban board) which has the columns for;
    • To be done
    • Being done
    • Done
  • Two types of the Iteration / Sprint burn down chart
    • One with cumulative effort required to complete the sprint on the ‘Y’ axis and the duration of the sprint on the ‘X’ axis. The balance effort required to complete the sprint gets updated on a daily basis. This is a re-estimate by the team on a daily basis (this is not planned effort – consumed effort). This type of iteration burn down charts with the effort required to complete the iteration on the ‘Y’ axis and the iteration duration on the ‘X’ axis will help teams to speed up when required.
    • Teams use Iteration burn down to monitor the story points completed against the story points planned within the iteration. In this case the ‘Y’ axis will have the total story points planned for the sprint. This will get decreased based on the actual story points completed. This type of iteration burn down charts help the project stakeholders, especially the product owner to monitor and control the story points planned Vs achieved within the iteration.

Sprint burn down – Immediately after the planning meeting

Sprint burn down after day#2 of the sprint

Sprint burn down after day#3 of the sprint

Sprint burn down after day#4 of the sprint

agile, blog post, Hybrid Project Management, Management, Trends in project management

Areas to apply agile within EPC Projects

The overall duration of the EPC (Engineering, Procurement and Construction) intensive projects can be reduced / controlled considerably by the application of agile best practices during the following phase / activities;

Pre-project phase

  • Assigning a task force to conduct preliminary studies
  • Studying the users requirements
  • Defining the technical specifications
  • Studying how to secure funds
  • Estimation of the project cost and duration (budgetary)
  • Approval of the project cost
  • Determining the technical specification of the materials
  • Studying the impact of the project on safety and health
  • Establishing criteria for the selection of project location
  • Establishment of milestones
  • Describing the responsibilities and authority of the parties involved
  • Establishment of a change control process
  • Establishment of design criteria for structural specifications
  • Conducting a feasibility study of the proposed project
  • Site preparation / readiness
    • Getting all the clearances required
    • Establishing the construction areas and path of construction

Site preparation

  • Land acquisition
  • Re-rehabilitation
  • Getting all the clearances required
  • Ensuring site readiness

Project phase

  • Basic design phase
    • Documentation for tendering and contracting
    • Specifications for procuring equipment
    • Regular design and specification review meetings
  • Detailed design phase
    • Qualifying of design professionals
    • Performing technical and financial analysis of offers from competing contractors
    • Selecting the design team
    • Providing inputs to design on time
    • Monitoring and controlling the design progress
    • Updating design documents
    • Reviewing design documents
    • Ensuing design quality and adherence to technical standards
  • Tendering
    • Preparing the specifications and agreement conditions
    • Preparing bill of quantities (BOQ) and estimating the contract value
    • Issuing tender documents
    • Holding tender briefing meetings
    • Receiving bids and evaluating them
    • Recommendations are made for the successful contractor
    • Awarding of the contract
  • Execution or construction phase
  • If detailed designs are not provided as part of the tender document, the contractor proceeds with the detailed design and drawings and follows it up with construction
  • Regular progress monitoring

Closure or completion phase

  • Snag lists
  • Punch lists
  • Completion certificate

As we can see, these are the areas where multi disciplinary communication and coordination is required maximum. The biggest culprit for delay in most of the infrastructure projects is in getting clearances. By bringing in agile project management (APM) best practices to these areas of projects, the overall delay of the projects can be controlled effectively.

agile, blog post, Management, New product development, Project Management, Trends in project management

Lead the change your product is intended to make

You have a brilliant product idea, and you want to go ahead very fast with the product idea, and unfortunately things are not moving as planned. After some time, you are tired, and almost drops the idea. A few years later suddenly you come across a very successful product in the market, similar to the one you conceived years before and dropped half way through. This is a very common shared experience by many first time product owners.

After all, every innovative product is intended to shake the world in a gentle way. It is about changing the lives of many in a gentle way. The internet did it. iPhone did it with the touch screen. The android phone did it in a subtly different way. The covid vaccines are doing it, the medical equipment and the building material segment is doing it…the automotive industry is a veteran in this. ..every successful product changes the way we do things in a subtly better innovative way. More than just product development, what really matters is the long term strategy to manage the change the product is intended to deliver to it’s end users.

Eight steps to manage the change promised by the product of your project

  1. Sense of Urgency – The first and foremost ingredient to change management is creating the sense of urgency. When we are working for others, we are always pressurized by others deadlines. But when you own the product, the risk of complacency is very high. During the initial phases of the product, your investment in the product is low. Your only potential loss is the opportunity cost (opportunity lost if the product fails to take off) which is a futuristic cash flow. You do not feel a crisis at this stage and the ‘sense of urgency’ can take a back seat. This is really risky phase. Consistent ‘sense of urgency’ is one good quality I have observed in every successful product owner / entrepreneur.
  2. Creating the guiding coalition – To see the envisaged change by the product of your project impacting the world positively, one has to create a great coalition who resonates the same excitement and sense of urgency you have about the product. This coalition include technical experts, financial experts, marketing gurus, quality assurance, sales, investors…they are all external entities and getting them as excited as you are in the project starts with the right selection of these partners and getting them work together as a team.
  3. Developing a vision & Strategy – For many reasons, for many the vision and strategy documents are something to decorate the office. Many management books describes vision as something that motivates you to get up everyday and work. The best definition of ‘Vision’ that excites me most is the one by Dr. APJ Abdul Kalam, the late president of India. It goes like this…’Vision is something that wont let you to sleep, till accomplished’. Having an exciting vision and a strategy to support it makes all the partners / stakeholders work together as a cohesive unit.
  4. Communicating the change vision – Nobody lights a lamp and keeps it under the cot, instead it is placed on the lamp stand so that others can see the light. This is true with the change visions as well.
  5. Empowering broad based action – Removing impediments, getting rid of obstacles, encouraging risk taking and innovation.
  6. Generating short term wins – Releasing the minimum viable product (MVP), as fast as possible to the early adopters and then moving fast to address the other segments.
  7. Consolidating gains and producing more change – Incorporating change at a rapid pace to incorporate the feedback and the lessons from the market.
  8. Anchoring new approaches in the culture – After the early successes, profitable cash flows, successful partnerships it is time to consolidate, refine and institutionalize so that you can move on to more exciting products and changes that can impact the world in a better, bigger way.

Every project has a product or service as a primary deliverable. These products and services brings in changes the way people do things. Developing a product with the technical team is easier when compared to sell and manage the change the product offers. While developing the product calls for management skills, managing the change need leadership skills. Behind every successful product, there is a successful product owner who plays the leaders role.

Reference – Leading change – John P Kotter