Do you have the Product Team Mindset?

Product Team Mindset 

Are you ready to go beyond the comforts of an Agile mindset to a Product mindset. 

Over the years in IT, teams have been organized more as component teams or feature teams. Component teams were more formed around the IT investments like the mainframe group, the DBA team, the website team etc. Terms like UI teams and backend teams were the more familiar structure. 

Shown Below is an example of Component teams. Depending on the platform or IT investment like Salesforce CRM, 

These teams also tend to have ownership of the components and get funded yearly to get work done on whichever component they are responsible for. 

This structure has its own pros and cons. Pros being people become experts of a certain area over time and the main con being the automatic dependency when anything needs to get done. The agile movement of cross functional teams led to the formation of feature teams. Feature teams are still heavily IT driven initiatives where instead of having teams around features or value streams. For e.g Search feature may have many pods each pod having representation of skills that can work on the UI, the platform and a data team.  This resulted in what is now famously known as a T Shaped team. The work for both component and feature teams were funded by business teams and were prioritized mainly using gut feel by the role of a product owner. This also led to the term Full stack developer, someone who can work in many layers of the code. 

Over the years with technology like React, Angular , AWS, Azure , Kafka, Microservices , Containers etc.   It is now impossible for any one person to be a master of all stacks.The skills of the team balances out the overall skills needed to deliver the feature. 

Siloes of Product Ownership, Design and Engineering and Ops.

The feature team and component team model solved the problems for developers and testers. However product ownership, UX Design , engineering and Ops continued to work in Silos and have teams of people working in their own teams. This creates 

How do Project Based funding models work with Component and Feature Teams?

The predominant funding model for both component and feature teams is project based funding model. Each year the company sponsors key initiatives through a portfolio prioritization process. This allows for various key initiatives to be completed. 

Each portfolio is made up of initiatives/ projects which then get funded. The initiatives/ projects are then estimated and then driven by product managers and product owners in product backlogs. The approach till it gets to the backlog is very much a waterfall. 

Since the funding typically happens once a year, that becomes the general planning horizon and everything revolves around it. 

Teams end up pulling from the different backlogs and in the end everything comes down to a prioritization exercise as capacity for most organizations is generally considered fixed for any given time period. 

So the project based funding models have become shorter and organizations are taking a proactive approach to relook and prioritize the portfolio at least one a quarter. 

So here the funded entity is the Project and that pretty much drives what goes in the backlog. While it is true that funding models are not any more once a year activity in organizations, the amount of such organizations tends to be very less in no. Most still do a large scale once a year exercise. Can we rethink our teams and make them truly customer facing. The answer lies in Product Teams and also how they get funded. 

What are Product teams?

Product teams are a startup within an enterprise. A collection of teams that are aligned around a product area or a value stream. They own the entire end to end lifecycle around that area soup to nuts. This will also include sales, marketing and other functions in this group itself instead of them being in another part of the organization. Mainly there are no more two separate groups within the company business and IT. 

An example is a large investment bank in the east coast that has completely restructured its investments group where each POD consists of the sales and marketing functions, and then many teams in a POD that are aligned to a specific feature on their product like Search. 

The main difference between Project and Product teams is that

	Product	Project
Funding	Based on delivery of outcomes to the business and funding is many times a year. Funded entity here is the Team.	Projects are funded based on milestones and are typically funded once a year.  Funded entity here is the project
Teams	Long lived teams that own the entire business outcome. More like the Amazon model of teams with a Single Threaded Leader	Teams are formed around projects,
Who owns	Team is part of the business unit.	Generally IT owns Projects
Customer facing	Yes , this is the big difference	Sort of through the proxy of business stakeholders and product owners
Silos	Same team has business, product, engineering and design and team members are encouraged to learn each others skills	Clear separation between Business, Product, Engineering, & Design Siloed skills

