Goal Setting in an Agile World

A friend recently sent an email to me asking this question:

We are introducing a “new” goal-setting system (meaning we’re just emphasizing the need and value of setting goals) and are also emphasizing agile development in engineering – which means we are running into the classic “but if we’re truly agile, how can we set goals more than a sprint or two out” argument. Wondering if you have any insight into the types of goals that teams running scrum can set – both individually and as a team.

Setting personal long-term goals is an area of self-improvement. To break that down into smaller chunks that could be completed in a given Sprint (my time or the company’s) is a great way to ensure I am making progress against this goal. If this is formal, I can make a plan with my manager and turn that into a personal backlog. Having a personal backlog for self-improvement is a powerful mechanism, assuming I respect and use it.

Team level goals are similar, and it often helps to take a goal and break it down into actionable deliverables or changes in behaviors that a team can try in a given Sprint. We’d not want to vary more than one or two variables per Sprint, but keeping a backlog of steps to get to that goal is important to continued pursuit of it. In this explanation, I am assuming we aren’t talking about product goals, but actual team goals. Things like, “We need to create a CICD pipeline.”

Projecting out a deliverable in terms of product features is only slightly different. One can decompose a feature or set of features into a larger product backlog and estimate the items in that product backlog, giving the Product Owner what they need to roughly forecast into the near-distant future. For far-future product goals we simply recognize 3 things. 

  1. Using a team’s velocity, we can forecast into the future most likely delivery dates a feature will be ready or most likely features a product will have by a given date. We cannot fix scope in a time-bound delivery model. We cannot fix time in a feature-focused delivery model.
  2. We may decide to pivot our product direction mid-flight and that needs to be okay, because we will likely only do so to provide more value to a customer in less time. This can leave a product backlog in place that we worked hard to create, but may well abandon.
  3. Any requirements we don’t implement were waste. We spent time to create, estimate, and manage them, but chose not to implement them. This isn’t heresy, but we should realize that work decomposed to the team level will likely change, especially work projected farther out than 3 weeks or so.

 We must set goals to work toward, even in agile work places, but we realize the goals may change as we learn more while building out our product and frequently delivering to our customers. Goals aren’t bad and they aren’t anti-agile in any way.

MVP for Android Apps

I’ve been working on my first (and very simple) Android application. I’ve been using a Model View Presenter approach and wondering if this is a typical pattern used by Android developers.

The main Activity is acting as the view and I pass it into the Presenter so both are aware of each other as illustrated below. The Presenter itself implements an IObserver interface that watches for state changes in the model, by having the model call IObserver.update. The Presenter then queries the Model’s state.

The Model’s job is to manage it’s own state and that of the ViewModels it returns, which are then bound to the Activity by the Presenter.

It seems to working quite well for me and avoids all the approaches I see online wherein people put business logic into the Activity itself.


MVP Android

One Thing DevOps Does to Scrum Teams

Yes, DevOps has fundamentally changed the way we operate in a good and healthy way. Development teams being part of the care and feeding of the systems they produce increase quality and will eventually automate the CICD pipeline as close to production as possible, if not all the way.

Even so, many of the Scrum teams I work with feel overwhelmed and even distraught about the work they don’t get done during the Sprint on their product. This is most common among teams who assume ad-hoc or interrupt work will not disturb their capacity to get work done on their core product.

There are 2 common sense ways to deal with this problem.

  1. Pull less work during Sprint planning.
  2. Pull less work during Sprint planning.

Most teams come to this realization on their own, but then struggle with the minutia of how to track the 2 types of work they are now responsible for: operations work and product development.

There are 2 main ways I have seen teams mitigate this tracking of work. One looks like the image below, and teams associate all operational work with a reserved User Story for just this purpose.

Scrum Board

These teams will often pre-size the Ops User Story based on previous experience of how much operational work comes into the Sprint vs. product development.

I’ve seen examples of operational items with up to 50% of the team’s capacity reserved. This is a team in trouble. They are on the verge of becoming an operational team that no longer adds features to a product and thus no new value to the customer.

At any rate, in my experience most teams settle into about 10% of their time being reserved for operational duties in DevOps environments. This informs the size of the operational Sprint item during Sprint Planning and tends to work well enough.

The thing I don’t care for in this model is that it doesn’t shine a bright light on the operational work, which is, in fact, bad. If we had no operational work, after all, we would be adding product features.

Since we are focusing on the tracking mechanism, another other way I have seen teams visualize the operational work they must address is through a fire lane. A fire lane may take the form of the board we see below.

