This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Search

How To Run Fixed Date Projects In Agile?

I have been lucky to work in different organizations that have taught me different things and made me aware of different points of view. One thing I have learned early in my career is how to “smell” fake fixed dates. Unfortunately, there still are organizations or people in some organizations that believe that by setting deadlines people will be motivated to get work done.These are fake deadlines, without real urgency behind them and without any loss of business or clients. They are dangerous because they create fake rush, get people to work late hours for no good reason, and in the end there is nothing to celebrate for what they did.However, I do believe that there are some legitimate cases when a certain solution is required in place by a fixed date. I have seen these cases and I have seen how Agile teams have been able to deal with them successfully.Some of these examples are Regulatory changes, Event-driven or Promotional and Holidays. Regulatory: These are changes that are forced on a company usually by Government or Market regulations.  Event-driven: These changes are usually driven by Marketing and supported by Sales. They are opportunities to showcase the strength of the brand, enforce market presence and/or domination in events like expos, conferences, partner announcements, marketing announcements, etc.Promotional or Holidays: These changes are usually driven by Sales and supported by Marketing. Think Christmas, Valentine’s Day, or similar depending where you live. These are days that retailers “live for”. I can think of other cases, but they kind of boil down to the need for an area of the organization to have an offer ready by a certain date that is controlled by external factors/organizations. The good thing about these cases is that usually we have a decent amount time on hand to prepare and deliver. During this time, I have found tools and techniques that help you more than some others, and I want to share those with you. Good understanding of the meaning of a fixed dateWhat happens if we miss the date?What happens if we miss the date by a lot/by a little?Do we have to have in place feature A or will B do it?Can we do A manually?Is the deadline for all our clients or just a portion of them?Keep asking from all the points of view. This is a good exercise that Agile teams are used to doing since they constantly split their stories into smaller work. Now bring all that into splitting the work for the deadline into smaller BUT meaningful and valuable pieces.Presenting real-time examplesIn one of the cases, I assisted my team, we were given only five days to deal with a change required by one of the provinces of Canada. Two of those days were taken by speaking with lawyers to clarify all the details of the change requested. After that, the team was able to understand the amount of work and what was the minimum they had to do to satisfy this new regulation. It was done on time.In another case, the Retail company had to decide if what they were asking was possible to be done by mid November. They agreed that if it was not in place by then, there was no value in putting efforts towards it since it will be too late for Christmas promotions.In another case, a product company wanted to present the new features of their 3D software at the most prestigious event of the industry. They decided to be in a good place where the Product Owner knew what wasn’t working or how to get around the features that would be demoed on the expo floor. The goal was to get people excited to have them subscribe and then follow up when the software was ready with the features and high quality experience.So, keep asking, keep slicing and keep finding ways to do the minimum required. Unless, you have all the time you need and in that case, do what is needed with high quality.The image below will perfectly explain how asking questions can help you prioritize.Product Owner and people with all the skills required are available all the time or in very short noticeAlthough we have asked all the questions and we have figured out the smallest piece of work to start with, questions and issues will always come up. Without the Product Owner always present to respond to questions from the team, we end up with wasted time. Same is true for any specialist or any skill required to achieve the deadline. We manufacture Dependencies.If this fixed date is high-priority, then let’s give it the right attention and the right dedication. If many things are high priority, it is usually a smell that prioritization is not well and is probably based on who screams the loudest. This is where we need to make sure that expectations are set and clear, where we understand the priorities of the organization and where people will focus.Coming to dependency management, the following figure can help visualize the ideal ways to manage dependency and streamline your workflow.  Dependency management is done best when we remove dependencies rather than manage them. Take time to identify the dependencies on skills, knowledge, process, sequencing and any other area that affects you. Take time to look at the whole picture and set in place communication channels, core working hours, give heads up with enough time for other areas to prepare for your requests. But one thing that works the best is to have a team that works very closely, possibly co-located and supported with collaboration tools. It would be great if this team is already working together and this request is a new addition to their prioritized backlog.  Otherwise you will lose time with onboarding.Continuous Delivery PipelineWe are not done until we are done. And done means it is accepted all the way to production. There is work to develop the change and then there is work to deploy the change. If your company has a long deployment process with many layers of approvals or documents to complete, then you are shortening the time for development. This adds extra stress to the team that will work on this change and frankly speaking from the Lean Governance point of view, a lot of waste in your system.Often, teams are asked to justify the need for investing in automation and better technology. These are the days when that investment has high returns and pays you back many times over. Continuous Delivery gives teams the advantage of early and often feedback. The earlier you are able to deliver out a solution the faster you learn about what risks you have to deal with when the changes are in the hands of the customers.There are many ways to leverage early deployments when Continuous Delivery Pipeline is in place. You will be able to deliver a small portion of the change (often you hear MVP but I prefer Learning Release), you will be able to test with a small number of customers or for a specific geolocation of your customers.Like this, you reduce the risk of releasing a valuable solution on the requested fixed date. No need to work extra hours or late at night.   !! DO NOT !!Hire more people and make a bigger team.Big teams move slow. Also, onboarding new people on the team is down time for specialists as well because they will do the training. For changes that have a short time to deal with a fixed date, adding people on the team will only slow you down and create more confusion.Cut cornersUnfortunately, I often see the practice of “get it off my plate”, where a team just patches together a quick fix and then sends it over to production to call it success. Although everyone knows that this change was not done right, we never give time for teams to go back and do it right.So if you can, do it right from the beginning or make sure the team does not start working on something else until they refactor the solution. This will allow you to make future changes easier and faster, even if the future changes are urgent and have a fixed date.Stop asking “Why?”On everything we do, we need to continue asking “Why” and challenge better ways of working. Just because this is how things are done now, it doesn’t need to be how we have to keep doing it in the future. The spirit of Agile is continuous improvement and that is where we keep learning and getting better. Asking “why” is where we get out of our comfort zone and become creative with the solutions for our customers.
Rated 4.0/5 based on 2 customer reviews

