No one goes full Agile.

After working on agile (SCRUM) projects for around 3 years I would expect to have a clear understaning of this working methodology. The truth is that even after being on 3 different projects I find myself looking back at the key principles of SCRUM and often find myself straying from its preachings.

I cannot imagine there are many that follow SCRUM word for word but would like to think the closer you can stay true to SCRUM the more productive your agile team will be?

Some of my thoughts so far:

It is better to know some of the questions than all of the answers.

My biggest failure would be trying to solve problems in the SCRUM stand up meetings when the detail required failed to be extracted or understood in the customer/planning meetings.

Looking at SCRUM documentation a maximum of 8 hours is quoted for this meeting, how many customers can take even a quarter of this time out of their working day?

Can a one or two hour planning meeting produce enough work for a sprint that spans 2 weeks?

Know your role

After reading a large amount of comments about the developers role I have come to the conclusion that agile frees the developer wooo hooo!:

“So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. ”

“To be successful in Agile environments (and in fact to do well in most environments) PMs must first favor people over process and avoid a command and control approach”

I have felt this way on projects and feel most productive when I am able to be creative and explore multiple answers during a SPIKE. This has not always been the case though and often it appears you are being micromanaged and lose control over what makes developing enjoyable. Who should be doing the micro-managment? It should be the team right?

A man on a mission is far different from a drone on a deadline

There is no escaping deadlines Im under no illusion of that, but as scope and priorities change can we really commit to delivering an unknown amount of work in a set time?  And Should speed outweigh quality?

Often I have seen long term plans within the SCRUM environment, I have seen many long term detailed plans constantly change to adapt to the real timeline which is already being captured by our planning tool, the Gant Chart seems a waste of time in SCRUM.

To finish I have found a nice list of SCRUM pitfalls and chosen a few to share:

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. (Guilty)

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.

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.

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).

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).

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.

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”.

http://www.agileadvice.com/2011/12/05/referenceinformation/24-common-scrum-pitfalls-summarized/

2 thoughts on “No one goes full Agile.

  1. Interesting post.

    By ‘Daily Scrum’ don’t you mean ‘Standup’?

    Also, as someone who introduced ‘Agile’ to the university, I’m not convinced that the current way we manage software development is ‘agile’ in any sense of the word. We are all encouraged to manage ‘process’ not ‘outcomes’.

    As a developer, what would you change?

  2. One of the major flaws in the way I’ve seen Agile attempted is that stories aren’t written with sufficient rigour to be useful. The formal agile story structure is suggested for very good reason, and you lose a lot of clarity by deviating away from that.

    There’s no reason that stories can’t be prepared prior to a scrum, especially since there is often a dedicated resource for just this purpose. Perhaps an extra benefit to a more disciplined approach to tickets might be to encourage a comprehensive testing system.

Leave a Reply

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