Fire Lane

I far prefer the fire lane model as does not obscure the operational items and makes them very visible. This can lead to pattern recognition. “We need to solidify our integration testing,” or “We need to close the gap on automated container deployments.”

This technique makes each and every item visible to the team and can be examined during retrospectives, potentially causing a team to expand its definition of done.

While there are undoubtedly many other ways to track operational vs. product development work, the technique to do so should draw a very clear distinction between the two and highlight operational work in such a way as it can be mitigated over time. One step at a time, just like paying down technical debt.

Team Safari – Beating the Central Services Team Problem


The Central Services Problem

In large enterprises, a customer-facing product development team often has dependencies on other teams for frameworks, underlying systems, and (very often) centralized platform APIs. The most common scenario in large enterprises is a central Platform Services team that provides APIs to product teams for access to underlying data and service workflows.

The point of this post is not to critique that model, but instead to accept this model exists and work with it as best we can. These central Platform Service APIs are a product in themselves, with customer-facing product teams as customers. 

Delivering a full slice of functionality of a given feature is the only true example of delivering value, but this can be challenging when team dependencies like this exist, which they often when dealing with scale. This central services model can produce frustrated customer-facing application development teams because they may be waiting on a Platform Services API team to provide those services or endpoints they depend on. So, what does the product team do? They can:

  1. Mock out the Platform Services API based on proposed contract (which may change)
  2. Put in an abstraction layer over the Platform APIs that would be unnecessary should the services be directly available, because it’s easier to mock and doesn’t predict service contracts. Then mock that, adding a layer of premature abstraction to your design.
  3. Send the Product Owner over to fight for positioning in the Platform Service team’s backlog. (This should probably happen anyway, but let’s assume that fails because the product team needs aren’t at the top of the list).
  4. Submit a Pull Request to the Platform Service team’s repository to provide the service capabilities the product team needs.

Ding, ding, ding. That last one is the right answer. The product-facing team submits a PR to the Platform Services API repository. What a great solution! The ultimate prescription for success here is to use an internal open-source workflow model and submit code to the Platform Services team to accept into their codebase.

Then the PR is rejected for a myriad of reasons that boil down to the PR-issuing team not understanding the conventions and policies of developing code for the Platform Services team APIs.

A Team Safari

Consider a Team Safari (we call these Agile Safaris at GoDaddy).

A Team Safari is when one or more members of a team leave their home team to join with another team for a Sprint or two to solve a problem and learn more about that team’s software systems.

Why would a we do this? After all, it decreases the capacity of the team left behind for the time the team-member is away. Further, the receiving team capacity is eaten up teaching the new developer how everything works.

The short answer is everyone benefits from high-quality PR being accepted. If the product-facing team can issue PRs that get accepted to the Platform Services team, everyone benefits. The Platform Services team grows its API services footprint. The customer-facing team gets the service it needs.

A Successful Safari Recipe

When a Team Safari is used, there are some ground rules to help things go much better than for a developer to just move a desk over and announce, “Here I am! Safari me!” In addition to core platform capabilities, the visiting engineer will greatly benefit from gaining a working knowledge of all aspect of the visited team practices, patterns, underlying architectures, etc.

First and foremost, ensure the Engineer on Safari is there to solve a specific problem, or learn a specific skill. This should be summarized in a clear and concise “purpose statement” everyone involved understands.

If the following are approached methodically, once the engineer returns to the home team, he or she will later be able to issue successful PRs to the team visited. The following knowledge will help ensure those PRs are accepted the first time.

  1. Standards, conventions, and architectural guidelines of the Platform Services APIs public interfaces.
  2. Standards, conventions, and architectural guidelines of underlying systems capabilities including data access, logging, security, etc.
  3. The underlying language (probably a prerequisite to the Team Safari anyway), documentation, and coding standards.
  4. Full understanding of the CICD team’s CICD pipeline, to ensure appropriate unit and integration tests are included with the PR and pass appropriately.
  5. The specific test-first or other developer testing practices used by the visited team.
  6. The greater architecture (if applicable) of the visited system, framework, or technology if appropriate. Not just solving for the stated purpose, but doing so in the visited team’s context.
  7. Any teams and system the Platform Services team depends on, and how those dependencies relate to each other. 

Paying Back on the Investment

Not only does the Team Safari inform the developer who went on Safari, but that knowledge eventually gets transferred back into the home, or product-facing team then the developer returns.