How To Run Fixed Date Projects In Agile?

408
  • by Ardita l
  • 07th Aug, 2018
  • Last updated on 23rd Jan, 2019
  • 6 mins read
How To Run Fixed Date Projects In Agile?

I have been lucky to work in different organizations that have taught me different things and made me aware of different points of view. One thing I have learned early in my career is how to “smell” fake fixed dates. Unfortunately, there still are organizations or people in some organizations that believe that by setting deadlines people will be motivated to get work done.

These are fake deadlines, without real urgency behind them and without any loss of business or clients. They are dangerous because they create fake rush, get people to work late hours for no good reason, and in the end there is nothing to celebrate for what they did.
However, I do believe that there are some legitimate cases when a certain solution is required in place by a fixed date. I have seen these cases and I have seen how Agile teams have been able to deal with them successfully.

Some of these examples are Regulatory changes, Event-driven or Promotional and Holidays.
 
Regulatory: These are changes that are forced on a company usually by Government or Market regulations.  

Event-driven: These changes are usually driven by Marketing and supported by Sales. They are opportunities to showcase the strength of the brand, enforce market presence and/or domination in events like expos, conferences, partner announcements, marketing announcements, etc.

Promotional or Holidays: These changes are usually driven by Sales and supported by Marketing. Think Christmas, Valentine’s Day, or similar depending where you live. These are days that retailers “live for”.
 
I can think of other cases, but they kind of boil down to the need for an area of the organization to have an offer ready by a certain date that is controlled by external factors/organizations. The good thing about these cases is that usually we have a decent amount time on hand to prepare and deliver. During this time, I have found tools and techniques that help you more than some others, and I want to share those with you.
 
Good understanding of the meaning of a fixed date

  • What happens if we miss the date?
  • What happens if we miss the date by a lot/by a little?
  • Do we have to have in place feature A or will B do it?
  • Can we do A manually?
  • Is the deadline for all our clients or just a portion of them?

Keep asking from all the points of view. This is a good exercise that Agile teams are used to doing since they constantly split their stories into smaller work. Now bring all that into splitting the work for the deadline into smaller BUT meaningful and valuable pieces.

Presenting real-time examples

