Distributed team
Regulated environments e.g. healthcare

Working with technologies without Unit Testing as a standard
Working with technologies without Standard practices / framreworks
Developer not understanding the basics of programming.

How do we start estimating with story points when we don’t really know what they represent yet?

Explaining what a point is, how “big” it is, management trying to compare different teams by point values, and all other things related to “Well just how much TIME is that?”

Too much discussion about following rules and techniques
Focussing on getting the velocity to be the same on each sprint
Postponing going live and delivering too long to ‘internal stakeholders’
Forgetting it’s about teamwork, value and smooth flow
Forgetting to involve the customer or user because the PO is the single point of contact

Misunderstanding of what a Sprint is - a milestone, it is not.

Ensuring development is also Agile - common dangerous assumption is that all developers are Agile. No point doing Agile management, with bad development process.

understanding the user environment while doing fast paced development
integration of specialists
stability requirements of the business

Skills lacking in Scrummaster and/or Product Owner - usually highlighted after it becomes clear that the overall vision isn’t clear, and that Sprint backlog’s tend to just spillover into the next Sprint by default.

@Kev McCabe Nicely put :) In other words, methodologies don’t work like magic - you need the skills and observe good practices.

* Scheduling time for exploratory projects, or other longer-than-a-sprint, we-dont-yet-know-all-the-subtasks projects.
* Strategies for handling unexpected firefighting during a sprint. (‘We didn’t set aside 2 days for fixing an issue, but had to do it anyway, now our sprint is running behind, what do we do?’)d

Estimation in story points (and prior to that, understand what they are)
Technical skills and excellence
Change management
Accept planning is reliable with story points by tracking velocity
Travel light (documentation)
Agile in a contractual environment

How to connect with the business and keep them involved.
How do you compare the business value of user stories from different projects, with different stakeholders.
How do you manage projects in a complex application landscape.
What to do when there are a lot of different stakeholders.

Our development team moved to Scrum two years ago and we are practised enough that we can now deliver predictably at a consistent level of quality and cope with change easily. 

Unfortunately it turns out the waterfall wasn’t just pointless scenery, it was being used to hide the fact that “the business” have no idea what they want us to do and were kind of relying on whatever we produced being a year late and wrong.

Our Product Owner does not make decisions. He (she) just translates info through him(her)self.

How to respond when my [manager / client] insists on knowing when the project will be done.

Having the wrong people on the team! When standing up an agile team, companies should allow employees to opt out if they are not interested. You can’t expect a commitment to change their entire mindset/way of working if employees are being forced. It’s all about the people.

The product owner is not present on site and does not have time to work with the team very much. Neither does he take the real responsibility of the PBL.
Creating good right sized user stories is very difficult.
Scrum Masters often do not really understand when and how to act or not act.
Teams don’t have the necessary practices in place to be agile, e.g. Automated tests and one click deployment.

How do we fit in UX design iterations into agile? Where does the designer fit in, on the team or the product owner side?

(I have my recommendations, but this is what we struggled with the most.)

I was assigned Scrum Master of a team in the past months. These are some of the things I found challenging:

1. Development efforts in which team members are “allocated by the hour.” Such scenario requires the alleged “precision” that story points/ideal days try to dilute.
2. Product Owners that cannot think of themselves beyond a “Project Manager” role. They cultivate no vision and they are just “Product Clerks.”
3. Need for accurate estimates for invoicing/billing processes.
4. Vertical mindsets (“the leader does the thinking, we are testers/programmers”) that make the participation of all the team in meetings more difficult, since the leaders are the only ones fully focused.
5. Amount of perceived rework as substantially higher since many “architectural concerns” are not discussed immediately because they are not necessary for “the minimum thing that works.” It takes experienced designers to keep the amount of rework and speculative features balance under control.

* Product owner has a habit of running the standup meeting.  How do we prevent this?
* Standups being used as a management status report (not for the team).  More of the same above.
* Product owners tend to want to micromanage.  How do we encourage our scrum master to prevent this?
* User stories written with specific implementation.  How do we get our product owner to write stories that explain the problem/feature request?
* Product owner designing the application. 
* Product owner overseeing what tasks developers take.
* Some developers choose poor implementation.  How do we enforce good code when the ‘natural leaders’ don’t have a supporting title?
* Every release ships with horrible bugs.  How do we prevent this, while still meeting our commitment?
* Product owners often don’t allow developers to meet without an official meeting request involving them and members of QA.

How to really integrate user-experience design including user-testing, etc.  I think there are various approaches that folks have adopted, but for the most part they break the “vertical slices of functionality” by splitting a user story along functional lines.

