Tag Archives: agile

24 Common Scrum Pitfalls Summarized

Posted on by
14

Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:

  1. Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum.  Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans.  Even the Product Backlog can be created after the first Sprint has started.
  2. Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well!  Use manual and paper-based tracking for early Scrum use since it is easiest to get started.  Finding a tool is usually just an obstacle to getting started.  (And besides, check out what the Agile Manifesto says about tools.)
  3. Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised.  Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested.  The ScrumMaster facilitates this meeting to keep it on track.
  4. Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members.  It is better to wait for someone to step up than to “take over” and assign a task.
  5. Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting.  Teams should immediately re-start after cancelling a Sprint.
  6. ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle.  Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.
  7. Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums).  As well, the Product Owner should also be available during work time.  Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
  8. Stretch Goals: The team decides on how much work it will do in a Sprint.  No one should bring pressure on the team to over-commit.  This simply builds resentment, distrust and encourages low-quality work.  That said, of course teams can be inspired by challenging overall project or product goals.
  9. Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team.  Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
  10. Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems.  The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
  11. Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog.  PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
  12. Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint.  Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
  13. Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing.  A team member solves problems, but it is critical to know about constraints.  The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
  14. Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit.  Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
  15. Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped.  These activities can be part of the tasks in the Sprint Backlog.
  16. Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint.  Building prototype code just delays the inevitable need to write production code.  Similarly, wireframes, detailed designs and other similar tools should also be avoided.
  17. Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.
  18. Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules.  The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
  19. Changing Team Membership: Scrum is a framework for creating high-performance product development teams.  If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence.  If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.
  20. Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team.  For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title.  Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.
  21. Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”.  It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
  22. Imposed Deadline Scope And Resources: Scrum is reality-based.  If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum.  The reality is that no-one can predict the future so any such imposition is simply a fantasy.
  23. Definition of “Done” Imposed:  There is confusion between the concept of the definition of “done” and “standards”.  Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
  24. ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters.  They worked there together most of the time!  The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team.  Otherwise, the ScrumMaster should be in the team’s room.

Agile Transformation and the Chasm

Posted on by
1

In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later.  He describes five types of people in relation to how they adopt new products:

  • Innovators – always actively seeking out and trying cutting edge new products.
  • Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
  • Then there is the Chasm – many products fail here.
  • Early Majority – willing to try new things but need strong testimonials or real-world proof.
  • Late Majority – require time-tested proof before they will adopt a product.
  • Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.

This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.

Implications of the “Chasm” Model