In one of the cases, I assisted my team, we were given only five days to deal with a change required by one of the provinces of Canada. Two of those days were taken by speaking with lawyers to clarify all the details of the change requested. After that, the team was able to understand the amount of work and what was the minimum they had to do to satisfy this new regulation. It was done on time.

In another case, the Retail company had to decide if what they were asking was possible to be done by mid November. They agreed that if it was not in place by then, there was no value in putting efforts towards it since it will be too late for Christmas promotions.

In another case, a product company wanted to present the new features of their 3D software at the most prestigious event of the industry. They decided to be in a good place where the Product Owner knew what wasn’t working or how to get around the features that would be demoed on the expo floor. The goal was to get people excited to have them subscribe and then follow up when the software was ready with the features and high quality experience.

So, keep asking, keep slicing and keep finding ways to do the minimum required. Unless, you have all the time you need and in that case, do what is needed with high quality.

The image below will perfectly explain how asking questions can help you prioritize.
Product Owner and people with all the skills required are available all the time or in very short notice

Although we have asked all the questions and we have figured out the smallest piece of work to start with, questions and issues will always come up. Without the Product Owner always present to respond to questions from the team, we end up with wasted time. Same is true for any specialist or any skill required to achieve the deadline. We manufacture Dependencies.

If this fixed date is high-priority, then let’s give it the right attention and the right dedication. If many things are high priority, it is usually a smell that prioritization is not well and is probably based on who screams the loudest. This is where we need to make sure that expectations are set and clear, where we understand the priorities of the organization and where people will focus.

Coming to dependency management, the following figure can help visualize the ideal ways to manage dependency and streamline your workflow.  
Dependency management is done best when we remove dependencies rather than manage them. Take time to identify the dependencies on skills, knowledge, process, sequencing and any other area that affects you. Take time to look at the whole picture and set in place communication channels, core working hours, give heads up with enough time for other areas to prepare for your requests. But one thing that works the best is to have a team that works very closely, possibly co-located and supported with collaboration tools. It would be great if this team is already working together and this request is a new addition to their prioritized backlog.  Otherwise you will lose time with onboarding.

Continuous Delivery Pipeline

We are not done until we are done. And done means it is accepted all the way to production. There is work to develop the change and then there is work to deploy the change. If your company has a long deployment process with many layers of approvals or documents to complete, then you are shortening the time for development. This adds extra stress to the team that will work on this change and frankly speaking from the Lean Governance point of view, a lot of waste in your system.

Often, teams are asked to justify the need for investing in automation and better technology. These are the days when that investment has high returns and pays you back many times over. Continuous Delivery gives teams the advantage of early and often feedback. The earlier you are able to deliver out a solution the faster you learn about what risks you have to deal with when the changes are in the hands of the customers.
There are many ways to leverage early deployments when Continuous Delivery Pipeline is in place. You will be able to deliver a small portion of the change (often you hear MVP but I prefer Learning Release), you will be able to test with a small number of customers or for a specific geolocation of your customers.
Like this, you reduce the risk of releasing a valuable solution on the requested fixed date. No need to work extra hours or late at night.  
 
!! DO NOT !!

Hire more people and make a bigger team.

Big teams move slow. Also, onboarding new people on the team is down time for specialists as well because they will do the training. For changes that have a short time to deal with a fixed date, adding people on the team will only slow you down and create more confusion.
Cut corners

Unfortunately, I often see the practice of “get it off my plate”, where a team just patches together a quick fix and then sends it over to production to call it success. Although everyone knows that this change was not done right, we never give time for teams to go back and do it right.

So if you can, do it right from the beginning or make sure the team does not start working on something else until they refactor the solution. This will allow you to make future changes easier and faster, even if the future changes are urgent and have a fixed date.

Stop asking “Why?”

On everything we do, we need to continue asking “Why” and challenge better ways of working. Just because this is how things are done now, it doesn’t need to be how we have to keep doing it in the future. The spirit of Agile is continuous improvement and that is where we keep learning and getting better. Asking “why” is where we get out of our comfort zone and become creative with the solutions for our customers.

Ardita

Ardita l

Blog Author