Many IT organizations that are now doing agile and devops practices well, are still struggling to deliver value and aligning teams around the product areas and giving them full responsibility is not new to companies like Amazon, for large enterprises this is still a challenge yet to be solved. This requires a complete mindset change from the entire enterprise and also needs teams to step up and learn newer ways of working so that they can directly engage with customers, own specific areas in the value chain/ user journey. This also brings new challenges to large monolithic architecture in favor of more microservice driven , micro front end architectures that enable rapid development at scale. This also requires leaders to reimagine how they have designed the organization, and trust the teams more to deliver to outcomes than output. 

Are you ready to imbibe the Product Mindset?  Learn more about moving your group to a product mindset ? Learn how to redesign your portfolio to create product teams aligned around customer journey / value streams. 

Contact us at contact@agilists.co and learn more how to go about this change in a predictable way. 

Scrum Your Meetings

How can we make our meetings productive. This is a billion-dollar question. Even if each one of us improve our meetings by 1% we save $$$ s for our organizations.

In this article, we look at one such technique called  Scrum Your Meetings:

Why Scrum Your Meetings:

In the first few pages of the book called Design Sprint, there is a picture which is worth million dollars. ( Picture modified a bit based from the book)

Normal Work Day for Most Companies:

Scrum Your Meetings Version

In the teams I have been recently we have been trying this and seeing really great results.

How do we Scrum The Meetings :

Work the Work is one way to think of this. The host of the meetings invites people. Recommend time not more than 60 minutes for a session. The goal is what can we get done in 60 minutes.

Step 1 - Goal Setting 10 minutes

The hosts present what is the goal that we are trying to achieve as a team in the next hour.

Notice the way the doing column does not have any more than one task for the team. This style of work is called Single Piece workflow.

Sometime you may do more than one task but as a general rule Don’t to start anything that cannot be done in an hour. 

Step 2: Close IM, phones , chats etc.

Step 3: Start Task ( Swarming around the first task )

The entire group works on the first task. Sometimes this means we are talking, sometime we may be writing a document, it depends on the work.

Suppose our goal is to create some document, we can start a shared document on google docs, or word docs and share it on a large screen. The first person types and others contribute to the document. You can also try a variant of this called Mobbing.

At 10 minutes the keyboard moves to the next person. Complete first task and pull next one. This way everyone has to work and no one gets to chill back and just talk.

Step 3: Close with action items or parking lot items

Conclusion

What if we can actually go home and eat dinner with the family and not worry about work. Imagine how much we can save by not context switching Every time someone randomly pings you in a chat, you are going to get distracted from the work you are doing now.

This kind of working even if your teams can practice once a week and once a week do a no meeting day. You will see infinite improvements to productivity and you will see many satisfied employees returning back home with a smiling face every day.

–Go for it , be the change and make it happen

What is the role of HR in the Success of an employee in an Agile Organization?

In Organizations that practice Agility, there is a growing need now to reimagine the role of HR. In this article, we see just from an employees perspective areas when HR interacts with an employee during the employee life cycle.

Mark has worked for 12 years. He has a masters degree. He is well respected in his field. His skill is sought out in the industry and he is really happy with what he is doing.

Employee Lifecycle

Let’s look at this lifecycle where typical involvement of HR happens.

The term human resources is a challenging one. Irrespective of what we call this group its what this group does that can make a huge shift to an Agile Organization.

Recruitment:

In most cases, if you are really good at what you do, you probably have a good job. So if you are a recruiter who is hiring for experienced professionals you need to do a lot more than just searching for profiles on job boards or LinkedIn. Most experienced recruiters have a tactic of approaching candidates, and over a period of time, getting them to think about possible future opportunities.

A few years back, I had hired one of the best Agile recruiters ever. As soon as she joined, all of a sudden our recruitment pipeline would look really good. She would organize events that looked more like meetups, and in those meetups, she would invite some of the candidates she was targeting either as a speaker or an attendee.

Good recruiters make the whole process seamless. Every small detail would have been thought through. Each email that goes out or the phone call has a fun human touch. Even when people are not hired, they would get an email why they were not hired, and what would they have to do to get hired. We have had numerous cases where people would come back after months saying, I completed all the items in the list, now hire me.

On-Boarding New Employees

