Category: agile

agile, blog post, Trends in project management

Building a distributed agile team

In today’s fast changing world we cannot escape from the fact that business requirements change very often. If we use the predictive, heavy weight methodologies for developing software it is very difficult to incorporate the changing business needs of our customers. Lightweight software development methodologies, which appeared in the late nineties “embrace changes”. The disciplined adaptive nature of these methodologies helps us to easily accommodate changing business needs of our customers, even in later part of the development cycle.

Many software development organizations are using agile development methodologies like Scrum as it helps the organizations to respond to changing business environments very quickly and provide better customer satisfaction. In today’s business environment it is not really the big that win the battles rather it’s the fast that win the battles over the slow. Time to market is very important in today’s fast changing world. Agile development helps us to deliver the value to the customer rapidly through a divide and conquer approach and prioritization. The right 20% of effort will yield 80% of the value, so we do a lot of those in agile development and extreme testing.

Introduction to Agile

In Scrum the whole development is divided into different increments/sprints. Top priority user stories are covered in the initial sprints. Unit tests are developed first as a best practice. Then the code is written to ensure that 100% of unit tests pass. This is done in an incremental way. The developers write unit tests and 100% of Unit tests are automated. This will help in executing the tests repeatedly and also simplify the reporting of results.

There is one more important type of testing involved in agile testing, which is called Acceptance Test/Customer Test. These tests are written, based on User stories. They are formal tests conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Test engineers write the Acceptance tests with the help of customers in some organizations. It is very important to understand the customer perspectives while writing the acceptance tests. The big mountain acceptance tests are automated using an appropriate tool and executed on all the builds. Agile testing creates confidence that code is complete and it works; catches integration defects when they are first created, and, most importantly, provides confidence that a maintenance change did not introduce a regression error.

Basic values like open communication, tight feedback loop in the scrum teams, simplicity and courage are the key in scrum teams. In scrum, testing isn’t a final hurdle it is a journey along the full development cycle.

Areas to Focus

While building a distributed agile team  we need to consider multiple factors. If we don’t build the right team for Agile it is going to be very tough to get the results. Open Communication is one of the key values in agile development.

Individuals and Interactions

If your existing team is to be transformed into an Agile team the most important step is to evangelize the agile concepts and benefits in your team. Management and Development teams also need to be educated on the ROI(Return On Investment). When we were implementing Agile in our organization we used to conduct talks by practitioners on agile, play agile dramas depicting the outcome from monumental methodologies and light methodologies. Once the platform is set we can start implementing agile practices and values. We need to identify and prioritize which are the areas to focus on first for the team. We may need to refactor the team. If there are team members in your team with a negative attitude or having an attitude to resist changes, then proper guidance needs to be given to them to bring in the change. If there are no improvements, it is a good idea to move them to a different project. Agile talks about “tossing off” the code at the end of the day if it doesn’t serve the purpose. This is applicable for team members also. Don’t try to patch it up too much…

While recruiting new members to an agile team we need to ensure that they have the right set of attitudes and skills in line with the agile way of working. Openness, ready to give and accept feedback, simplicity, courage, adaptability, good in communication, right skill mix …these are some of the attributes we need to ensure in a new hire. If you are planning to hire it is a good idea to have a brief discussion about agile practices you follow in your organization during the interview. Once they are hired we need to evangelize agile among them. In some cities we may not get engineers who worked in agile earlier. Transforming an engineer who has been working in monumental methodologies to an agile environment is not that easy. It’s a big paradigm shift. There may be resistance to change. We need to plan our inductions in such a way that the returns of Agile are communicated to the new hires appropriately. Once they understand the synergy it gives to customers and the organization employees will start believing in this new model. Once this milestone is covered it is easy to evangelize the other agile practices we follow in our organization.

Like the “pair programming” concept in Agile mentoring also can be done through pairing. A new hire is paired with a senior engineer who is in the team for more than 1 year. A high level introduction about the product is given to the new hire. After that during the sprint the new hire pair up with other team members according to the plan laid out by the Coach. The mentoring plans always focus on big mountain functionalities first.