That is, the most widely adopted approach seems to be to have UX design run a sprint ahead of development. That actually works relatively well, but it certainly makes things a bit messy to track. You can also end up UX design for features that never get built, among other things.

The alternative of trying to do UX and development (on the same feature) in the same sprint is equally problematic.

I have yet to see a really convincing and coherent solution to this. Most books on Agile avoid it entirely, or treat it in a very superficial way.

- Agile is isolated to the dev team but the rest organization continues to function “the old way”.
- Financial forecasting and budgeting ahead for a full year make being “adaptable” challenging.

Distributed team, half writes unit test & tries to do TDD, the other have writes no unit test at all (just “code”).

Trying to use scrum estimation & planning methods, without using agile engineering practices (continuous build, great unit test, automated regression tests, shared code ownership).

Changing sprint length. “This looks like a lot of work—let’s do a longer sprint.”

Sprints that are too long.  If it’s a month, it’s not a sprint. Two weeks seems to be a sweet spot.

Skipping, or skimping on, retrospectives. There’s enormous power in constantly identifying what does, and doesn’t work, and acting on it—every single sprint. Each change may be small, but it’s like compound interest, with each building on the one before!

Not getting to done-done within the sprint. If a story isn’t through functionality testing in a QA environment by the end of the sprint, then it’s not ready to demo. If you’re calling it complete, and handing it off for more testing, then you’ll be working on bugs from sprint_n in sprint_n+1, and you’ll never be focused on the work at hand. An agile team is most effective if it’s made up of both development engineers and QA engineers.

Not doing demos. Have a standing meeting with your internal customers where you demo what got done—or explain that you didn’t get done.

Thanks, everyone for all the suggestions so far. Seems like lots of things can go wrong! Who woulda thunk it?

Please, keep them coming…

Our product owners are project managers. They have a fixed budget so we don’t deliver features, but the entire project. There is no priority, the PM’s job is to get the entire project to production & and not the highest value features.

the developers adopting scrum but the organization ensists using a “traditional project manager” who things totally waterfall. The challence i have as a scrum master is to prevent a misuse of scrum by the project manager who translates the velocity to show the organization when the project is done. the main challence is to get the project managers on board to choose between product owner or scrum master. In my case they don’t choose at all.

“Technical” stories should they rather be tasked and form part of a user story? Developers creating Technical stories - sometimes called a spike - and when sized it will replace a story of business value on the SBL

The whole management of the company does not support the agile transition. Adopting scrum or other agile method is only a IT-thing. Therefore insufficient support by other departments (e.g. business).

Issues around self-organisation, for both the team and ‘management’, always seem the most difficult to resolve. Coaches also have to be very aware of how counter intuitive self-organisation can feel to pretty much everybody involved. Oh, and time-boxing

Team members not allocated full-time
Assigning story points to bug fixing
Sticking to user stories in cases where they don’t work

Product Owner is too busy. Performance constraints become Product Owner team performance, leverage is not effective. Sister spent time in the political stakeholders and product owners can not be original work.

1. everybody is agile until becoming a manager
2.people love templates
3.people want to follow rules so they don’t need to think

1.when the analyst states a requirement (business or epic level) he/she doesn’t imagine what does it really means in the real world

- Regulated environment e.g. FSA regulation of trading exchanges
- Project managers at boundaries of agile team translating points into man-days or man-hours for budgetary purposes
- Project managers demanding low-level estimates beyond the next iteration
- Lack of education of stakeholders at fringes of agile project e.g. project managers, support staff
- Testers, business analysts, support not being embedded within team
- Apathy, some team members adopt attitude “not my problem if story is not delivered on time”
- Lack of hardware… chairs, desks, dual keyboards/monitors/mice

When a Project Manager migrates to a Scrum Master role, making the leap from command and control to a facilitating/enabling role.

Planning of production support and other external influences that divert the team away from the objective of the Sprint.

