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?

333
  • by Ardita l
  • 07th Aug, 2018
  • Last updated on 13th Nov, 2018
  • 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

A Leader’s Journey: The Path from a Scrum Master to Agile Coach

Who is the Scrum Master?  The Scrum Guide defines the role as someone who upholds the values and principles of Scrum, someone who helps the rest of the team understand Scrum theory, and who supports their growth and maturity as individuals.  Not everyone can perform this role as the skills required are not easy to learn or master. It’s not that being a Scrum Master is hard, however, many people who take this path do so without a full understanding of what it means to be a Scrum Master.  So, what exactly is a Scrum Master?  How to become a Servant Leader?  John Maxwell, an author of numerous books on leadership states that being a leader is being someone of influence. What does this mean? Being someone of influence is someone who others come to depend on to help them grow as individuals and as members of a team. The leader influences them in some way to unlock their own potential.  Is Scrum Master the lifeline of Scrum?  A Scrum Master undoubtedly has to be an expert in the Scrum Framework.  However, being the expert at Scrum, and upholding its values and principles is not enough.  A Scrum Master has to also master being a leader and a coach for the team he or she serves.  The Scrum Master is a coach to the Product Owner, influencing her in ways to better her craft so that she can get better at maximizing the value being delivered by the team.  The Scrum Master also strives to be a coach to the organization, helping and influencing leadership to change their behavior from a command-and-control mindset to one where they also practice servant leadership, and develop their leadership skills and become people of influence.  All these do not happen after a two-day certification class.  It takes years to develop the coaching skills necessary to move from an expert in the Scrum Framework to a team coach, helping influence and shape a high-performing team, to coaching an organization, influencing leaders to improve their leadership skills. Many Scrum Masters will stay content in team coaching roles as it’s an extremely important one to fill, and many others will progress along a path to becoming an Agile Coach, someone coaching multiple teams, to an Enterprise Coach, coaching an organization.  The model, pictured below, from the Agile Coaching Institute, visualizes the coaching modalities required to be a successful coach (and leader).  The coaching modalities are colored in red.A Scrum Master, often called an Agile Team Facilitator, should be someone who is an expert facilitator, no easy skill to master.  Professional facilitation courses are available to help new Scrum Masters hone their skills, and Scrum Masters are encouraged to hone their craft to become master facilitators.First Facilitation → next Agile CoachAccording to Sam Kaner, the author of the “Facilitators Guide to Participatory Decision Making”, a facilitator “is an individual who enables groups and organizations to work more effectively; to collaborate and achieve synergy.  She or he is a ‘content neutral’ party who by not taking sides or expressing or advocating a point of view during a meeting, can advocate for fair, open and inclusive procedures to accomplish the group’s work”.  Facilitation, in my view, is something that takes years to master and can serve the individual if their career aspirations include coaching, teaching, and mentoring. All of these modalities require the person to be an excellent facilitator, as facilitation skills play strongly in all of them.For a Scrum Master, it’s important to work on facilitation skills, however, it’s not necessary to be an expert facilitator before taking on coaching, mentoring or teaching.  In fact, as a Scrum Master, you will be expected to mentor and teach your team, and to coach individuals.  Mentoring vs Coaching  When taken in an Agile context, the Agile coach is there to partner with their clients in a thought-provoking and creative process to help them change their mindset and approach and influence people in their organization to work in more Agile ways.  Mentoring, from an Agile context, is to share your knowledge and experience to offer your mentee’s choices and options from which to choose. Choosing a mentoring stance is something that you gain with experience.  And finally, Training is something that a Scrum Master will need to hone and develop their skills in, as it requires equal parts facilitation and mentoring to deliver effective training that people will learn from and remember.  In summary, a Scrum Master has a lot to master besides knowledge of the Scrum Framework! It may seem daunting at first, however, the key is to embrace the role and hone your craft as a facilitator as this forms the foundation for all the other modalities that make for a great coach and leader.  A typical path from Scrum Master to Coach may look something like this:As a newly minted Scrum Master, you’ll be expected to focus your attention on the team and the individuals on the team.  You will be facilitating all the team ceremonies while honing your mentoring and coaching skills in the process.  You will also be exercising these skills as you conduct workshops and more formal training for your team, and possibly other teams in the organization.  Don’t shy away from these opportunities; they will allow you to become better at being a Scrum Master, and a leader.  Remember that leadership is nothing more than influence, and having a mastery of these coaching modalities allows you to wield considerable influence on the people you serve.  As the team matures through your leadership, and as you mature as a Scrum Master, you will be ready to take on more of a leadership role for the organization.  You may focus on multiple teams as an Agile Coach, providing mentoring and coaching for new Scrum Masters, or other roles in the team. You may be conducting more workshops and training for the organization and possibly creating your own content for delivery.  You will be developing mastery in one or more of the coaching domains as pictured in the coaching model and will be developing expertise as a Business Coach, a Transformation Coach, or a Technical Coach. Business Mastery, as the name states, allows you to focus your coaching and leadership in Product Management, and other aspects that run the business. Transformation Coaches focus on all aspects of organizational change, while Technical Coaches roll their sleeves up, and work with technical teams to help implement DevOps, Continuous Integration and other technical enablers that help the enterprise accelerate delivery.  Take advantage of coaching boot-camps available commercially, and attend local coaching meetups.  This will give you the opportunity to meet other coaches for mentoring and coaching opportunities. Remember, the more opportunities you have to coach, the better you will be at it.And finally, the picture above depicts Enterprise Coaches as the pinnacle of coaching from an Agile context. These coaches have mastered all the coaching modalities, are experts in Lean-Agile, and have mastered at least one of the domains pictured in the coaching model. Enterprise coaches as master facilitators, and expert coaches who multiply their efforts by developing others to be great leaders and coaches.  So, go forth and become great Scrum Masters, as this role is foundational to great leadership.  In my view, being a coach is being a leader of influence. You will be able to help your organization stay nimble and adaptable through your leadership and coaching influence.
Rated 4.5/5 based on 2 customer reviews
A Leader’s Journey: The Path from a Scrum Master...