Why do we celebrate only when people leave the company? While we should do that, why not make a lot of noise and make someone feel awesome. on the day they join the company.

Here are some ideas to make Mark’s first day memorable.

• Send Mark something he/she likes a few days before they start.
• Stand with your team and clap and invite Mark as he joins the organizations.
• Keep paperwork on day 1 to a minimum.
• Laptops should be ready when they arrive not after a few days.
• Keep a task board of things they have to do and give them a few days to complete the work.
• Don’t bore them with corporate training on the first day. let them do the work they joined to do.

Professional Development

Most work not always but in many cases has come down to teamwork. Every employee needs to set for themselves a few goals and they should be measured on reaching those goals.

1. Goals to help grow self.
2. Goals to help the team
3. Goals to help the organization.

Separate feedback systems from Financial Incentives. Dan Pinks Drive  Drive: The surprising truth about what motivates us. Are you creating ways in the organization to encourage Autonomy, Mastery, and Purpose?

Minimize Titles, Promote roles instead. All organizations do need some sort of internal numerical systems, which should only be used for salary purposes. In some organizations, these levels are given so much importance that it ends up killing creativity

Retention

It’s easier to hire new employees but tough to retain them. Each person has many reasons to work. Most of us work to get paid. But beyond that, we work to use our creative mind and make a difference to the community around us.

People leave when they have a bad boss, and when work does not motivate them anymore. This is where leadership role is critical in creating organization systems where people have the freedom to work, but are working towards clear goals for the group that they are working on.

A big part of retention is the ability of an employee to feel like they own the organization.

There is a difference between happy employees and engaged employees. What you want are employees who are engaged in what they are doing and hence happy doing it.

HR can play a critical role in creating 360 feedback systems, happiness surveys, enabling organization-wide collaboration tools. video conferencing systems, work from home policies, timesheet only for billable work, open PTO,

Exit

When people decide to leave, support them. Don’t try to stop them. There is a reason they are leaving. Treat them as future customers, future employees. Ask them in the exit interview what the company could have done differently . In some cases, employees do leave just because they are following the money, and those kinds of employees who are only motivated by money are better off to leave.

What you don’t want to lose are those dedicated employees who would not have left, if they felt they had been heard, they felt their work mattered and when work gets fun, people often don’t leave.

In all of this having even one strong leader in your HR team who understand that can bring agile values to the work they do, they will make a huge difference to your workforce. Find the right leader to lead your HR group. And as you do so maybe call it Resources for Human not Human Resources.

Can Agile work for Infrastructure and Ops Groups?

Yes. Agile can work with Infra and ops groups. This article outlines some basic principles during your agile transformation journey.

When an organization gets more and more Agile soon they realize that one of their bottlenecks in their own IT operations department. With the concept of physical datacenters slowly moving to the cloud the nature of work done in operations groups are also changing drastically with time.

The DevOps movement has been successful in moving parts of the operations, upstream so that the engineering teams can mostly be self sufficient and not have to deal with handovers and delays due to large wait periods before things get deployed. Concepts like SAAS, IAAS, PAAS, Cloud etc fundamentally changed the notion of network engineers, DBA and many roles that were typically there in classical IT operations groups.

Organizations that have tried Agile in Operations are moving from processes like ITIL and are heavily invested in specialized skills, network engineers, DBA’s etc.

Here are some pointers to transforming your Infra and Ops group to an agile organization.

First things first

1. Identify all the Service Lines that your group supports and align cross-functional scrum teams around these service lines. For large services, consider using the concept of PODS which compose many small cross-functional feature teams. Set up Scrum of Scrums across PODS. These teams can follow a Scrum or Scrumban model of working. Use dedicated Scrum master for a team or an agile coach for a POD model . Teams need help during the change. Don’t ignore this role.
2. Identify one or more product owner for the service lines.
3. Move some of the operations folks upstream to directly work with engineering teams to enable DevOps and provide the necessary automation required to seamlessly deploy to production.
4. For incidence response teams, involve the actual dev teams in the process. The first level response teams may not be able to use Scrum as most of the work they do may be demand based.
5. Streamline ticketing systems so ticket duplications in systems like Service Now are removed. The same ticket should be used by teams to solve the incident. In earlier organizations since the org was siloed each group had its own ticket ending up in a lot of duplication and coordination of work.
6. Education for leadership and middle management is key.
7. Consider rolling this change to the entire org in some sort of structured manner using internal and external coaches so that there is minimal disruption to the operations.
8. Set up leadership impediment board to relentlessly remove impediment across the organization.
9. performance measurement systems should be changed to encourage more cross-functional learning than a siloed expert based learning the culture.