- Products not clearly tailored.
- Team fluctuation with many external employees. How can we get stable teams for a given product?
- Proxy POs. How can we get the real product managers involved as POs instead of representing them (also satisfying their lack of time)?
- Dispersed teams. How do we support a team forming process here, if possible?
- Distributed teams. How to overcome the lack of inter-team communication?
- Lack of management support to change the organizational habits
- Missing understanding about Scrum / Agile techniques
- Habits. How can we achieve a mind set transition from what we have done in waterfall? (huge shift for QA)
- Scaling Scrum. How do we integrate the work accross multiple teams on the same product?
- Responsibilities. In a scaled context, how do we organize such that not everybody is responsible for everything (NB: infrastructure, build, test environment, etc.) thus nobody feeling responsible for anything?
- Legacy code. How can we cope with it (maintain/rewrite/test cover) and how do we make sure new teams do feel responsible for it as well
- External employees. Do they feel and act as responsible as internal ones (considering the mid to long term effects of their actions)?
- DoDs. Why do our teams/POs not step up by themselves with setting their expectations in the DoDs? How to get compatible/unified DoDs in a multi team context?
- Sprint Planning: Why do we need a week in a multi team context to get the planning done (staggered by a day)?
- Architecture. How do we deal with emergent vs. upfront architecture in Scrum? How do we apply changes to the architecture (consult and involve architect vs. everybody by themselves)? Is there an architect role allowed at all and if so, how to involve him/her?
- Defects. How to integrate in the PB or defect backlog? How to plan them? How to deal with an overwhelming count of defects (QA sprints vs. on the fly)
- Estimation units. How to get wrong assumptions about Story Points out of teams’ heads when they were being used to confound them with time (days/hours)?
- POs are striving for functionality instead of listening to QA objections from the team.
- Organizational gravity between different departments. How do we make sure while POs are part of the PM unit, the interests of the head of development department don’t conflict but rather integrate?

What Christopher Riesbeck said.  The current mentality is that knowing when something is going to be done is all-important, even if it means that the project will take 40% longer to accomplish as a result.  So knowing how late you’ll be is more important than being done on time or early.

I have some more problems:
- The part-time product owner, very busy with other projects.
- A scrummaster acting as a teamleader (command - control).
- A product owner changing the sprint back log during the sprint.
- Team members only reporting the status to the scrum master during the daily stand up instead of telling the team what they have achieved / will achieve.
- Personalities within a scrum team are not balanced well. E.g. when there are too many ‘red’ people in a team resulting in a team with a lot of conflicts and discussions or a team with no ‘red’ people at all resulting in a team with no energy.
- Stand up meetings take too long. Some people get bored, play with their smartphone or are just standing and staring out of the window.
- Team members are very busy with work NOT on the scrum board. (No focus, lots of interuptions.)
- Team members remain in the traditional waterfall roles of tester, developer, analist etc.
- Tasks are too big. (“I am going to work 5 days on this task and it’s no use splitting it up…”) You can’t see enough progress on the scrum board.

As a scrum master, working with more than one team and all on different platforms.
Working with different teams all at a different agile maturity.
trying not to manage the teams, trying to aid in self-organiseing.

more to follow.

1. Working on legacy architectures / codebase. Getting people with experience refactoring into a good architecture.

2.Developing a feature backlog (vision) with a mostly complete story breakdown prior to having it scheduled for a sprint.

3. Getting the business to actually determine the business value for an item so that they can be prioritized against other items (doing alot of what is “urgent” instead of what is “important”?).

4. Transitioning to scrum / kanban without a coach

- Testing is still after our DONE
- Not everything is showable on a screen
- Retrospectives are getting boring
- Sprints are good but if we find a bug in the demo, we deliver on Monday/Tuesday
- Team member is dragging the team back
- Estimating is good but reestimating is seen as a waste of time
- Esimating is good but managers wants metrics and dates (planning)
- Why managers keep asking for productivity metrics?

Traditional management not understanding Agile/Scrum (command – control).

The organisational changes that are necessary to help support Scrum are not being made.

People who are not accustomed to Scrum do not understand the roles of Scrum – how often do you see the job titles ScrumMasters and Product Owners in companies that say they do Scrum? I only see Project Manager, Consultant etc.

A frequent complaint is having to break a feature down because the effort required to complete the story is estimated to be more than a sprint. The problem is that as far as the PO is concerned there is no value in part completed story which itself is deemed a minimum marketable feature.

This scenario seems to be one of the biggest criticisms of Scrum when compared to Kanban.

People seem to be the biggest draw back to the entire thing. Either people don’t want to step up and make decisions to follow better practices, or other people who are so religious they ruin it for everybody (you know: The only bad thing about Evangelical Christianity is Evangelical Christians.) So, for the first group it seems that proper motivations (goals?) are not communicated/transferred, and for the latter group it’s a failure on the golden rule of “Don’t be a d!ck.” that gets lost somewhere.

Leaving newly-minted, not-yet-mature-enough Scrum teams to the <strike>wolves</strike> self-organization and without a real leader

Roy Osherove wrote an excellent piece on that: http://5whys.com/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html

Management and organization control, planning and budgeting culture

- Culture!! It’s a mindset shift and persuading people that their old habits aren’t necessarily good habits is tricky.
- Getting BAs to produce “Just Enough” documentation - getting them out of their seats to have the conversation and seeing working software as the real output
- Working with legacy mainframe applications
- Getting developers to realise that whilst writing Fit fixtures can take as long as the code itself in some instances, it’s about the efficiencies saved in testing and in ongoing maintenance of the application.