Ardita is a passionate Agile coach, trainer, speaker and consultant in the Toronto area. As the President of Industrial Logic Canada, she brings more than 15 years of software development experience from different commercial and public organizations. Over the past few years her focus has been on business process improvement for organizations that are adopting Agile practices. Working with management and development teams, she is well known for applying Agile and Lean techniques to help identify and remove barriers in order to streamline software development efforts. She is driven in creating sustainable change and has developed techniques that focus on building teams that have a culture of continuous improvement.

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Best Practices of Scaled Agile Framework - Agile Management

The enterprises have many different frameworks and methodologies to choose from once they decide to adopt the ‘Agile’ approach for project/product development. Designed by the Scaled Agile Inc, the Scaled Agile Framework (SAFe) is an Agile software-development framework. Earlier, the Agile development methodologies were used on a trial basis for various projects at an enterprise level. The development team experimented in making an efficient Agile method suitable to work in their environment. This resulted in evaluation of methods that worked and that didn’t, which ultimately led to the development of various frameworks and strategies for the adoption of the Scaled Agile Framework. Within the last few years, the Scaled Agile adoption has become popular amongst many enterprises. The two most important responsibilities of management are measuring improvement and ROI. The management needs to choose a solution that best equips with their business model and speed up the delivery and release phases. With these benefits coming handy, more and more professionals are practising lean and Agile methods and implementing it in the enterprises. The Scaled Agile Framework is a highly structured and is mainly used in larger enterprises and is primarily used to for agile development. It is an increasingly popular framework that has been successfully implements in enterprises. The nine principles of SAFe include as follows: 1. Taking an economic view 2. Applying systems thinking 3. Assuming variability by preserving options 4. Incremental built with fast and integrated learning cycles 5. Building the foundation of milestones on objective evaluation of working systems 6. Visualising and limiting WIP, managing queue lengths and reducing batch sizes 7. Synchronising with cross-domain planning by applying cadence (timing) 8. Establishing deep-rooted motivation of knowledge workers 9. Decentralising the decision making There are three levels in SAFe, and they’re as follows: • Team All the SAFe teams are the Agile teams consisting of 5–9 people working in 2-week scrums. They have skills to define, develop, test, and deliver value using XP (Extreme Programming) methods. Unlike the traditional development scrums, they work in collaboration. • Program At Program level, 5–10 SAFe teams consisting of 50–125 persons create an “Agile Train Release” comprising of stakeholders and development teams. They put in sync their iteration boundaries and facilitate delivery of integrated working systems every 2 weeks. The SAFe defines the Agile Release Train (ART), which in every 10 weeks (5 iterations) delivers a Potentially Shippable Increment (PSI). The PSIs provides a steady cadence (timing) for the development cycle. • Portfolio The lean–Agile budgeting mechanisms are budgeted by a portfolio, which is a collection of value streams. The portfolio management requires program management, investment funding, strategy, and governance. A portfolio is associated with the enterprise strategy in terms of strategic themes. Epics that define large-development initiatives are captured and analysed by a portfolio Kanban system. There are business epics that are customer facing, and then there are architectural epics that are technology solutions. How the practices of the Scaled Agile Framework benefit the organisation? SAFe is considered as a framework based on Agile Development, Lean, and Systems Thinking, which has gained worldwide recognition throughout the large corporations and enterprises. Following are the benefits of adopting the Scaled Agile Framework for your organisation: 1. SAFe allows implementation large team programs and portfolios Initially, the organisations adopt Agile approach and experiment it by its implementation with small teams. After gaining moderate success with small teams, often the organisations would try to increase the size by aligning various teams, programs, and various departments in an organisation to promote collaboration and efficiency in development and shipment of the product. By identifying the key Agile functionalities, Lean and Systems Thinking that scale well, SAFe addresses all these issues. 2. SAFe outlines a consistent approach for planning, execution, and delivery of value It becomes difficult for large organisations when numerous Agile teams are involved, because the teams might operate on different cadences (timing), or might use various Agile frameworks, or might rely on varying tools for managing the Agile lifecycle, or the teams might have adopted different technique practices. SAFe makes use of ART (Agile Release Train), which collaborates various Agile teams on a consistent cadence for every 8–10 weeks. It is known as a Program Increment (PI). This enables the teams of the organisations get together and uncover, plan, and address dependencies of the teams and the risks that might arise. All the teams of ART make use of best practices such as the Scrum-of-Scrums during each PI. At the end of every Project Increment, the ART does the analysis of what was done in the past 8–12 weeks. 3. SAFe addresses roles and responsibilities across Team, Program, and Portfolio levels Adopting and implementing Agile causes a drastic change across the organisation, which can raise questions regarding the current and new functions. SAFe addresses all these questions across the various levels. 4. SAFe provides a framework to bring consistency in strategy and alignment to the program and team levels In an organisation, maintaining an overall alignment with the vision and strategy is often a challenge faced by enterprise-scale software development. It becomes difficult to arrange various business departments with similar strategies, and if that is achieved, the problem still persists to communicate that strategy at the team level. SAFe provides an architecture to implement Agile, Lean, and Systems Thinking consistently to various levels in an organisation. 5. SAFe improves product development lead times SAFe is a well-documented approach that applies its principles, benefits, and values to the wider enterprise. More and more large corporations have understood how to scale Agile to lessen the time required for product development and improve the release time of their product compared to their market competitors. SAFe provides an extensive set of functionalities that can be applied in an enterprise to successfully scale Agile.
Rated 4.0/5 based on 20 customer reviews
1038
Best Practices of Scaled Agile Framework - Agile M...