Scrum Essentials

What is Scrum?

Role:  Scrum Product Owner

Role: ScrumMaster

Role: Team

Artifact: Working Agreement?

Artifact: Product Backlog

Artifact: Sprint Backlog

Artifact: Definition of done?

Artifact: Definition of ready?

Event: Sprint Planning Defined

What is the most important role in the Scrum team?

Paper napkin design?

What is MosCow Rule?

Measuring success in agile projects?

How do we do effective Daily Scrum?

How do we select velocity?

How do we measure productivity?

What is 13 forms of leadership?

What is the relationship between user stories and use cases?

What is a story point?

Can we change the length of a sprint?

How soon can we see improvements when we start using Scrum?

How can I estimate on something I know nothing about?

What are different techniques to size stories?

What is a ScrumMaster mission statement?

What is a book list for agile teams?

Is there an Agile meeting cheatsheet?

What is a ideal source structure for a .NET project that is agile?

What are product owner teams and how do we set them up?

What is metascrum?

What is the relationship between story point and complexity?

1. What is a self-organizing team?

Agile Metrics

This article presents guidelines and examples of metrics you as a leader can help set for the group or team

It is really important that an organization does not measure only to demonstrate to others in the company that things are getting done. There is a false sense of comfort in these metrics. It is important to measureless.

“Remember – What you measure gets done”

–Attribute pending

5 rules when selecting metrics: ( VOIRS Rule)

• Make what you measure, is Visible.  Everyone should be able to see what is being measured. Customer satisfaction survey results -outcome metric, velocity – output metric. A good mix is always required.
• Outcome driven metrics always produce better results that output driven metrics.
• Make it Inclusive – let those who you want to measure have a say on how they want to be measured. Get input from teams. If you get buy-in from teams then metrics makes a lot of sense
• Make it Real-Time. – If metrics need translation by humans in an excel sheet there is something wrong with such metrics.
• System metrics are better than People metric. Measure more of how the system is doing and less of how people are doing.

Measuring Process Effectiveness

Measuring ability to reach Strategic goals at a regular cadence

Any product or service organization has business goals. These goals are often things like  ( in this case we have shown an airline example )

• One Integrated Airline Booking Experience
• Reduce customer complaints by 30 %
• The launch of 4 more cities for new flights.

When it comes down to the teams these goals are compounded with so many other little internal goals etc that somewhere along the lines, the big picture goal is lost. So leadership job is to regularly communicate these goals and make sure everyone in your organization is focused around these key goals. There will be other things but many times those other internal work items slow down the more important strategic priorities.

In the example above 9 different epics have to be done to get the three goals achieved. Each epic could be made of many many smaller epics or smaller user stories or backlog items.

So how do we measure things from here?

Metric – Lead Time – This is the time when the requirement was first identified in the organization and added as the core component of the strategic initiative to the time it was actually delivered to the customer.  Tools can do this easily. The difference of end and start is the lead time.

Monitor “Cycle time”.

Cycle time is the time taken at each step. in the doing column. Time from the time some work start till it is finished. The customer does not see it

Lead Time is = Sum of Wait Times + Sum of Cycle Time. In this case, we are taking Cycle Time to be the actual Value Add time. Really go and figure out where waits are in the process and help remove these waits. Waits are often seen

• when people are waiting for approvals,
• Only a few people in the organization can get some things done. Remove the silos.

All the work note ” All of the work” a team does should go from one list. 

Show a live report of where these epics are at any given moment