When a groupWhen group of people works together in internationally distributed locations, there is great need to communicate with each other, share data and share expensive resources. Building a good communication mechanism is very important for the success of agile testing. Conversation with developer, customer, and feature team leads and product manager is frequent. Daily Stand up meetings with the scrum teams helps to build the relationships among the teams. All the Agile team members including developers, test engineers, documentation experts, product managers and DevOps assemble in the morning (usually on a planned fixed time like 10am) for a short stand up meeting of 5 to 10 minutes duration. Plan for the day and top priority unresolved issues from the previous days work is communicated to the team. This meeting is not for resolving the issues or detailed discussion. Resolutions are taken later after the meeting. If we are working in a distributed model where the development is happening in the US and the testing is in India or some part of the feature team is in a remote location like India and China, Communication and the feedback loop get badly affected. Tailored agile for these kinds of offshore development can be called as “Distributed Agile”. Collaboration among testers, programmers, and other stakeholders is more highly valued on agile projects than details of process, practices, or tools. Test engineers are part of scrum teams. Agile methods ask teams to continually evaluate how to improve group interaction, for the benefit of the project.

Once we have decided the members of the scrum team, building the team is the first priority. We need to plan for internal and external team building activities initially. We can also do a lot of informal interactions and get together … like all feature team members having evening snacks together in the snacks parlor.

Video calls, Chat, email , lightweight documentations  , phone calls etc.. can be used for constant communications. We can plan for weekly meetings with members of the scrum team who are in the remote location. It is a good idea to have all the scrum team members participate in this meeting. Frequent conversations between the remotely located team members is a good practice. This will help us to build relationships. We need to agree on the overlap timings when the video calls can happen as most of the time one of the engineers will be at home because of the time zone differences. Engineers traveling in both directions frequently (2-3 travels per quarter) and working with the remote team for 3-4 weeks will enhance the relationships. This will help us for better culture sync. These ambassadors ensure there is enough osmosis within the distributed feature team.

Working Software over Comprehensive Documentation

Jim McCarthy said that, “The regular build is the single most reliable indicator that a team is functional and a product is being developed.” This is very much true in the case of a distributed agile team. We need to ensure that we have good CI/CD practices in our organization where the latest builds are easily available for the test teams. This will help the test teams to run their test on the latest code. We need to automate the big mountain acceptance tests using appropriate tools. This will help us to test often and communicate the progress to the feature teams.

Frequent demos of the current status of the features to the entire feature team is very important. It is a good idea to have such demos weekly once. Demos can be arranged for remote teams on Fridays and we can have a group test after that where the entire feature team tests the latest build with a focus on new features. These demos can be recorded and uploaded to a common repository. Later if some of the team members want to go through the demo they can always replay it from the common repository. During the initial milestones where the top priority features are developed we can use build mechanisms like “sandbox” where the developers check in their new code as and when the unit test passes into a sandbox build maintained by the feature team. Test engineers can always use this build for testing the new features. As we are going to give feedback on working software rather than on design documents or requirement documents the feedback inputs will have more value. Development engineers can incorporate the feedback back into the sandbox the next day. At the end of the week all the new code checked in by the feature team in the sand box (which is tested and feedback incorporated) can be checked into the main line code. If we are working in distributed agile we may need to document some of the important changes. We can use wiki or google doc etc… for maintaining these kinds of knowledge bits.

Summary

To build an effective testing team for Distributed agile we need to focus on individuals and interactions over processes and tools. We need to ensure that the latest code is available for testing in all the internationally distributed locations. Feedback based on working software helps to build confidence in the feature teams.

References : https://agilemanifesto.org/ 

Author :

Baiju Joseph Thalupadath

Head Of TechOps(QE,RE & SRE) @ Yahoo Small Business

Linkedin profile

agile, blog post

OVERCOMING THE BARRIERS TO AGILITY

[responsivevoice_button]

Agile Transformation is the evolution process an organization undergoes in order to deliver better, faster solutions while adapting to the constant change of an increasingly complex and uncertain business environment. Most organizations recognize the benefits of agile but aren’t sure how to create or encourage Agile “behavior” or when to introduce frameworks and practices. It involves a mind-set change in all people in an organization which can be uncomfortable for most. Commonly the emphasis in an Agile Transformation is on the “Agile” part and there is little focus on the “transformation”. When the companies focus on the details of “Agile” they often struggle or fail. The emphasis should be on “transformation”. Agile is important, but it is not the make or break focus of an Agile Transformation.


