My focus is on making software, coaching Agile/Scrum teams, and being a husband and father--definitely not on blogging--so please do not expect very frequent posts here.

Friday, February 12, 2016

A compact layout bookmarklet for TFS web work items

UPDATE 2016-05-06: Now supports the TFS Product Backlog, Board, and Sprint Backlog, with resolved/closed work items green and crossed-out, as well are much improved User Story (Kanban) board.

Do you want your UI controls and whitespace cruft taking up half your browser window, like the default view in the first image?  Wouldn’t you like your TFS backlog to instead show as much info as possible, as on the second image below?



You can!  Drag this to your bookmark bar (Firefox or Chrome):

TFS Web Compact (for TFS 2015 and Visual Studio Online)
TFS Web Compact (for TFS 2012)

Then, whenever you have TFS web work items or task board open and you want to see more content and less cruft, click it.  Be sure to use "full screen view" in TFS and in your browser as desired.
I’ve also made the 2015 version available as a gist.

[Bookmarklets are tiny programs stored inside bookmarks or links. Similar to (but simpler than) add-ons and extensions, they add new tools to your web browser. Bookmarklets are shared on web pages as web links. To add a bookmarklet to your browser, right click on its link and choose the bookmark option, or drag it to your bookmark bar. To use it, simply click on the new bookmark you added.]

Sunday, January 24, 2016

Basic Scrummaster Duties checklist

I really like Michael James's Scrum Master's Checklist to give us an idea of the work a Scrum Master can do to make their team the best.  However, it doesn't really show the basics of being a Scrum Master, so the following should help with that.

Scrummaster duties list:
Always:
  • Nudge, steer, and help the team to do all Scrum events and activities
  • Help the product owner and team in any way to be more productive
  • Remember the Agile values
Before daily scrum:
  • Ensure the team has updated the hours remaining on all tasks.
  • Update and post the burndown chart.
During daily scrum:
  • Note all impediments reported by the team for later helpful follow-up.
  • Steer the team to stick to short answers to the three questions; steer them away from discussing problems or details during the scrum (Often say "this sounds like an important discussion; can we have it after the scrum?")
After daily scrum:
  • Help team to overcome impediments as a top priority
  • Ensure relevant team members meet to overcome impediments before doing regular work
  • Keep outside distractions away from the team
  • Answer (or research) all Scrum questions the team has
Anytime, to prepare for sprint planning:
  • Gather info on vacation/unavailable time for all team members in the next sprint
  • Ensure (help) the Product Owner refines and reorders the backlog
  • Ensure the product owner prepares a sprint goal
  • Schedule the next sprint planning
  • Schedule the sprint review; arrange for stakeholders to attend it.
  • If the stakeholders can't attend the Sprint Review, reschedujle it.
  • Ensure the team will prepare a demonstration for the sprint review.  Ensure it is appropriate
  • Prepare any other charts or information radiators helpful for planning, such as a velocity trend chart
  • Schedule a backlog estimation meeting as required
In sprint planning:
  • Facilitate the entire meeting; take team through all parts
  • Take notes from the retrospective
  • Announce velocity in story points from last sprint
  • Announce team capacity in hours for the next sprint (accommodating vacations, etc)
  • Post/arrange the product backlog for sprint backlog selection
  • Keep the team on track for breakdown into tasks; write/post task cards if necessary
  • Ensure a reality check of task hours vs. capacity happens and adjustments made
After sprint planning:
  • Create beginning burndown chart, task board, and any other information radiators
Never:
  • Demand that the team take any certain action
  • Assign work or take unilateral action to change a practice
  • Neglect Scrummaster duties in favor of "regular work"
Once you have the above under control, consider additional duties from the Scrum Master's Checklist.

Tuesday, December 1, 2015

Szalapski.com Scrum Rubric


Agile is a set of values, and does not imply or require certain practices. Scrum is a framework that says a software product should be developed by a self-organizing team, in multiple fixed-length sprints, in full collaboration with the product owner, using Agile values and principles throughout. Scrum specifies a few practices, but as a framework, it is up to the team to insert many other practices into it.

The following is a guideline on practices to strive for. It is not a maturity model—the goal is not to adopt as many of these practices as possible. It is not a roadmap—do not try to adopt a minimal set of processes at first before adopting others. Instead, it is a menu of options. We recommend you, as a team committed to Scrum, immediately adopt all of sections A, B, and C; adopt as much of section D as you can; and consider adopting any practices in section E.