Who is the Scrum Master?  The Scrum Guide define... 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 9 customer reviews
2669
Scrum Master vs. Project Manager: Differences and ...

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

Built Instability Fosters Innovation New Product Development

As funny as the Calvin and Hobbes comic is, it conveys an important message about how creativity and chaos almost always go together. In 1981, when Honda was developing Honda City – the innovative first-of-its-kind compact car – an executive in charge of its development remarked, “It’s like putting the team members on the second floor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” Haven’t most of us experienced this at some point in our lives? The idea of “built-in instability” was first published in a 1986 Harvard Business Review paper, which kicked off the Agile movement. The paper names built-in instability as a top quality of new product development at leading companies such as Honda, Fuji and Canon. Well, what does built-in instability mean? Why is it important? How does it help teams succeed? Let’s address these questions one by one. What built-in instability means When a company’s top leadership does the following: establishes a broad but extremely challenging goal, does not provide a product definition or a work breakdown structure, AND offers the project team ample room for experimentation and failure … this is called built-in instability. The leaders have basically created an environment of constructive chaos to serve as a catalyst for creative output. Why built-in instability matters Honda’s leaders instructed the Honda City project team to develop “the kind of car that the youth segment would like to drive.” Do we see a goal here? Yes. But is the goal well-defined? No. Do we see what kind of product is expected? Uh, maybe. But do we see the steps to get there? No. With a goal like that, the only way leaders can expect the team to succeed is by letting them fail – to fail early, fail often, and fail forward. When a team has the freedom to fail and knows there isn’t a firing squad waiting down the road, it begins to break traditional boundaries. And companies that thrive beyond decades or centuries with avant-garde products do not get there with traditional thinking. This is why built-in instability matters. How built-in instability fosters success Look at the Honda City team’s goal again: to develop “the kind of car that the youth segment would like to drive.” A broad goal like this naturally demands cross-disciplinary work across a broad spectrum of organizational functions – market research, finance, planning design, production, testing, sales and service. When the team wants to succeed while having the luxury to fail, the built-in instability fosters collaboration among individuals from various functions. In the words of a member of the Honda City team: “You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand. If everyone understands the other person’s position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.” In sum, what we today use as Agile/Scrum or other modern methodologies essentially relies on built-in instability. By giving teams the freedom to fail, the process encourages a DNA of experimentation, learning, innovation and continuous growth.
Rated 4.0/5 based on 20 customer reviews
1245
Built Instability Fosters Innovation New Product D...

As funny as the Calvin and Hobbes comic is, it con... Read More

other Blogs