An organization attempting to do an Agile Transformation [Kotter's 8-Step Change Model] should understand how to use this model to ensure long-term success.  This diagram illustrates the concepts (click on it to see it full size):

First, the organization should start the transformation by finding the innovators and early adopters.  These people can then be recruited to run the initial pilot projects.  They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility.  If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment.  Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.

In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups.  These people will tend to drag on the results of the pilot projects.  This is a common mistake in running a pilot program and leads to discouraging results.  One way to help filter between these two groups is simply to ask for volunteers for the pilot projects.  Innovators and early adopters will be much more likely to volunteer for a new initiative.

After the pilot projects have shown some good results, the next step is to go the general roll-out.  In this step, you are now working with the early and late majority.  These people need much more substantial support for a change of this nature.  They will require intensive training, and hand-holding in the form of coaching and mentoring.  This hand-holding can come partially from your innovators and early adopters.  Some of the participants in the pilot projects will have the desire to share their success.  From these, you need to carefully select and prepare a few who will act as internal coaches.  If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.

The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated.  This evidence partially comes from your pilot projects.  However, this may not be sufficient.  There are two other important sources of evidence for this group: the leadership team and external experts.

The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team.  The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar.  As well, this “Agile Transformation Team” must make itself very visible during the general roll-out.  This can be done with communication and by taking up visible residence in a central conference room or bullpen.  As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.

The second source of evidence comes from external sources.  Published case studies are one valuable source.  However, there is a huge value in a visible management investment in external support from recognized experts.  This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like.  When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.

The final stage of a roll-out is to deal with the laggards.  For the most part this is a do-or-die proposition for these people.  Either get with the program and engage like a committed employee or leave the organization.  If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.

For some organizations, this transformation process can take many years.  An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years.  Often it will be longer.  Good luck on your agile transformation effort!

ScrumMaster + OpenAgile + Kanban training in Toronto December 7-9,2011

Posted on by
Reply

We have an upcoming three-day agile training seminar in Toronto on December 7-9, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

to register:
http://www.regonline.ca/Register/Checkin.aspx?EventID=988417 

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

Upcoming Agile Training in Ottawa November 28-29

Posted on by
Reply

We have an upcoming Certified ScrumMaster (CSM) training in Ottawa on November 28-29, 2011. This two-day Scrum training is full of great features including:

  • Facilitated by Certified Scrum Trainer ™ Mark Levison, an Agile expert since 2001
  • Classroom management using agile methods so that you can learn by example
  • Two intensive days of training with exercises, simulations, discussion and lecture
  • plus much more!

For more information visit: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

 

To register:
http://www.regonline.ca/Register/Checkin.aspx?EventID=988414 

 

Proudly delivered by Berteig Consulting, a Canadian organization.

Announcing our winter 2012 course schedule

Posted on by
Reply

Hi Everyone!

We have delayed announcing our winter 2012 schedule until now because we have been working on a new platform for listing our courses and creating a community environment for people who have taken our courses.  So, without further ado, I would like to offer to you: World Mindware!

Since we are agile ourselves, this site is still very basic.  We have our list of courses and you are able to register for courses.  However, we welcome feedback of all kinds including bug reports, suggestions for improvements or requests for assistance.  Please contact operations@berteigconsulting.com if you have any feedback about the site.

ScrumMaster + OpenAgile + Kanban training in Waterloo November 9-11,2011

Posted on by
Reply

We have an upcoming three-day agile training seminar in Waterloo on November 9-11, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information and http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

What is Scrum good for?

Posted on by
2

I have worked with a lot of people, teams and organizations over the last 8 years helping them to adopt Scrum and I have seen some interesting patterns about where Scrum works well and where it doesn’t work so well. I wanted to share my observations to see if they correlate with what other people are experiencing.

So first off, I want to describe what I mean by Scrum working well:

  1. Teams using Scrum are obviously high-performance teams whose business results are at least 4x that of normal teams.
  2. The organization in which Scrum is being used experiences a change in culture to become more team oriented, more value oriented, and more customer oriented.

So now I can describe where I have observed Scrum to work really well:

  1. When an organization (or team) is in deep trouble and willing to admit it adopting Scrum seems to be a catalyst for creating a new culture, process and team environment where getting out of trouble is possible. This is Scrum for Crisis. The “willing to admit it” part is extremely important as I have worked with two organizations where the “deep trouble” part was obvious to me as an external person, but in both cases management and staff did not seem willing to admit the depth of their crisis and in both cases Scrum failed to act as a catalyst to get them out of trouble. In this use of Scrum, sometimes resolving the crisis then leads back to complacency and Scrum fades away.
  2. Small growing organizations that have no existing formal processes for development can use Scrum as an effective way to maintain their high-performance without getting burdened in bureaucracy. In this case, it is important to note that they are _already_ in a high performance state and their struggle is to maintain that while at the same time growing. I’ve worked with quite a number of small organizations where all they need is the CSM (plus maybe one or two days of coaching) to adopt and maintain Scrum. I have also worked with small organizations that were _not_ already high performance and Scrum has not typically worked to bump them up to a high-performance state.
  3. Pure new product development where a single strong Product Owner can be identified who has the authority to make product decisions independently of anyone else (including product budget decisions). By “pure new product development” I mean that neither the individual team members nor the team as a whole have any responsibilities outside of the product work – there is no “fractional allocation” or “resource levelling” across projects or products. The strong Product Owner is critical to success with Scrum and must understand the principles of Scrum as well as the mechanics of being a Product Owner.

I have also seen Scrum be inappropriate and not lead to the results I mentioned above:

  1. Management teams. It seems like Scrum could or should work for management teams, but it appears that managers have too much of the following problems to be able to use Scrum:
    - operational responsibilities (non-creative, non-problem-solving work)
    - urgent, legitimate interruptions (e.g. an escalated customer issue)
    - real commitments to events or projects that are calendar based (e.g. a management off-site)
    - ego: they don’t want to follow an apparently rigid process or they are always happy to make exceptions for themselves
    Again, one might imagine that Scrum _should_ work to help resolve these issues, but unfortunately I have never seen it able to do so in this context.
  2. Small teams/projects. Scrum is too heavy for teams less than 5 people or for projects shorter than 2 months in total duration. Those numbers aren’t meant to be hard and fast, but when I’ve seen small teams/projects attempt to do Scrum they _always_ end up breaking lots of the rules partly because they can and partly because they must. That said, some folks have created “Personal Scrum” and other variants. I’m not sure if we as the Scrum Alliance officially recognize/endorse those variants.
  3. Purely operational work. There just isn’t enough creativity/problem-solving to make the Sprint an appropriate process element, nor the Product Backlog an appropriate organizing mechanism. I have seen some operational environments get some benefit from doing regular retrospectives, but just doing retrospectives is not Scrum in my book. My experience with Kanban is still a little limited, but it seems to be an appropriate approach for these environments.
  4. Organizations where there is very little need to change. I’ve spent some time working with big profitable banks to adopt agile and without exception, they just can’t wrap their minds around the need for Scrum… because they are already so successful as a business. The general attitude is that Scrum is popular therefore we will call what we are doing “Scrum”, but it really isn’t. It’s Scrummerfall and Scrum-Butt wrapped up in the terminology of Scrum. They will adopt some Agile practices and get very modest benefits. I have seen minor improvements in team morale and minor improvements in quality and productivity, but certainly not anything near to what is possible for improvements. When we do assessments in this type of environment, we see Value Stream maps with waste at the 80-90% level so there is huge room for improvement… but it just doesn’t happen.

Scrum can definitely transform the world of product development. It can definitely act as a catalyst to get teams and organizations out of crisis. But that isn’t the whole world of work. I’m also concerned about the idea of using Scrum for general project management. There might be some good practices that are part of Scrum that would also be valuable in general project management (e.g. regular retrospectives, daily team meetings) but that doesn’t make Scrum a general project management framework.

I don’t claim that any of the above observations are “correct”. That’s partly why I am sharing – I would love to have a good discussion here about this because I think it is critical for us as Agilists to be able to answer this question well when we are asked: “what is Scrum good for?” – particularly since Scrum is by far the most popular Agile method.

I would love to hear other people’s observations about where Scrum works well (as I have defined “well” above) vs. where it either is only a modest improvement to existing approaches or where it might even not work at all.

Estimation – Bad Advice

Posted on by
1

Here’s a fun article on PMI.org.  By omission, it gives some very bad advice about estimation.  What is it missing?  Asking the people who are going to do the work!!!  Any estimation method or approach that fails to ask the actual human beings who are going to do the work about the effort required is going to be badly wrong.  (Of course, even asking the people who are going to do the work is no guarantee of good estimates.)

The starting point of the linked article is a study that showed 90% of projects having cost overruns.  To me, this just shows the futility of predicting the future, not anything about how we can (and should?) make better estimates.

OpenAgile Team Member training in Markham November 17-18 th, 2011

Posted on by
Reply

We have an upcoming Agile training in Toronto on November 17-18th, 2011.  This is a special Agile training because it is an OpenAgile Team Member training – which is the most widely applicable Agile method!  This two-day training seminar is designed to help you use OpenAgile principles and processes to improve productivity, efficiency and quality in your team, project and operational environments. This is the official OpenAgile Team Member training and provides the basic skills and knowledge to work with OpenAgile as a team member.

For more information and to register visit: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004

Good Explanation of INVEST for User Stories

Posted on by
Reply

Mike Caspar, a fellow agile coach,  just forwarded me this YouTube video to Bill Wake talking about INVEST for User Stories.  I worked briefly with Bill back in 2004/2005 at Capital One where he did some excellent coaching.  I strongly recommend checking out the video!

Upcoming Agile Training in Ottawa October 31-November 1

Posted on by
Reply

We have an upcoming Certified ScrumMaster (CSM) training in Ottawa on August 15-16. This two-day Scrum training is full of great features including:

  • Facilitated by Certified Scrum Trainer ™ Mark Levison, an Agile expert since 2001
  • Classroom management using agile methods so that you can learn by example
  • Two intensive days of training with exercises, simulations, discussion and lecture
  • plus much more!

For more information and to register visit: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization.

ScrumMaster + OpenAgile + Kanban training in Toronto October 26-28,2011

Posted on by
Reply

We have an upcoming three-day agile training seminar in Toronto on October 26-28, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information and http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

Agile Outside of Software

Posted on by
1

The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:

1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan

I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.

On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.

Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.