Following this rubric is not sufficient; you must learn and apply the concepts and stories of Scrum from training, books, other practitioners, and experience, starting with the Scrum Guide. It is possible to adopt most of these practices and still miss the point of Scrum, so do not take this rubric as a gold standard.

(I offer coaching on all these practices.)

A. Agile values and principles – If you don’t follow these, then nothing else matters
  • Value people over process
  • Value working product over documentation
  • Value collaboration over contracts
  • Value responding to change over following a plan
  • A willingness to change any practice, attitude, or relationship that conflicts with the four values
B. The price of admission – If you don’t do these, you ain’t doin’ Scrum
  • A commitment from all to follow the Agile values and principles
  • Empowered, committed, singular, decisive product owner who is always available and interested
  • Self-organizing team with 2-9 most-time members (do not include 40% or lower allocations)
  • A designated Scrum Master on the team
  • Fixed-end sprint iteration of 1-4 weeks
  • A product backlog consisting of all the important known work to be done
  • A sprint planning session starting each sprint
  • A sprint backlog consisting of all the work to be done in the current sprint
  • A scrum each day during the sprint; self-assigned tasks
  • Emphasis in the scrum is on finding and exposing blocks; discussions happen afterward, not during
  • A commitment to daily adjust based on circumstances
  • Potentially shippable working software at the end of each sprint
  • A retrospective meeting every sprint
C. Practices strongly urged
  • Estimating product backlog items using planning poker or other system
  • A formal sprint goal
  • Sprint backlog broken into tasks, estimated in hours remaining, updated daily by the team
  • Work remaining daily burndown chart
  • Regular backlog grooming sessions
  • A well-attended sprint review and demo meeting to stakeholders at or after end of sprint
  • Sprint planning happens the first day after the end of the previous sprint (no gap)
  • A shared definition of “done”
  • A short quality plan
  • Automated unit testing  (for software)
  • Zero compiler warning tolerance (for software)
  • Literally standing up during the scrum
  • Velocity tracking and capacity planning
  • A “Minimum Viable Product first” attitude
  • A refactor-as-you-go attitude
  • A team of generalists and generalizing specialists
  • Steady, sustainable pace; no overtime
  • Fixed-end sprint iteration of 1-3 weeks
D. Practices recommended for most Scrum teams
  • A product owner who reports to the business, not to IT
  • Product owner sits with the team
  • Most product backlog items in the form of proper user stories
  • Swarming on fewer stories at once
  • Spikes whenever needed
  • A technical debt backlog; a commitment to work on technical debt
  • Continuous integration: Automatic builds, automatic testing, automatic code analysis (for software)
  • Asynchronous code reviews (for software)
  • Co-located team; common work area/team room
  • Coding standards (for software)
  • Ad hoc pair programming encouraged (for software)
  • Automated integration tests (for software)
  • Shorter sprints
  • Manual testers on the team (for software)
E. Optional practices to consider for your team
  • User Story mapping
  • Story brainstorming sessions
  • Estimation of ROI using planning poker
  • Test-Driven Development
  • A burn-up chart of completed vs. remaining work in the backlog
  • Light-hearted shame trophy for breaking the build
  • $1 or other light-hearted fine for being late to scrum or other important meetings
  • Pair programming required
  • Continuous deployment
  • Chaos monkey
  • Advanced training
  • Automated behavior-driven and/or acceptance tests
  • Zero bug tolerance
  • Mandatory fun
  • Personas
  • 1:1 retrospectives
  • WIP limit
  • Reserved time for training/self-education
Values to remember throughout
  • The 12 Agile principles
  • Servant leadership
  • Self-organizing team
  • Remove impediments and keep out distractions

Monday, August 24, 2015

Coming soon: a rate-limiting and throttling service

Limtr
 
rate limiting and throttling the simple way


coming when it's done

Wednesday, April 8, 2015

Which of these things does the arrow belong to? - UX in the wild

Even simple signs have UX concerns. Take this sign, in San Francisco:


I ask you this: does this sign mean the general entry is here, and that the handicap-accessible entry is to your right?  Or does it mean the entry is to your right, and it is also handicap accessible?
My first thought was the former.  Why? Having the wheelchair symbol and the arrow on the same line implies a stronger relationship than with the information above it.  To most people, they don’t think about this directly, but they intuitively process the arrow and what it means.
I looked in my immediate vicinity and did not see any entries.  I concluded the meaning must be the latter.

A better sign would have been:

Also, if the entry be handicap accessible, there be no need to call that fact out, as it isn’t special. You only need to know where the handicap-accessible entrance is if the main entrance isn’t so accessible.  I submit the best sign therefore would be:






(Of course, the arrow should be centered and not have a blotchy background, but that’s just digital manipulation error.  No, I am not going to spend the time to fix it!)

Bonus UX problem: this entry was on the southeast side of the building.  Maybe it should have been called the Moscone Center West South East Entry For Kids Who Can't Read Good And Wanna Learn To Do Other Stuff Good Too

Or, maybe you just shouldn’t name buildings after ordinal directions.

Monday, April 6, 2015

We still value the “things on the right”!

In a recent article reexamining the Agile Manifesto, Derwyn Harris criticizes the fourth Agile value, which values responding to change over following a plan: “The volume of software being developed today dramatically outpaces that of 2001 and the Agile Manifesto doesn't address that reality. There is a notion in the Manifesto that we're trying to move away from planning, away from negotiation.”

The author only criticizes that we value responding to change more than following a plan.  However, she is only criticizing a straw man.  Valuing responding to change doesn't mean we avoid planning—a disclaimer right at the bottom of the manifesto itself clarifies this!  Responsible Agile teams plan much, perhaps even more than in traditional software development. Agile planning needs to happen throughout product development and to accommodate the more important value of responding to change.  

The Agile Manifesto “doesn’t address the reality” of how to plan for complex, fast-moving projects because it was never meant to address it.  The Manifesto doesn’t try to give us “values” that we can apply to address every trend and movement of how software is made—it simply provides four values that historically have been secondary and makes them primary.  You can—and often should—uphold other values that the manifesto didn’t anticipate. 

If Harris means to criticize some naive "Agile" teams for failure to plan, then that is fair game.  I would join him!

Wednesday, April 1, 2015

Scrum sprint length: three, two, or one week(s)?

Suppose you are doing three-week sprints.  Should you consider moving to two weeks?  If you are already doing two, should you move to one?
Some teams want shorter sprints because they need more feedback, a quicker turnaround, and more interaction with the stakeholders.
If you are doing Scrum (or even just being Agile) well, you should be able to get lots of feedback during the sprint, regardless of your iteration length. If you feel that this isn't happening, yet you want to stay at longer intervals, consider setting up an informal demo with the Product Owner (PO) and a key stakeholder or user halfway through. This informal demo is flexible to happen more often, as much as you can benefit from it. Remember, official Scrum has the PO as part of the team all day every day. This is not commonly followed, so you have to intentionally look for ways to get that continuous, high-touch feedback from the PO. 
On the other hand, some teams want shorter sprints in order to improve focus—to truly get done with half the work in half the time.  This is the real benefit of one-week sprints; if successful, you can increase your output in that one week due to the benefits of increased focus.
Consider one-week sprints if you can possibly deliver genuine value in one week—providing the stakeholders with a potentially-releasable product. Otherwise, I'd keep it at two.
Some teams want this benefit of shorter sprints, but are wary of taking the plunge, thinking that the overhead of the Scrum rituals (estimation, sprint planning, daily scrums, and sprint review) is too high to do in one week. 
I fear this is a straw-man, worry-wart argument.  For a one-week sprint for a Scrum-experienced team, I'd hope to do the demo in one hour, the retro in a half-hour, then do estimation (which works best before sprint planning) and sprint planning in a few hours after that. I would combine these all in one day. The team may need to be involved in backlog grooming/story writing later in the sprint, but this shouldn't be the whole team, just individuals as needed. 
This tighter approach is best done by remembering the goal of sprint planning is to agree on a sprint backlog that the team can begin working on immediately, and nothing more. In my experience, a good morning of sprint planning followed by a team lunch leaves the team extra-productive for the four hours remaining, wherein they get a lot done.
I think there is a different obstacle to shorter sprints that we don’t want to admit to ourselves.  Too often teams feel two weeks is "easier" than one (And three weeks easier than two) not because it is actually easier, but because there is more time that can be wasted (or stolen by unplanned work) without being noticed. That's a "benefit" of a longer sprint you don't want. All the scrum rituals should take half as long in a one-week sprint as in a two-week sprint, so you should have exactly half the time to get done half the work--but hopefully, you will end up able to do a bit more than half the work in a sustainable, fast pace, right?  "It’s not enough time" is a smell that the Sprint length is being abused and therefore wasted. 
In the end, the team should decide 1-, 2-, or 3-week sprints based on how much they can plan with confidence and how much they can benefit from rapid feedback and delivery.