The following are transformation issues, no matter what kind of Agile Transformation you have in mind (Scrum, Kanban, Lean, XP or other team level practices OR SAFe, LeSS, DAD or other scaling practices):

  1. Company philosophy or culture at odds with core Agile values: Cultural change is critical to any ongoing successful Agile adoption by small and larger businesses because people feel comfortable using traditional ways and resist any change. Moreover, it is critical that Agile must co-exist with traditional development approaches. The agile adoption can change the nature of some roles; particularly those of line management and traditional project management, people who are used to making decisions and directing work, whereas agile requires a more democratic process, with all team members participating. It’s very important that people in such positions are allowed to influence the nature of their new roles and understand the value they can continue providing. Without such transparent communication, they can become blockers to the adoption of agile but when properly involved, they can be positive agents of change.
    Recommendation: Should start small, experiment with pilots and prototypes. Ensure key stakeholders are involved early in the process and have a common understanding of Agile concepts and benefits. Plan a concise, contextualized strategy for Agile transformation, a foundation roadmap, its desired outcomes, how to measure and communicate the progress and success to the team. When others in the Organization realize the success, will also start supporting and contributing in Agile adoption.
  2. Lack of management support: It’s usually ‘middle management’ who has lack of trust for a new process, lack of understanding of changing roles and a lack of buy-in to the new process. Successful Agile implementations need support from the team members, management, and executives to embrace new ways of completing work and collaborating. In most enterprise wide agile implementation efforts, it is common for teams and executive to have great enthusiasm for the effort. However, in the absence of a strong Agile transformation plan, project and program managers or functional ‘resource’ managers often feel isolated mainly because their roles are no longer clear. This results in a general resistance and creates additional barriers to further Agile adoption and success.
    Recommendation: Executive leaders should model the behavior they want their management team to display. Lead by being an example and live the values they want them to adopt, and help middle managers understand how they fit into the changing organization. Embrace not only from top down but bottom up that a “mind shift” needs to happen to embrace the new levels or collaboration, communication and transparency.
  3. Resistance to change: Another barrier is resistance from people who feel they don’t need to change and unwilling to follow Agile. A lot of the “management” functions start to move, change or go away as an organization becomes Agile. One of the changes is that “Line management” becomes less important and “hands-on” as people and teams become empowered; Technical managers become less important as teams become more self-directed and define their own technology spaces; Service managers become less involved as people move from silo IT to DevOps and Project managers become less powerful as the firm moves from a project to a product mindset.
    Recommendation: Not having alignment on the aspiration and value of an agile transformation could be barrier. Employees also need incentive to make a change and how will it benefit them. No matter what your role most people need to know “what is in this for me?” it is human nature when dealing with change. Everyone must see the value in the change before it can happen. Incentive is the piece that can either build consensus or build resistance among staff. Incentives can be tangible such as monetary, or intangible such as personal achievement or prestige.
  4. External pressure to follow Legacy systems and processes: This is especially common in large enterprises, where some teams follow Agile approaches and other parts of the organization operates within traditional waterfall approaches, sometimes working under the umbrella of the same portfolio or program. In such cases, the Agile teams are usually being grafted into the existing traditional portfolio and project management methodology, and with teams that are working against different schedules, trying to deliver on a specific project. This can be a barrier in successful Agile adoption.
    Recommendation: Should aim to get business units aligned through training to ensure that managers of different areas understand the implications of interacting with teams that do work in the new way. The ultimate goal should be to break dependencies across the entire organization. Change your metrics, identify new metrics that move away from measuring and tracking lines of codes, quality issues and reports as success factors and deliverables. Focus on “working product” and value delivery and this should be greatest measure of success in an Agile environment. And to achieve this, facilitate continuous collaboration between the business and the development team. Having the traditional teams understand even though they cannot change their architecture on a dime there are things that they can do to move them in the right direction, have them start small and work their way over to a full agile adoption.
  5. Insufficient training: One of the necessary elements is to know what skills are needed and do existing staff members have expertise or training in what they are being asked to do. The lack of skill, appropriate resources and training may lead to anxiety.
    Recommendation: Should know what in-house resources are readily available and if they are suitable. What resources are needed and how will you get them. Conduct trainings for all stakeholders and the core teams. Coach teams through real delivery to refine understanding. Not only is the initial training essential but on-going training to keep the skills within a team and to assist the team in evolving to a high performing group of people.
  6. Inadequate experience with Agile approaches: For most new Agile teams, members are typically inexperienced in applying basic Agile practices and unfamiliar with successful agile transformations. In such cases, there is a high likelihood for misinterpretation of Agile principles and fallback to old practices. An Agile process will expose problems and issues with the project more quickly than a more traditional development process; addressing such and what to do about those problems and issues is also not always very clear to new and inexperienced Agile teams. Challenges can make the difference for the team’s success or failure with Agile.
    Recommendation: Understand that inexperienced teams need more formal process and guidance. Include an experienced Agile resource to coach on the team that has strong experience practicing Agile methods, and successful experience with Agile teams. Keep team members stable on a team, if possible, move towards a “Fund the team” model versus “fund the project” where you are constantly ramping up new teams. This will help teams mature and develop a cadence and well-defined velocities that provide better predictability to product owners and stakeholders. Invest in making training and continued coaching guidance available for the teams to consult. Encourage a learning organization by launching a community of practice.
  7. Lack of vision and Agile priority: There must be a vision and reason why the change is needed. Creating an “agile friendly” culture requires a firm vision, senior business and IT executive support, strong governance and a clear roadmap. Mostly, companies find themselves limiting agile to pilots within a small part of the organization, with a small set of leaders. While the pilot is typically successful, its impact is restricted to a few teams and not treating agile as a strategic priority that goes beyond pilots eventually gets killed.
    Recommendation: Transparency is vital to the effective teamwork that underpins agile development. The vision and action plan for change should be clear, developed by a representation of all stakeholders and should be communicated to the team. The lack of vision and open communication leads to confusion. A great practice is to not only review the vision with the team in the beginning but go back to review it as work progresses ensure the changes that naturally occur are accounted for and the team(s) still understand the direction and priority needs to help deliver the greatest value.