And now, we don’t have to wait for the Platform Service team to work our Product Backlogs to the top of the queue. The newly informed team has someone who can create real PRs that are accepted and deliver on the promise of working software each Sprint.

As stated, the visited team now has the added capability the accepted PRs provide. Everybody wins.

Do you and your teams use Team Safaris or something like them? Let e know in the comments.

Leftover Work in Scrum

I recently received an email from someone who had taken one of my Scrum courses on Pluralsight. He asked:

  1. For the next Sprint, how is this unfinished User Story/Documentation task handled and is the User Story re-estimated for its remainder to arrive at Story Points?
  2. If the User Story is not considered for Sprint 1 Velocity given that it is not complete, and if its considered entirely in the second sprint when complete, this will skew the Velocity. As organizations love to measure Velocity and would like this to be fairly consistent, it does not help. Wouldn’t it help to have the story points prorated for Velocity discussions? If Documentation would have taken 2 % (we can use task estimations in hours to find out the relative contribution), we can consider 98% of the story points for velocity. What do you think?


This was my reply to this poor soul who is clearly being beaten down by a manager or someone else who doesn’t understand what this whole velocity thing is all about.

I do not advocate for re-estimating the work. Just leave it on the board and let it finish, taking the Story Points in the next Sprint. It will all come out in the wash. Just try to limit this by learning to plan better to your team’s capacity.
Trying to arrive at a consistent velocity is a dysfunction. Take the averages and don’t work about Sprints being consistent. What happens when people go on vacation, become sick, etc.? Velocity is a historical record and lagging indicator. It is a poor predictor as a leading indicator because of the reality of life.
I hope this makes sense. In short: Don’t let the process beat you to death. Let it flow and don’t worry so much about perfection 🙂

Mac – Install Xcode for git?!

It is so lame that I have to install Xcode to get git to work on the command line. I did’t have this problem last time I used git, but I just a few days ago upgraded to Sierra and I received this message while trying to clone a repository from GitHub.

git clone https://github.com/dstarr/intellij-community.gitxcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

Aaaand, lame. I don’t think I’ve ever read a really long license agreement via a terminal window, btw. That was a thing to behold.

That said, once I installed the tools, Xcode reqs, everything was peachy and worked fine.

Here’s to doing that in the shell:

xcode-select --install

Or if you already have Xcode

xcode-select --reset

Yep, I’m in Mac all the way now. Instead of griping about MSFT tools, I get to gripe about other tools 🙂 Stay tuned.

Starting the New Year with Less

I would like to make a more concerted effort to post a bit more. Not necessarily huge, rambling tomes of articles, but short and meaningful drips of things I learn, experience, and encounter along my professional path.

So, first things first! I am starting the new year with an old technology purge. This is actually taking longer than I’d thought because of all the unidentifiable cords, power adapters, and other detritus that’s piled up in my office over the years. The three things I did manage to accomplish yesterday were to:

  1. Admit my old Windows Home Server adds no value and put it on the “take to e-cycling” shelf in the garage. I pulled all photos from it, out them up in my personal OneDrive, and pulled the plug.
  2. Gather together all my old cords, mice with wires, some mice without wires, 4G thumb drives, and other do-dads. Those still need to be sorted so I can put most of that pile on the “take to e-cycling” pile, too.
  3. Pull all my old books I will no longer receive value in owning from my shelves. Put them in a box and was pretty stunned at how much it weighs. I guess I’ll donate these to Goodwill or something, but below is a picture of my first real book purge.

Book Purge

I hope this is a good start to the year.

What can you purge from your life that would make things feel lighter for you?

Attributes of a great development team member

My boss’s boss recently asked me, “If an Agile leader were to outline the top characteristic of their best developers, what are they? “

The response was relatively quick, and rather “off the cuff”. After re-reading it, I like my answer!

  1. Seeks to help others with any aspect of product development, regardless of her individual specialty
  2. Independently pursues continuous learning and shares new knowledge with the team
  3. Encourages and enacts technical practices to improve code and product quality
  4. Collaboratively and respectfully engages during all Scrum events
  5. Pro-actively seeks and provides feedback on code and the product being created
  6. Encourages, coaches, and embodies team-level agility
  7. Respectfully collaborates with other teams to ensure valuable features are DONE within each Sprint
  8. Embraces and actively supports organizational-level agility
  9. Enacts and coaches product instrumentation enabling Build > Measure > Learn

What’s missing from this list?

What could be improved in the original list?