- We haven’t implemented any scrum practices at all.  Where’s the best place to start?  What should we adopt first?  next?  last?
- Our executives like shiny objects.  How do we convince them index cards for user stories are a good idea?

We have no PO (and we must scream). Team is given old-and-busted legacy product and asked to brainstorm new features, without knowing anything about customer needs.

- Product owner is just a list maker. Has to get information and decisions regarding stories from others (in particular, their manager).
- Product owner does not maintain a Product Backlog much beyond what they want for the next sprint, sometimes even making up some stories during planning [note: just like stories need to be DONE DONE at the end of a sprint, one team I know requires stories to be READY READY for planning].
- Product owner doesn’t do project planning.
- Product owner, other stakeholders not interested in product demonstrations.
- Project initiatives that involve more than one team.
- Vocal negative team member(s). Everything that is new or different “won’t work, can’t work”.
- Estimation paralyzes team member(s) with fear of being wrong (especially when there seems to be no penalty for estimation “errors”).
- Estimation and velocity become the focus and source of tension. PO wants more faster. Team wants to satisfy this so they “try”, and “fail”. Team delivers “more” by changing idea of point size.
- Size estimates for sprint items miraculously scale to equal velocity.
- Teams believing that it is more important to do “more work” than to complete stories.
- Focus on 100% utilization (e.g. “let’s pick a database story so Bob has something to do”).
- Annual (or, tragically, weekly) individual goals. These always seem to be product related and totally out of the control of the goal owner (finish this project, that feature, these bugs, that document…)
- Team members won’t read. Anything. Not the scrum book, not the scrum guide, nothing technical, nothing skills related, not anything.
- Product owner’s manager (and other stakeholders) wants commitments for projects that equal schedule/scope/cost.
- Company has trained customers to expect project commitments equal schedule/scope/cost. Customers have evolved process where they monitor progress against schedule/scope/cost commitments.
- Company is unprepared to deal with organizational impediments that scrum exposes: teams not collocated; cubicle city, nowhere to hang even a single white board; no support for training; functional org chart, many managers weighing in; toxic team members and managers…
- Commitment to set of stories for the sprint is really just fixing schedule and scope. This commitment means that the cost of estimation “errors” will be born by the team member in either late nights or “failure” (underestimation may be deemed as sandbagging). If a team is committed to working at their best then the stories they finish by the end of a sprint are exactly what they can do, and what they would have estimated if they had had perfect foresight.

I agree with points posted by Ken Horn. Additionally -
- Belief that every project can be executed in Agile efficiently. This may be true for MOST of the projects BUT not true for ALL. Teams do not completely analyse the project methodology that will suit a particular project/scenario and decide to go ahead with Agile.
- Company may decide to execute the project/program in hybrid mode - for example, few modules to be developed in Agile and few other modules/components either in iterative or typical waterfall. In such a case, the bringing all the pieces together for successful end-to-end integration poses numerous challenges.
- Heavy dependency on talented, self-driven members for project execution and as a result, the project does not have good backup plans in case of resource absence.
- Not so robust Risk identification and management strategies - especially for projects/programs spanning one year or more. Since, the entire picture is not well drawn before starting the program and only details for next few sprints may have been charted—this activity is not covered comprehensively. Or probably this may be in cases where projects are not executed in a true agile mode - I am not sure.
- Insufficient documentation of functionalities and business rules. Products get built in a defined timeframe. However, the overall product life is much greater than the build time of the product and resources move on to next assignment after completing the build. Maintenance of the product and further product fixes is very challenging and poses difficulty due to lack of good documentation.

The most difficult problem we are in the process of overcoming is Agile estimation and planning / release planning with teams where the product needs very specialized skills and cross training resources is very difficult. This causes the total historic velocity of a team not always reflecting specialized skill based available velocities to avoid over / under allocations.

Problems I frequently encounter:
1. No Customer/Business involvement in accepting an increment. As a result: unnecessary test runs after a sprint could have finished. Most often caused by capacity problem or Business not understanding how to work with Scrum teams.
2. Testers not knowing/understanding what gets unit tested. As a result: inefficient testing at higher levels since testers are not informed by the unit tests. Also: testers seem to operate disconnected from the team. Root cause: testers typically not able to or not wanting to discuss architecture/designs/code
3. Team not quality infected. As a result teams leave testing to the tester (note that quality is a team responsibility) and testers operate as loners. Waterfall symptoms can be observed too. Root cause: developers find testing is a tester’s responsibility. Tester not able to convince devs so no team strategy on testing.

- Specialized Team Members, that are not willing / able to do all work
- Interfering Managers
- Horizontal Split of Teams: one team doing backend work, other team doing front end work