Measuring Agility.

How do we know how Agile we are. It’s surely not a gut feeling or some massive assessment. Assess systems, not people. Using Agile Principles as a measure of Agility.

http://agilemanifesto.org/principles.html

Shown here is an Agile Principles Card. Have each team sort through the 12 principles from “Yes to do it” green or no we don’t do it ” Red”. Collectively prioritize the red ones and then come up with action items as story cards to move items from Red to Green.

 

Measuring Product Effectiveness

Customer Satisfaction 

If you have a good product you should see higher customer satisfaction. Regular customer feedback collected real time from customers should be shared as is with teams that produced that feature. A much-debated technique is called Net Promoter Score. It is just one measure and should be used for what its worth. A point of reference.

Amount of features in the product that is actually used. 

80 % of the features we produce are hardly used. You could use the four categories in the Kano Model https://www.mindtools.com/pages/article/newCT_97.htm

Every product manager should know how many of the four categories of features they have from the Kano Model in their product

As per this model, every feature can be categorized into:

• Mandatory features – Must be present in order for users to be satisfied.
• Linear Features – The more of this is better
• Exciters or Delighters – These are not the reason we buy a product for. A feature she does not know exists until she uses it.

The image above is from http://foldingburritos.com

Mandatory Features – Customers are quite indifferent to must-be featured. For Eg Do you ever buy a phone because it makes a phone call?

Linear features – Customer satisfaction is more around linear or performance features

Exciters or Delighters – These are huge pluses to customer satisfaction. For eg the first time Gmail said, Hey you have forgotten to attach a document when your document says something is attached.

Collect data about all the features in the product broken down by the three categories in real time. This can be achieved when you tag epics as a Linear, Mandatory or Exciter in your Product Backlog tool.

 

 

Measuring Leadership Effectiveness

A #1 reason for Agile to not be as successful in the organization is due to lack of middle management support. See State of Agile Survey By Version One. 

 

– the picture above is from State of Agile Survey By Version One

As you look through the list, it is clear that effective leadership can actually help resolve a lot of these challenges listed. So how do we measure effective leadership?

• Are leaders solving daily the biggest impediments of the organization? Are they helping daily?
• Are they delegating decisions down where information exists and don’t punish people for making decisions?
• Are they setting clear boundaries for teams to operate in?
• Have they separated feedback from performance reviews?  Feedback should be routine not drama.

This can be collected from teams from regular automated surveys or 360 feedback. Leadership effectiveness is a much bigger topic that we will surely address in a later blog.

Conclusion:

This article presents very few metrics mainly around three categories Process Effectiveness,  Product Effectiveness, and Leadership Effectiveness.  Note that velocity is an output indicator and not good to measure effectiveness. It can simply be used to predict future dates that is all and it is a lagging indicator.  Also, note that it is important that all of this be automated and be touch-free leaving nothing to interpretation. Also, this is the main metrics that should measure and it’s really up to you as long as you pay attention to  VOIRS rule. 

Make it useful, measureless, get more done….

What does a Manager do in an Agile Organization?

This article covers the role of a people manager in the context of an Organization. There is a lot of data on what Product Owners do, Scrum Masters do etc. However, when someone takes over the important role of People Manager, there is confusion in teams from a refusal to listen to the manager, to a feeling that the manager is micromanaging.

If you have taken over the role of an Agile Manager or an Agile Engineering Manager this article is an attempt to help you with your new role.

First, let’s cover the list of things we should stop doing.

• Don’t feed work directly to the team. Instead, route it through the Product Owner. 
• Stop asking for Status Reports. Instead, go to the team room or virtual team room, listen to their standups etc.
• Stop calling meetings. I know this is an extreme claim but think about it. Do you really need this meeting?
• Change or add team members without the team’s explicit permission. 

Now take a minute to see this video about turning the ship around by David Marquet

 

Set up an Impediment Board in your office. Tell your teams that you commit to working on the impediments any team member brings to you. An impediment is anything that blocks your team from getting their work done. First, check with ScrumMaster of the team what impediments he/she is solving for the team. The ones they are not able to solve are yours to solve.