By Harleen Flora; PhD (Computer Science), PMP, MSP, PRINCE2, ITILv3, CSM, Agile PM, SAFe5 Agilist, Lean Six Sigma Black Belt https://www.linkedin.com/in/harleenflora/

agile, blog post, certifications, gig economy, PMP certification, Trends in project management

Project trends 2021

World over the way people work have changed. Organizations are forced to re-think their business strategies to survive first and then to grow in a new world order characterized by;
  • Organizations sparing no opportunity to maintain / improve bottom lines
  • Organizations trying to go-global looking for new markets for existing products and services
  • Organizations rapidly innovating new products and services for their current markets and beyond
  • Organizations leveraging the gig economy

In a nutshell, everything in the corporate environment have become dynamically agile, where business owners are trying their best to maximize return on their investments. As a timely coincidence, leading organizations like the Project Management Institute (PMI) started their initiatives long back to converge the Predictive and Agile Project Management best practices, as if they could foresee the forthcoming new world order well in advance. All these have major impact on how we collaborate and work on projects. The concept of permanent employment have already become a matter of the past, as organizations are actively seeking flexibility in resourcing to optimize costs.

People with proven skill sets and the ability to learn fast with good work ethics will be sought after. Professionals with the ability to deliver value at the right time, with almost zero supervision, working remotely will be in demand globally. The geographical constraints of employment will become almost zero for the right people who can proactively identify the new opportunities and gear up. In this new world order, our professional profiles matters a lot to market ourselves. You are a brand, and that brand has to be continuously nourished to be in demand. This is the right time to equip yourself with new in demand skills supported by globally acknowledged credentials. Project Management 2021, is all about highly skilled, motivated individuals, working on their projects of choice as self organizing teams, demonstrating high degree of work ethics.

Get ready and embrace the Change !

PMdistilled PMP fastrack program

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.

agile, Hybrid Project Management, New product development, Research & Development

Request for feedback to serve you and the project management community better

Agile is excellent. Predictive project management is even better. Leveraging the strengths of these two intelligently to make the projects successful is very practical and many of the organizations are practicing hybrid project management very effectively. We are really glad to see this independent view of ours gaining wider acceptance these days. Thanks to PMI, for incorporating the same views in the latest version of the Project Management Body of Knowledge (PMBOK). This is the project management practitioner’s perspective.

When it comes to project management education perspective, our experience is totally different. When we try to educate a project management professional both Agile and Predictive together, that becomes very difficult to understand and comprehend for them. That is because some of the fundamentals of predictive and agile are different and even conflicting.

Hence our new project management training program is highly modular and comprises of a stack of four programs;

  1. Predictive Project Management (PPM)
  2. Agile Project Management (PPM)
  3. Hybrid Project Management (HPM)
  4. PMP Content & Certification focus

These are our thoughts based on experience, and we have started developing these training programs with the hope of making things easier for the learner of professional project management, for both the experienced and the novice.

Here is the help we need from you…

We have completed the week#1 module of the Predictive Project Management Course, which is part of the New 10 week PMP program. We are seeking early inputs / feedback from you to incorporate them into the subsequent modules and courses which will definitely help us to make these courses very learner friendly to serve you and the project management community better in the coming days. Your inputs are very valuable to us. Please spare a few minutes of your valuable time to share your experience and views with us.

Click here for the Week#1 Module of Predictive Project Management

Click here to provide us with your feedback