- How do we scale?
- What good is tracking velocity?
- How do we manage risk?
- How do we manage design?
- How do we define done?

The most common problem I’ve come across is managing quality. I don’t believe Agile & Scrum are less conducive to quality, but the potential is there for detrimental quality consideration. “Not releasing bugs” can lead to a slippery slope of what we call “done.” But putting defects on the backlog marginalizes the defects; they can scarcely compete with new features when measured by estimated value. And the engineers probably have less incentive to deal with them (especially if you’re counting points which is silly).

* No obvious customer: the product is a community resource and anyone is free to use it, without notifying the team.

* Team members are separated geographically, and teleconferencing is done via IRC.

* Some team members are part-time and value the flexibility of choosing their working hours.

Most of the problems we encounter are people problem. Some are process, especially the more you look to the customer related part of the cycle (That would be product owner/sponsor territory) but these problems are easily solved if the people problems are solved first. The key is (14th point of Deming’s way, I think he was an agile kind a guy!) Put everybody in the company to work to accomplish the transformation. If this is happening then many process problems can be resolved.

Since our Scrum teams consist of only developers and QA, our biggest obstacles relate to shared services (DBAs, Unix admins, Security, etc.) where they are 1) not following Agile practices, and therefore use different prioritization, scheduling, and goals and 2)  being pulled in several different ways at the same time.

Another stumbling block is that we are still working on nailing down the product management roles and responsibilities in our organization, so our PO is having a hard time knowing how to prioritize across multiple completing stakeholders.

This may seem an obvious first step but everyone in the organization should know why the organization is adopting Scrum or agile. Even better if you can explain why this is good at an individual level. Prior to adoption, individuals may be content and very comfortable with their own success or place in the organization (regardless of how well the organization is functioning as a whole).

Bringing Design and UX into a mobile sw process. These 2 disciplines claim they can only work on a waterfall model, that they have to storyboard each view first, and complete everything before they hand it off to development. Maybe that’s true (I pretty much doubt it), but that workflow bottlenecks engineering and QA at every point. I see this same problem again and again across sites. I have no answer.Would love an answer.

I’ve seen many people pay lip service to agile but they are really in denial.  Many seem to have become disillusioned yet continue to outwardly work in it because they are “supposed to”.  You end up with something that isn’t agile and that fuels disillusionment, perhaps often laziness and doesn’t really help anyone.

Examples of challenges this brings in the context of scrum often fall under the umbrella of “tailored scrum” (e.g. no burn-down, little/no backlog grooming, inconsistent ceremonies, inconsistent sprint durations, space between sprints, regular ends of sprints where less than 100% of the committed stories are delivered e.t.c.).  We know scrum shouldn’t be tailored and all these issues (or smells) lead to problems.  As soon as you see something other than 3 roles, 3 ceremonies, 3 artifacts it ceases to be scrum.

Some very specific challenges I’ve seen:  (1) poor/misunderstood user stories, (2) poor adoption of roles (e.g. the bullying product owner or the PO who can’t prioritise), (3) fear of committing to dates by team, (4) lack of empowerment e.g. team being told “how”, (5) PO unable to define “what”, (6) others inserted in team who usurp scrum roles e.g. team leaders, project managers.

I think one difficulty is that people do not understand what agile is meant to do when seen particularly in the light of the problems it is directly opposed to.  Perhaps only when you really suffered under those methodologies can you appreciate the brilliance of agile.  People therefore only “half” buy in to it (technical and non-technical users alike) and never fully recognise or leverage its immense value.  The people involved don’t therefore have the courage of their convictions and things start to bend.

I think another difficulty, particularly in the context of scrum, is that because it doesn’t go into as much detail about the practice as XP; developers often fail to adopt many of the values and disciplines explained therein.

I got my CSM last year.  Here’s what I’ve seen since then:

1) The catch-22: “We won’t adopt Agile/Scrum until the organization changes.”  Or “We’re not ready to change right now.”  So we can’t change until we change?  Really? Related: Deadlines are looming and there is not time to change right now.

2) Organizations unwilling to spend time or money to train staff.

3) Automatic push-back when preaching simple prioritization techniques,e.g. Kano and Relative Weighting.

4) PO’s sticking to awful Gantt chart.

In short, I think there needs to be more preaching of Agile to C-level executives.

1) Agile may not be appropriate. Capers Jones discusses this in his book “Software Engineering Best Practices”. Based on decades of research, he describes when Agile is a good fit and when something else is a good fit.

Below are some of the problems we face:

#1) Business needs specific features on a quarter by quarter basis and the Software Development teams agile release management / iterations do not always align.