Protect Teams Time – By asking teams to practice the concept of “Core Hours”. Core hours is the time members of an Agile team commit to being together. Add a rule in the organization that no one except team members can disturb the team during core hours. The team when in core hours may not respond to emails, chats etc.

Spend Teams Time Judiciously – Most teams now ( 2016 ) get only two to three hours of productive time at work. What if we can help create a system where teams spend most of their time doing value-add work as a team.

Don’t optimize your group for capacity, optimize for value: 

Behaviors in an Agile Delivery Team

As a Team Member of an Agile Team, we are always looking to understand what behaviours we should encourage and see practised within a high-performance Agile Team. Here is a list of 14 behaviours that as a team member you should model. I once learned this from an Agile expert. Be the example you want others to be.

1. Instead of complaining always having a “Bias Towards Action”.
2. Watching out for team members who need help and pairing with them to get work done.
3. Not blaming others outside of the team for what the team has done.
4. Taking the time to understand users.
5. Letting go of control and Trusting the team to get things done.
6. Making sure no one works on things that do not fit a sprint goal.
7. Not working on one-off projects without others knowing about it.
8. Giving the team enough free time and not demanding overtime all the time.
9. Coaching each other on how to receive feedback
10. Saying No and saying “If it’s not in the backlog we don’t know”.
11. Not compromising on quality.
12. Being on time.
13. Following core hours as a practice to do work.
14. Making sure everyone in the team is giving open and constructive feedback

Looking Beyond Large Scale Agility

After being involved with a group that is probably the most Agile anywhere in the world, seeing hundreds of companies over the last decade trying to become Agile and so miserably at that, or after having taught Leadership, Kanban, Scrum and Agile Engineering workshops and finding that the same problems exist in organizations that existed a decade ago, I am really starting to wonder if its time for us all to really Look beyond Large Scale Agility.

If you are in an organization that is busy implementing Agile Change frameworks like SaFe, Less, Dad, Nexus etc you may be wondering

• How all of this is going to improve your life. ?
• What is going to happen to all the hard work you have put in this organization over the years. ?
• Is your company getting better or worse?
• How are you going to make more money and be happier?

You are not alone. The issue I have come to realize more so lately is one of Scale. Agile is heavily dependent on people, less in the process. Yet most companies we work for are heavily driven by the process and profit  Have the meeting madness. Leaders are incentivized to drive down cost. The pressure of shareholder satisfaction makes things tough to change.

Agility tends to work well in smaller groups. If your organizations are really small say 50 people, it’s really tough to implement Any kind of Framework. Pretty much the culture is one of “Get it done”. From 100 to 150 People scale All these things work beautifully. More than that you are in the “I am not sure this is working Zone”.  Dunbar’s Number posits that 150 is the number of individuals with whom any one person can maintain stable relationships.

What we need is

• Sess – Small Scale Scrum  NOT Less – Large Scale Scrum
• RaFe, Right Agile Framework NOT SaFe Scaled Agile Framework

The fundamental issue in scaling beyond 150 to 200 is a simple one of coordination and one of leadership mismatch. At a scale of 150, you often have a group leader of some sort. The culture of this unit really depends on this leader. See this HBR Video that talks about 8 kinds of company culture.

If you see the video you would see one of the top kind of culture is Results Driven.

I would expect every profit driven organization is results driven. See the video above.

Every kind of organization should be results driven. So that means leaders are incentivized to get results.

Shown below is a typical organization where leaders are incentivized to get outcomes. Most of our organizations look like this. Broken by some sort of functional groups. Here shown are two Blue could be Sales and Marketing and Red – Could be Products. L (A) who is the leader for both the groups has to make sure the L(B)’s are incentivized correctly in  order to extract maximum results from the six leaders who in turn, so on and so forth

The book Leadership BS from  Jeffrey Pfeffer, a well known Stanford professor calls our many of the issues with leadership today. He goes at why leaders are actually not honest, not authentic, and not modest, do not often tell the truth, doesn’t build trust, and do not take care of others. In organizations such as the one above where top-down leadership is practiced, there is more of order following rather than ownership. Even if leaders really want to be Agile, The system is set up against them.

