The Fragile Manifesto

If you haven’t done so yet go back and listen to the episode on SCRUM. In that episode the guys talked about the way SCRUM and Agile in general are supposed to work. This week they’re talking about some of the anti-patterns you’ll see when it is not implemented correctly. The episode is broken this down into four areas where you might see these anti patterns: Planning and Scheduling, Management, Treatment of Workers, and Delivery.

“This is basically a discussion of the phenomenon in our industry where people call their process agile when it’s really agile but…”

You should expect to see some of the these happen at least once while you are working on an agile team. It becomes a problem and they become anti-patterns when it happens regularly or become a pattern of behavior. It’s not likely you’ll see all of these on one team but knowing them can help you guide your team or workplace away from them. If you see one of these patterns start to develop act quickly to quell the anti-pattern before it takes hold.

Episode Breakdown

Planning and Scheduling

8:12 You Don’t Have Sprints

If you aren’t doing sprints you are doing marathon coding. Not having fixed sizes to your sprints can lead to confusion and over scheduling of meetings that take time away from development.

“That’s Reactgile!”

It can also occur that stories and tasks are added to a sprint once it is under way. In general this is to be avoided. When it is unavoidable the scope of the sprint much change.

10:45 Scope Creep

Scope creep is any change of scope without changing schedule. This could be as seemingly innocuous as adding to acceptance criteria of a story while in the sprint. If the scope of your sprint is added to something must go to another sprint.

13:15 Developers Not Doing the Estimates

This occurs when estimates are done by management or project managers. These estimates won’t reflect actual development workflow.

14:55 Everything Is Top Priority

“When you say everything is top priority, nothing is a priority.”

A common anti-pattern is to have priorities shift constantly. When this happens nothing is top priority. The priority of items in the backlog should be set by the product owner so that the development team knows which stories to commit to doing and which can wait or may need further evaluation.

16:35 No Time Allocated For Bug Fixes

You will find bugs while developing. When planning your sprints you must consider time for QA to find bugs and fix them before product review. This should be part of your capacity for the sprint. Not all bugs will be from this sprint. You may find bugs when work from previous sprints interacts with current work.

19:38 Ambiguous Acceptance Criteria

One of the most insidious of the anti-patterns. This could be criteria that are impossible to achieve or do not contain enough information. One of the worst is when the acceptance criteria changes while you are working on that story in the current sprint.

Management

21:48 Rotation of Developers

This occurs when you do not have consistency on your team. It could be that developers are on too many projects at one time and are constantly coming and going between projects. Not having a consistent team is a sign of poor resource allocation from the management.

24:28 Over Reliance on Timelines

“It gets in the way of actually getting things done.”

Agile is designed to flow and grow without hard deadlines and timelines. A project with a set timeline and fixed completion dates is not agile.

26:40 Poor Self Assignment of Tasks

This could come from several different areas but ultimately it is a manager’s responsibility to make sure the members of the development team are appropriately assigning themselves tasks. This cannot be done if it all gets assigned at the beginning. Generally you will see some siloing based on individual capabilities but have to avoid developers self assigning task they do not understand or cannot accomplish.

28:50 Not Allowing Changes Based on the Sprint Retrospective

“There’s a tendency in some organizations to move people into management when they can’t develop anymore”

The purpose of the retrospective is to provide a place for the development team to self assess and review what went well and what didn’t go well in the last sprint.

From this they develop action items to improve the process. Management shouldn’t be involved in the meeting and only receives the action items after the meeting. This anti-pattern occurs when management ignores these items or misinterprets them as criticism.

Treatment of Workers

30:38 Poor Relationship With Product Owner and Stakeholders

Siloing the developers from the product owner and stakeholders cuts communication and can lead to misinterpretation of acceptance criteria. This in turn leads to developing the wrong thing or having to rewrite large section of code.

The converse is too much interaction with the product owner and stakeholders. This can lead to them misunderstanding the development cycle and making requests or changes to the acceptance criteria while the story is in development.

33:40 No Rotating SCRUM Master

Not rotating the SCRUM master creates a situation where if they are absent meetings do not happen because no one else is able to lead. It also creates specialization on the team.

By rotating the SCRUM master no one person gets siloed into the position. Also as other people rotate through this position they may do things better and teach the entire team.

37:00 No Feedback of Developer Estimates

“What changed between now and when you made those estimates?”

Developers should be held accountable for doing what they say they can do. If the success or failure of the developer’s estimates is ignored then there is no value for accuracy in estimation.

42:08 Stand-Ups Are Actually Sit-Downs

“It’s not a big deal when everyone goes in sits down for five minutes and leaves.”

Daily standups, or daily SCRUMs should be no more than 15 minutes. Each member of the team states what they have done since the last stand up, what they are planning to do, and what if anything impedes their process. Daily standups that are poorly scheduled or poorly administered tend to be excessively long and stray from the topic at hand.

45:11 Death Marches

These occur when developers are expected to work overtime on a regular basis. On occasion this is acceptable especially when close to a deadline or holiday. However, when it occurs on a regular basis rebellion breeds within the team.

46:43 Lack of a Sprint Retrospective

The retrospective is a time for the team to commiserate on the struggles of the previous sprint, rejoice in the successes, and learn from what they have just accomplished. The retrospective is the core of agile as it is how the team learns to adjust the process.

Not having a retrospective denies the development team of a core component of the agile methodology. Worse than not having one is not producing actionable items from the retrospective. When this occurs the retrospective instead of being a learning experience becomes a whining session.

50:10 Management in the Sprint Retrospective

This gives the impression that management is looking for a yes man or woman. It creates an environment where the development team cannot be honest with each other.

Delivery

51:58 No Deliverable Code at the End of a Sprint

“Done means deployable”

Each sprint should produce a minimum viable product (MVP) or something that is ready to be placed in production. Deployment is a looming threat over developers. Working toward deployment in each sprint leads to design decisions that will not break in production.

52:29 No Quality Control

This occurs when developers finish with no time for QA or testing. When it happens the sprint should fail. QA and testing need to be built into the sprint as part of the process.

Without QA and testing developers will be interrupted when something critical is found in production that would have been caught by QA. You’ll never know when a breaking bug will hit.

54:36 Delayed User Acceptance

At the end of each sprint the product owner and stakeholders should be reviewing the completed progress. Without the sprint review they will not know if what was built is what they actually need. User Acceptance Testing (UAT) should begin as soon as possible in the project lifecycle.

IoTease: Project

Solu: Smallest General-Purpose Computer

“No need to worry about your hard drive, backing up files, or installing software because it is all in the cloud.”

It is a cloud linked computer with no hard drive or software installation. It’s all in the cloud and protected by convergent encryption on the device. It even works offline synchronizing when you connect it.

Hardware

Software

Tricks of the Trade

People often use terms for reasons other than clarity. Avoid getting burned by someone else’s misunderstanding of an industry buzzword by asking questions. If a term could have multiple meanings get clarification before proceeding.

Editor’s Notes:

Tagged with: , , , , , , , , , , , , , , , , , ,

Leave a Reply