#2) Operations Groups follow ITIL based processes and are not agile while the Software Development teams follow agile methodologies. Results in production ready code waiting collecting dust until OPs takes time to push the code.

#3) Organization structure has technical management hierarchy such as VPs having one or more Direcotrs having one or more Techincal Managers who in turn having development resources. The entire management stack feels out of place as to what their role is within the Agile Scrum processes. They are accountable for deliverables but cannot easily map themselves to a PO / SM / Developer roles or contribute to the suceess of the team.

#4) Organization requires external user acceptance and signoff process which has to be accommodated outside the sprint / release planning

#5) Dealing with specialised skilled resoruces like QA, UX, Architects, DBAs within teams as their contributions within iterations will vary based on the type of stories.

#6) Not much guidance available on managing multiple teams distributed globally working on the same product. All the pre-planning necessary to scrub the backlog, organize it based on dependencies / functional areas / Core utilities so each team has a clean backlog and does not step on other teams toes has to be worked out outside process.

Can’t wait to see the consolidated list of problems, with pointers on how to tackle them!

Low reactivity from the organization

Difficulty to scale.

Lack of visibility on issues and success, by blindly using tools.

Lack of discussion and negociation during the planning and the iteration

Low trust.

Productivity myths, axioms from the last millenium, need for perceived control.

Requirements that are too vague/big at the beginning of the iteration to be taken into the iteration

Scrum by he book: Scrum applied as a religion, without any imagination regarding continuous improvement. Processes bloating, bullets flying when the confluence template is not strictly applied.

Write-only processes and documentation.

1) Interaction between Dev and QA: Turning it into a collaboration from the “throw it over the wall” took a while.

2) Getting buy-in from all members of the team. Particularly, not everyone buys the assertion that you can do just enough design (paritcularly of relational database schemas) for the following sprint.

3) How to handle “large” bugs was an issue for us. There are the 0-point bugs that are easy to fix and just overlooked, but a large class of bugs are bugs in the design. To estimate this and how it effect capacity was a challenge.

Only superficial understanding of the agile waterfall, from values (respect, courage, openness) via principles to practices, not vice versa. Inability to empty your cup first. Framing “Agile” as yet another process-centered method.

As a result, focusing on the Nile delta of practices and techniques, not on the sources. Ignoring smells, e.g. grueling discussions about so-called “best” practices, method “customization” and change “management”. Staying forever at this Shu level, never reaching Ha or Ri.

Hi Barry—
It will take awhile but I do plan to consolidate the list and try to provide advice for the common problems.

For me, this is one is the worst: Executive pressure. Executive’s demand the team commit to releasing a set of “minimum” features by a certain date. Quality levels are reduced and there is no commitment from the team.

1. How to give a fixed price for a set of user stories in the backlog
2. Lack of understanding on Agile concepts by customer. This makes very difficult to follow scrum in accordance with scrum principals.
3. Resistance to move away from traditional weekly reporting structure to team velocity model
4. Lack of understanding on story point based estimates. I don’t really find a good article with practical examples on why story points are better compared to estimating in hours

We have multiple product owners and produce a product that is consumed by more than 100 customers.

Each sprint seems to add on barnacles of functionality. After a number of sprints, when we come to cut a release of the product it feels like the architecture is cobbled together rather than well-designed in a generic manner that gives flexibility, reliability, etc.

Sure, the theory is that you refactor during each sprint to adapt the underlying architecture but if we did that we’d spend all our time reworking the architecture and no time implementing actual features.

Our customers appreciate stability and don’t like frequent delivery - they don’t want to spend time for verification of each version too often.
Following this, we produce big fat product version like in pre-agile ages.
Following this, we don’t have good reasons to complete stories in one sprint, except, may be, ability for quick response when needed.
Following this, our end of sprint ceremonies often look like “check points” - “I didn’t finish this story, no problem, I will continue it in the next sprint”

Here are the top 5 problems I see with agile:

1) People expect and want everything to work as explained by scrum, kanban… In reality, people should learn about different methods and find the one that works for them and continually adapt and stay agile.

2) It’s hard to define of long term vision (like a gantt chart like you get with waterfall) and lots of management people still expect a gantt chart even if they want and know their team is agile.

3) Teams are stuck on strict roles when really, individuals that are part of an agile team should do everything they are good at to make the project move as best as possible.

4) Many times, agile teams are development teams. However, they depend on other teams: design, marketing, sales… ALL teams that work in relation to an agile development team should also be agile. Agile should not strictly pertain to development.

5) It’s difficult to plan with people who work on more than one project or product. People are rarely fully dedicated to 1 thing and that is a HUGE reality.