The enterprises have many different frameworks and... Read More

Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Product Backlog Grooming, is a method for keeping the backlog updated, clean and orderly. It is a basic process in Scrum. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. Backlog can be defined as a set of user stories which are not present in the current sprint that defines project’s scope context. The stories which are left unattended, may interfere with the functioning of the development team.When this happens, the status of user stories will not be clear, and even the team can lose focus and fail to deliver within the project completion date. The backlog grooming meeting is attended by the scrum master, who facilitates everything for team members, the team and the product owner. They decide among the top items from the product backlog. The team comprises mainly of Developers, testers and Scrum Masters. The team can raise queries during the sprint planning session if they find any unresolved issue. The expected doubts can arise in the following forms : How to handle the situation if the user enters invalid data? Which part of the system are the users authorized to operate on? For the product owner, it will be easy to get the conclusion over the queries, by asking these questions in the early stages. If there is a question which is unanswered by too many people, it is time to make some changes in your backlog items by curating higher priority items to the top of the list and assigning highest priority to the unanswered questions. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important?  PBR and its sessions are important mainly due to the following features- It increases the efficiency of the team by reducing uncertainty Properly refined stories are easy to estimate, test and implement. PBR session increases the efficiency of the team due to the knowledge shared among the team members. If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. The Product Backlog grooming can be made effective if the following aspects are considered- Do not schedule backlog refinement meeting during the first and last 20% of the Sprint Planning session. Backlog refinement meeting should be considered as the first part of Sprint Planning. The backlog items’ list should be well understood by the PO, or development team member to work well in the meeting. Make sure that the set of predefined acceptance tests are present. Keep an eye on the meeting goals. Make sure to assign action items for any unknown thing. Do remember that the backlog items are a collaboration between the PO and the team. Feel free to break the product backlog items during the meeting. After the product backlog refinement meeting, the team can update the Product Backlog items in line, based on the discussions held. Finally, you can get a potentially shippable product, ready to be deployed in the market.
Rated 4.0/5 based on 20 customer reviews
2315
Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Pr... Read More

Scrum Master vs. Project Manager: Differences and Similarities

