You are currently browsing the tag archive for the ‘scrum’ tag.

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

 There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
  Measured by Number of manual steps required
    Minimum acceptable 1
    Maximum acceptable 4
  Measured by Time from submit until calculation appears
    Minimum acceptable 0.5 second
    Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.

Advertisements

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
Measured by Number of manual steps required
Minimum acceptable 1
Maximum acceptable 4
Measured by Time from submit until calculation appears
Minimum acceptable 0.5 second
Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.

walmartWhen kick-starting a new team, it’s helpful to be empathetic to each team member’s background and experience.   Interpretation of such concepts as productivity, efficiency, and quality can differ based on an individual’s background, values, and previous experiences.   Ambiguous goals can lead to ambiguous results.

A role of the Scrum Master is to facilitate the team toward common goals.  At face value, this sounds like a “motherhood and apple pie” statement.   Under the covers, this can be more challenging than it appears.    When goals are stated in subjective’ish language, each team member’s interpretation is likely to be different.   

Tip: Know the Target of a Goal.

There’s a difference between goals for the project and goals for the thing being built.  

Project goals tend to pertain to the schedule, resources, and work.     Project goals usually contain language related to efficiency, productivity, being on time, providing good customer service, meeting budgets, etc.

Product goals pertain to attributes of the system being developed.   Non-functional requirements fall into this category: The system shall fast, efficient, comprehensive, fault tolerant, user friendly, etc.

Tip: Make Adjectives Measurable.

Adjectives are inherently subjective.   Product goals such as “User Friendly” and “Fast” have a zillion interpretations.   Rather than “System shall be fast”, try a more specific goal such as “Each screen must display within 3 seconds of request”.

Similarly, a project goal such as “Work Productively” says nothing.   This is where Scrum tactics can help.  Establishing a specific goal for the team’s velocity is measurable, reportable, and actionable.   Once the team agrees to a goal for its Velocity, it can be tracked and reported as a shared measurable goal.

 Tip: Radiate the Goals that Matter.

When goals are written in a document and filed away, they can be forgotten.   If a goal is really important, consider radiating it – perhaps post it on a wall in the team room.   If a goal is not worthy of being posted, perhaps it’s not really that important.

holiday1Although I’m usually pretty disciplined about diet and exercise, I tend to slack off quite a bit during the holidays. Some believe that a vacation from discipline is a good thing every now and then, while others feel that “discipline debt” becomes hard to pay off.    I do know that losing the 5 pounds I’ll probably gain is going to be a hassle, and completing my twice weekly bike rides is going to be more difficult when I resume.

 

Many projects (Agile or not) tend to go on vacation during the holidays.   Not necessarily a full blown stop, but work may slow to a trickle.   Many will take days off and/or participate in other non-project related activities.  When a project team is shut out of office decorating, food-fests and gift exchanges, discontent can build.   

 

When planning a sprint that will span holiday weeks, it’s important for the leadership to agree on an acceptable velocity that could be lower than previous sprints.    This strategy continues to enforce the discipline of “we set a goal and work together to meet or exceed it.”    The alternative is to miss an unrealistic goal and blame it on the holiday.   Allowing this can open the door for all sorts of other excuses down the road.

 

Another strategy is to devise a holiday sprint – one focused on cleaning up outstanding housekeeping items that would be nice to get out of the way.   Items selected for the holiday sprint are hand picked based on size, complexity, and lack of dependency on resources who will be gone.  Although this may violate the practice of driving sequence based on priority, it does allow the discipline of the process to endure.

emperor-new-clothes-13A commenter on my previous post made reference to Scrum’s transparency of work, workers, and productivity, noting that this causes some to dislike Scrum. 

 

Back in High School I was a trumpet player in the marching band.  When football season ended each year, our large band was split up into multiple small bands with just a few players on each instrument.    Every note played (or missed) by each and every member of the smaller band was noticed.   Those who were marginal players couldn’t hide behind the other players.   This resulted in two things: 1) Many worked harder to develop the skills needed to perform acceptably, and 2) Some left the group, or moved to a “lesser” band that had more casual goals. 

 

The transparency of productivity and results in Scrum leaves no one out.  Even if today is my most productive day ever, that will be forgotten if I’m not productive tomorrow as well.   Many are invigorated by this and will thrive in this environment.   Others may try to hide by fabricating useless tasks that burn down hours, but that don’t move the project forward.    When this happens, the Scrum Master, Product Owner, and each and every member of the team should call the bluff.   C’mon, you probably know what’s going on and you just don’t want to expose it!   When a team member tries to hide a lack of skills or a deficiency in productivity, it wastes everyone’s time and can slow down the project.

 

In a perfect world, members of a newly formed Agile team are highly skilled, and the role of the coach is to overlay Agile so the skills are employed in the right way, in the right place, and at the right time. But many of us don’t live in a perfect world.

As a coach, I have often been challenged with team members who lack fundamental software development skills. This can distract efforts to be successful with Agile…and when core skills are missing, there is risk that the organization will peg Agile as the culprit for poor results.

I have met a number of people who told me that Agile was abandoned at their company and dubbed a failure. Agile cannot ‘heal’ poor software development skills, rather, it helps teams that possess skills experience an order of magnitude improvement in results.

When tasked with coaching a team of underdogs, the first order of business is to assess the presence (or lack) of core software skills. If an underdog team is what it is, a successful coach recognizes the obligation to clearly separate Agile coaching efforts from those of teaching/mentoring fundamental skills. This will help a company balance it’s needs: To emphasize skills development, or to place more emphasis on successful delivery. If the latter is the emphasis, it may not choose to pursue that particular project with a team of underdogs.

I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.

So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.

From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?

Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.

I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.

So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.

From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?

Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.

Many software projects seem to me to have inherent opposing forces present at all times. Analysts wrestle with business folks about what’s needed, developers wrestle with analysts about too much / too little documentation, QA folks wrestle with developers about the sufficiency of unit testing, management wrestles with development about cost and schedule, and on and on.

Many of us are naturally repelled by conflict. We try to prevent it from happening, and when it does happen, we try to get away from it as soon as possible. (With the sole exception of people from New York.) On a software project, the easiest way to avoid conflict is to burrow in a cave and do work. Unfortunately this is totally contradictory to the collaborative best practices that make Agile projects work, and rather than avoid conflict, it just defers it.

Agile projects tend to expose conflict early and attack it head on. Since this is unnatural and uncomfortable for many people, it can slow the adoption of Agile practices. Embracing Yin-Yang and cultivating opposing forces on a project into an efficient process with quality results is the very first hill to climb when starting your first Agile project.

10. The Product Owner keeps dropping by to see what we’re doing.
9. I have to prove that I got work done every single day.
8. I have to work with other people, constantly.
7. I am expected to demonstrate imperfect, unfinished software.
6. Senior management looks at our burn-down chart every day.
5. Developers keep bugging me with questions.
4. There’s hardly any down time.
3. Everybody else gets an opinion about my task estimates.
2. I am expected to work on tasks that aren’t in my job description.
1. My project could end before the target date!

What’s on your top ten?

Advertisements