On any software project there is normally significant variability and change to realistically come up with accurate short term commitments. In scrum this usually means we are regularly missing our sprint commitment (which in turn affects team morale and sense of achievement).  It is interesting to see in the scrum.org Scrum Guide 2011 that the term commitment has been changed to “forecast” as it is expected that as more is discovered in the sprint, the forecast will change.

Our biggest problems seem to more about attitude than process, but I would sure appreciate any guidance you could offer.

1. Understanding that points on a story are not exact.  I think we follow the process correctly by building our backlog early and with a vague understanding of the requirements. When the story bubbles up on the backlog well develop it more and sometimes it is significantly different in size than originally expected.  Sometime this is due to design changes and sometimes this is do to what we know now verses what we assumed there about the technology or implementation. Our scrum master has taught us that we shouldn’t re-poker these stories when they come up, for two reasons: “Sometimes we’ll loose, sometimes we’ll win” points will never be precise. The second reason is that the points are use to predict what are releases will be and when they will be and we can’t keep changing that.  What this has lead to in some developers (including senior devs) is an attitude that the points don’t matter.
2. Creating walls between the devs and the BAs. We value the agile process of people over process and just in time design however this might mean that the UX design is not fully flushed until inside the iteration.  We do what we can to make sure the design is complete before tasking; however there are some things that seem to make complete sense in design but once you build it out enough to start playing with it your realize that its not going to work either technically or from a user experience. The problem is that when we communicate these challenges between groups a wall comes. This happens on both sides the BAs say things like “I don’t care how hard it is it has to work this way” and the Devs say things like “well that wasn’t in the originally design so you’ll have to write a story and put it on the backlog (Aka “too late, so sorry Charlie”) Neither position is wrong, but we aren’t communicating well and it seems to build an us verses them environment that is no fun. I would much rather see a team of BAs and Devs that handle these challenges together.

At the end of the iteration, we have about 25% to 50% of the stories not completed.
Sometimes the developers don’t finish all the work.
Sometimes the developers finish their work, and problems are found in testing.
Sometimes the developers finish their work on the last day of the iteration, leaving no time for testing.
How do we get better at getting all the work done in one iteration?

1. Building a real cross-functional team. People having individual quaterly goals and not acting as team players. Senior developers having feeling that they do all the work and are not properly backed up by others. People not able/willing to do anything outside their area of specialty (testers, DBA).

2. Dealing with technology debt/legacy application. Maintenance occupying significant and unpredictable part of sprint time. Prioritizing refactoring/redesign stories with no immediate customer value in the product backlog.

3. Unrealistic deadlines promised before sprint commitments.

4. Product Owner being a puppet (I exaggerate a bit), real decisions done by top management.

5. Stories not done done at the end of the sprint. Repeatedly.

6. Splitting features to stories - small enough and with some impact to user.

This is all great, stuff. What’s the purpose Mike? Are you going to filter this down until you’ve got your Top 100 problems with scrum and publish that? But, after that - whats the purpose?

Hi Mike—
I’ve got a couple of ideas in mind for the list but I don’t want to share them until I’m further along with one of the two possibilities. I work on so many different projects and some don’t see the light of day. Hopefully the ones I have in mind here will. Thanks to everyone for sharing the huge list (Sadly!) of possible problems.

- Team members don’t see the value of the sprint boundary when there are multiple sprints per release (to them, there is no cost to slipping as long as they can catch up at the end. It seems burning midnight oil once in awhile is more exciting than having a steady pace. Cheering from management doesn’t help either.)
- Mapping story points to hours or days
- Team members refuse to dog-pile, prefer to own and do the whole story by himself or herself (negating the sprint backlog priority)
- Functional manager thinks he has the authority to overwrite the practice (e.g. he believe he can order to accumulate technical debt “when necessary”)

- trying to get everything done in a sprint and not resulting in a mini-waterfall where testing is lagging behind the development
- trying to get items broken down small enough so testing can take place in the sprint
- hard to see the wood for the trees as stories end up too small. Techniques like story maps and mind maps can help this
- product owners who want everything and so refuse to prioritize
- changing job roles and responsibilities and the worry this gives people
- releasing so frequently that the business change required to accompany the release lags behind and so value is not realized immediately
- people think analysis is just user stories, analysis discipline is more critical than ever to ensure the product owner gets the value they want

Some items which are specific to running agile/scrum inside an organisation that is only using agile techniques at a development level:

1) Business believes that an agile process means it’s driven by developers and at once thinks the business is agile (because it sounds good) and doesn’t believe that anything can be developed without fully signed off specs, project managers and commitment to estimates.

2) With no business buy in there’s no way to hire/train dedicated POs, scrum masters etc which mean scrum teams try to make do with developers and managers acting as proxies. The results don’t make the best advert for going agile.