Organizations that are new to Agile and Scrum commit some deadly blunders. The most common and overlooked one is the lack of clarity of the roles of the Scrum Master and the Project Manager. This is more often seen in smaller Scrum teams, where these two discrete roles overlap.  There are of course similarities between Scrum Master and Project Manager roles. But that does not give way to ignoring the distinct differences between an Agile Project Manager and Scrum Master.  We have spaced out this article into various sections-    Scrum Master vs. Project Manager roles and responsibilities Scrum Master roles and responsibilities: Scrum Master is referred as a facilitator, who manages the teams that are implementing the Agile methodology. Scrum framework is the best framework for smaller teams of developers, who can break their work into a Sprint in order to get your project done at the end of every sprint.  The roles and responsibilities of the Scrum Master includes- Sprint planning  Scheduling the daily Scrum meeting Managing Scrum process responsibly Helping the Scrum teams to follow Scrum practices Removing barriers so the team can focus on their work Assisting with the Product Backlog Co-operating with Product Owner in designing Product Backlog items for the next Sprint Protecting the team from external distractions Recording and assisting to improve team dynamics   *Project Manager roles and responsibilities: Project manager’s role is to manage the projects and ensure that the project meets the requirements. The roles and responsibilities of the Project Manager are as follows- Defining project scope to the team Planning project target Preparing the work schedule for the team members Gathering requirements Defining the resource requirements for the project Preparing the budget for a project Assuring quality Mitigating the risks Monitoring the plans Getting user feedback Managing relationships with the client and the stakeholders Ending the project   Similarities between the Scrum Master and the Project Manager Project Manager and Scrum Master both are humans and they both make mistakes. But they both debug and learn from the mistakes. They both can communicate, receive feedback, mitigate the risks, and enable a great bonding within a team. Actually, neither the Project Manager nor the Scrum Master is the supreme authority. The Project Manager has to report to the client and the stakeholders, whereas the Scrum Master has to report to the Product Owner alongside the stakeholders and clients. Both Project Manager and the Scrum Master fail when they ignore the basic principles that are supposed to be adhered to. They fail when they not only neglect being professionals, but also when they are any less than skilled professionals. Sometimes, they may also fail when they disrespect the team members’ opinions. Differences between the Agile Project manager and Scrum Master While noting down the differences between the Project Manager and the Scrum Master, you will find out that the Project Manager plays the leadership role by leading a planning for the execution of the project. Scrum Master plays a support role for the team members, by working closely with the team and assuring that they are following Agile principles properly. Let’s look at the major differences between the PM and SM: Project Manager(PM) vs.Scrum Master(SM) Goals Has defined goals like- Completing the project on time, planned budget, and scope Makes sure that the team members are well trained to follow Agile practices appropriately. Also, SM coaches the Scrum teams and mentions the timeline to finish the project. Quality Assurance PM also knows the importance of quality, but doesn’t know how to achieve this. Usually, a consultant is hired to fix the errors. SM assures the quality and very well knows the importance of it. Team Size Project Managers like to make the things large. PM works with more people and a huge budget. In this way, they improve to Program Manager Scrum Master always tries to keep things smaller. They like to work in small teams irrespective of budget. Average Salary Rs.1,351,403 per year Rs 1,036,017 per year Job Description The job description of the Project Manager includes- Planning, creating budget and the related documents PM has to work with upper management to ensure a scope and direction of a project PM has to work with another department also, in case of emergency sometimes have to work themselves or instruct the team to finish a goal. The job description for Scrum Master includes- Resolves barriers and controls the Scrum processes. Making a team aware of Agile and Scrum to deliver successfully Facilitates the Scrum ceremonies Ensures that a project is running smoothly with the help of the tools Executes the Product Backlog as per the Product Owner prioritization Solves team conflicts with good communication skills Motivates the team Monitors the Scrum processes to increase efficiency   Scrum Master vs. Project Manager certification The Scrum Master and the Project Manager certifications are the two most popular certifications of the Agile and Waterfall methodologies.  Scrum.org report as of 30th April 2017 states that around 110,000+ people are  Scrum certified. Only 56% of the Project Management Specialists are holding a Project Manager Certificate, even in Big IT companies. This was revealed in a survey conducted by IBM.    Last words: Deciding between the Scrum Master and Project Manager certification is indeed a tough choice and entails a careful consideration of the prospects of each. Eventually, the role of a Scrum Master is proved as a ‘deciding factor’ of the successful projects. The Scrum Master and the Project Manager both have distinct roles. Both need particular skill-sets and a right person to make the work happen.       
Rated 4.0/5 based on 1 customer reviews
5684
Scrum Master vs. Project Manager: Differences and ...

Organizations that are new to Agile and Scrum comm... Read More

other Blogs