People who actually do the work are so far away from the real customers that they don’t have a clear understanding of what problems they are trying to solve for customers, are not empowered to decide anything without explicit permission from the leaders. In such organizations meetings is the norm as the person above has to delegate the work down, coordinate across different groups. Hence the normal problems of excessive meetings are seen in these organizations.

See this amazing Ted talk about what happens when leaders create an epidemic of meetings in organizations.

So how can we be Agile? Really agile. Agility is really about
– profitability of the business,
– Engagement of employees where they are empowered to solve and innovate for customers

It starts with three simple practices
1) Small groups that are direct customer facing creating a startup like a mentality in these groups
2) With a heavy focus on good solid agile engineering practices and a culture of teamwork.
3) Where leaders are elected by those they serve and are now serving than leading.

It’s really about Product or Service Agility. Are we creating products or services that delight our customers? We really cannot change org culture esp if your organization in more than 1000 people.

But we can do a lot of magic in the 125 range.

You can make a huge service to your organization by creating worthy leaders who are trained to lead from the side. The leaders can create a culture where truly the time of the team is protected so that they do not waste even a minute of their time in meaningless meetings, instead of by working together to creatively solve customer problems.

Share your thoughts and experiences on success or failure trying to implement large scaled Agile.

Practicing Scrum Well

Just like any sports team. there can be the winners like the ones who go to the super bowl, or those that get kicked out each year right before the playoffs even start. ( If you don’t know American Football you may not get this point. I live in Seattle where football is a big deal ).

Anyways, it is up to the team and the coach to work together to produce a great product.This simplicity of Scrum becomes the reason where teams feel Scrum is not working. 

There are some necessary conditions for doing Scrum Well.

Energized And Empowered Scrum Team – On top of the list is how energized and empowered team members are to ship quality products out of the door.

The entire goal of Scrum is to create a direct relationship between the stakeholders who seek value and the people to can create value.

There should be a Culture that Values Transparency – In Organizations that do not value truth and transparency, Scrum may not add much value.

Management does not micromanage – Top down command & control and the Scrum culture of openness and honesty often contradict each other. In fact, more than 50 percent of Agile Transformations today fail because of the middle management’s inability to let go.

Have a Sense of Urgency: Scrum works well when the organizations feel the urgency to do things faster, and of higher quality. In places where there is no pressure to ship anything and where quality is not important, Scrum does not work well.

Jeff Sutherland, one of the co-creators of Scrum Suggests the following steps

1. Get Started with Stable Teams.
2. Look at Yesterday’s weather to successfully pull backlog items into a Sprint.
3. Swarm with One-Piece Continuous Flow.
4. Allot time for interrupts and do not allow the time to be exceeded during the Sprint. See Illegitimus non-Interruptus Pattern.
5. Write Daily Clean code by following XP Practices.
6. When things go wrong do something about it immediately (See Emergency Procedure).
7. Find out what one improvement will increase the happiness of the team the most, and implement that improvement in the next Sprint.
8. How do you get teams to have fun? (Happiness Metric).
9. Teams that finish early accelerate faster. Take less work into a Sprint.

Ref: http://www.scrumplop.org

Sometimes the teams give up on Scrum too soon saying “Scrum is not working, let’s try the other new framework”. You should try Scrum for at least one release cycle or a few sprints before changing anything. 

In this early stage do not change anything. Scrum is really good at exposing the mess in an organization. If your organization is afraid to fix the mess Scrum exposes, then it may be tough to use.

Remember the 10 things in Scrum are the simple rules of Scrum. Don’t change them.

Also, there are many other techniques e.g., Kanban. Feel free to evolve your process and use other Agile Practices as well.

Scrumtuphobia!  Fear of doing Scrum Wrong.  HENRIK KNIBERG

As a general guideline, as you master Scrum, you can always subscribe to practices from any of the Agile frameworks to become Agile.