3) The business doesn’t like the (accurate) estimates coming out of planning and “enforces” tighter deadlines (that are unlikely to be met).

4) Trying to run agile without product owners

In my company a team (4 people) must work in several projects, so it isn’t focused in just one project.

My best solution, and also my problem:

There is a product owner with his “project backlog” for each project. Then, we need a “proxy” product owner who maintains an only product backlog on which the team works with.

- Product Owner not interested in attending Sprint goals demonstration.
- Product Owner focused on deadlines, leading to a continuous process of scope negotiation just to meet such deadlines. That causes technical debt to be continuously increased, and adding new features is getting more and more difficult as project evolves.
- Both highly skilled and novice team members within same team. Estimations accuracy depend heavily on which member will take the task. No time allocated for novice people to get training, so they are being asigned easier tasks sprint after sprint.

*  I was working on a Project with many interfaces with the others systems from other companies, and we had a lot an lot of problems to make the interfaces work, and to integrate different systems due to the rest of the systems were following waterfall. We had to suffer many changes in the definition of the interfaces, we had to wait many months for them to finish all their features of the interface to keep on working.
* The scope of the users stories were not clear during the sprint planning. The person who plays like the PO, who belonged to other company,  didn´t work enough on their backlog. However, We wanted us to make an analisys of what we had to make to accomplish with the users stories asking to other people from his company during the sprint.
* The POs didn´t understand the concept of Agile. They expected we accomplish all the deadlines, and all the features of the product were finished on a date despite of being continuos changes on the scope of user stories and change in the definition of the interfaces.

Hi Mike,

Some challenges I see in my current organisation.

1. Agile/scrum regarded by the broader business as something that only belongs in development.
2. The inevitable clashes that occur when the agile part of the business needs to interface with other parts of the business. 
3. The lack of understanding from senior management the impact and changes in business practises an agile approach requires. Eg, senior managers committing a project with fixed scope and timeline to a stakeholder, then embarking on a extended requirements gathering phase, before involving development who operate with scrum. Same senior managers also put a Program Managment Office over the top of the project, who keep telling us “we are running an agile project with a waterfall governance program” - no joke!!. How can we get the senior mangers, stakeholder and other departments to understand what organisational level changes are needed to get real value from an agile approach?

I ran through these questions while working on agile or scrum methodologies projects in the past.

1.> User stories were not documented rather requirements were told through an informal way. So, what should be done here?

2.> Agile or scrum methodologies were tough to worked on without agile tools. Is it possible to adopt / work on agile without having the right tools? What minimal tools do we require to work on agile project?

3.> Would there be some compromise on ROI when working on minimal agile infrastructure?

-Dave

After working in the software development waterfall world since the early 80’s; I must say I’m a huge Agile advocate.  It just makes sense.  More recently I’ve become a team member of two small projects that each have 1 week sprints.  I’m finding the overhead of these sprints overwhelming and I keep thinking why would anyone ever choose to do 1 week sprints.

1. Scrum works better when Product Owners are properly engaged in the process.  Getting them engaged is difficult.  Has anybody had success doing it?  How?

2. There seems to be a widepsread belief that Scrum replaces project management, which I don’t think is healthy.  Although the engineers who created it say they “don’t need no stinkin’ Gantt charts”, scrum doesn’t address risk and issue management, cost management, contract management, configuration management, setting up a project organisation… or possibly I was not listening when those bits were covered (yes, I am a project manager).

3. Scrum is based on the empirical process model (it’s good for complexity, dealing with surprises and the unknown, etc. etc.).  It does not follow automatically that since it works well for that type of work, it is therefore appropriate for everything.  What’s the heuristic that indicates what is and isn’t a suitable candidate for Scrum?

Hello Ian,

1. If you do not have a product owner - you should be rethinking about the project. Who is your customer is , why are you doing the project &  for whom.  If you do not have the answer , you have much bigger concern than the Scrum.  If your PO has difficulty in engaging - you do not have the support of the Executive management - BIG RED FLAG.

2. No Scrum does not solves the issues management, people management, architecture management e.t.c which are needed even before you start the scrum process.

3. SCRUM is just a branch of Agile - there are othes like Kanban that are more appropritate for projects that does not suitable for SCRUM.

Hi Mike Cohn, Have you compiled the list? I don’t mind buying ‘Succeeding in Agile Volume 2’ should you publish it.

Hi Fun Chiat-
Sorry, but I haven’t distilled all this down into a single list. I’m not sure if I will but it has certainly been helpful seeing what everyone listed as the main problems with using Scrum or agile.

Team are not skilled in testing and we do not have a tester.
also
Problem selling in Fixed Cost, Fixed Time Variable Scope to customers.