Agile

Why use Story points or Time for resource tracking

/ timmeeuwissen / Leave a comment

For: team leads and Entrepreneurs

Running a service oriented business isn’t the same as running a product oriented business.  There’s a major difference and over the course of time I’ve learnt where the differences are when it comes to resource tracking, and how that may or may not affect your business.

Resource Tracking based on Time (more service oriented)

Pros:

  • enables to have specific billing, which feature costs how much money exactly
  • prospects and invoices can be compared to see how budgets are met
  • you can track individual progress and troubleshoot on real fine level when things aren’t going well
  • works exceptionally well for time-to-time small ad-hoc services

But the cons weigh more heavy:

  • time tracking is a pitfall for managers to start micro-managing
  • it kills creativity
  • it drives quality down (you assess on time, not on result)
  • there’s large amounts of overhead and overthinking for the developer
    was I effective this 15 minutes? And, I had to google a lot for this feature, should the customer pay for this?
  • employee satisfaction but also effectivity is strengthened when the employee feels at comfort. The best idea’s come to you when you’re not actively trying to solve something. Opportunity for relaxing is in that sense just as important for the employer than the employee (mind you, there should be a good balance here. Of which part of can be obtained by having a good thorough intake). When the employee has to meet up to the set 8 hours of his job he’ll feel at discomfort when he sat down and stared out of the window for half an hour, even though this time might have solved lots of other stuff. At the end of the day he or she will start with creative bookkeeping which will result in lots of negative energy that could have been used for positivity.

Resource tracking with story points (more product oriented)

When you start resource tracking with story points:

  • all points will be relative to one another.
  • developer doesn’t have to think about the client. They just have to think about what it’s relatively costing to another task
  • tasks get easier separable, since they can now be defined without having to speak in understandable business terms.
  • story points have relative value. This eliminates that the speed of the individual developer is weighed in the estimation
  • more focus towards quality

But how do you sell this:

  • Measure in Complexity and Uncertainty, not Effort
    • Complexity consists of how hard it is to clear the job. E.g. it touches lots of repositories, we have to align with lots of people and the subject is very delicate. This would be a high complexity.
    • Uncertainty gets weighed in, because it is key that during grooming sessions this factor gets reduced to a minimum. The more certain something is, the smaller the task can be, the better it is estimable but also deliverable for the allocated number of story points. So if either your PO or yourself don’t have high confidence and feel uncertain how to solve the task, you should start splitting what is clear and what isn’t, to maintain deliverable stories. External dependencies are uncertainties as well.
    • Effort gets pulled out. It’s silly to do simple stuff for lots of times and your customer shouldn’t have to pay for silliness. This is where you have to play smart, and say: changing all files by hand would take me 10 hours, so I will have to write a converter that does exactly this, this and that, which will only drive up the complexity, and thus the investment in to getting this topic solved.
      By doing this, you get rid of your legacy topics. Programmers should be lazy and automate everything they can. This should be part of the routine, because your PO ‘pays’ for your routine. Just be cautionate to not over-do it.
  • Each team will start establishing a baseline of story points that they can process in a time slot. This is your so-called ‘velocity’. You can easily divide the time over the storypoints and see what the cost would be.  Because your team is focussing on what it would cost in relative terms, instead of fitting deliverance of functionality in a timeslot (which is doomed to fail), you can calculate the cost to analyse ROI versus expected delivery date. You could then also decide to buy from external sources, since you have a good idea what it would cost doing it in-house.
  • Run through the story and write down all steps that need to be done. Now everybody should have a ground level understanding of how to solve this story. Buy a set of scrum-pokercards, count down and let everybody throw down a card. No significant differences? Quickly reach consensus and take the average if no-one objects. Some super high or super low? Let them explain and let the team learn from this perception.

Conclusion

As you might see I’m in huge favor of working in a product oriented environment. This is not always a possibility given your business model and current list of clients. If you would like to go with story points, but your clients are not ready yet, try to do this:

  • find a good size client, preferably one that favors on-time delivery more than super-detailed invoices. You need one or two good sized ones, because this will work best when you allocate one (or preferably multiple) full sprint with a complete team on this.
  • build a business case, show them your intent to deliver more consistently and be willing to invest a bit yourself. You can decrease your own investment over the course of time, but all process changes suffer from inertia so give it some of your own momentum.
  • learn from your first couple of attempts. It is more key to persist in the process than to immediately have the good numbers.
  • make sure you deliver, so make sure you have small stories with almost no uncertainties.
  • Once you have a basic idea of how much the team can do, commit slightly under it and use that room for delivering quality and optimizing your process. This allows you eventually to move the baseline up

You’ve now done what a developer would do. Apply an abstraction layer over business metrics in order for the team to work with their own currency. You’ll have a more productive, more motivated and more reliable team as a result.

Any thoughts? Let me know!

Turtles all the way down

/ timmeeuwissen / Leave a comment

A story about the risk of over-abstraction and false assumptions on technical debt.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”

The first time I’ve got in contact with this story is when I read the book Godel Escher Bach. Although it seems hilarious, it also points out that there is no solution for human stubbornness and lack of logical thinking. It is an exceptional example of missed credits for the inertia of mankind’s cumulative factual cognition, or perseverance of human-induced stories one could believe in.

Not soon after, I started recognizing some of these silly patterns in my own behavior. Of course regarding personal and behavioral stuff, but it somehow concerned me more that I noticed that these patterns can easily be found in day-to-day technical tasks. A recurring theme in my software seemed to be some serious over-engineering with abstractions over abstractions, all to separate concerns wherever possible and isolating whatever could be isolated. The layers of abstraction grew so thick that they became very hard to follow for anyone else including my future me, and I realized I needed some serious re-prioritization of what I perceived as good practice in software development.

The rule of three

It is so, so hard to leave technical debt when you’ve had a history full of it. This becomes the second nature of a developer. Remove any tech-debt up-front before it bites you in the ass afterwards. But there’s a risk in this.

We tend to prematurely optimize our code. But the risk here is that we optimize without knowing the full set of features that are required. This is when I introduced the rule of three (which sometimes is ignored, sometimes the rule of two, but don’t tell anybody okay?).

Only when you’ve seen similar functional demand occur three times, start clustering the functionality and isolate the individual concerns.

By the time you’ve implemented a third similar functionality (which usually needs some adaptions to work in a specific situation), you can tell something about the environment the component should work in.

Set your KPIs

(For those who don’t know, Key Performance Indicators, the stuff that tell you if you are doing the right thing or should pivot your efforts).

This might seem strange, but make sure you set your definition of done straight before you start the development of new features. The definition should only encompass the creation of functionality. Not the how. Just the what. Don’t create elaborate structures, but try to get to your goal the fastest way possible.

Honoring:

  • transparency
    Read your code, and let someone else read it (peer reviews). If it’s not clear what it does or how it works, it’s not good enough
  • Usage of other modules (DRY (Don’t Repeat Yourself))
    Don’t do work that’s already done
  • Don’t implement features you don’t directly need (KISS, Keep It Simple, Stupid)
    I guarantee you that the functions you consider nice to have but unused, will be the first to bring your code to a grinding halt.

You’ll need these KPIs! Because odds are that you won’t feel good – at all – about the product you’ve just delivered. There’s ALWAYS a better way to do things, and that shouldn’t drag your just created real-life value down. Satisfy your KPIs and feel satisfied. But watchful.

Observe

Take notes along the path of deliverance. Mark the project as Concept and MVP (although functionally you might feel you’re there, you can sometimes treat functionalities as separated products) and keep track of it. Observe all stuff needed in the future and observe if your suspicion of lacking features, abstractions and re-usage of code are right. If so, don’t be shy to become your own PO and create a story that removes tech-debt. If your relation to your usual PO is one that has trust in it’s fundament, he should respect this story as much as any other feature request and allocate time to remove this technical debt.

Apply validated learning

By waiting to apply all these abstractions, you enable validated learning (beautifully described by Eric Riess in The Lean Startup) to more or less scientifically confirm the future of the feature (the standard definition used in validated learning), but also the need and the focus of the future optimization.

Bottom line: You’ll spend less time, on stuff that get’s thrown away.

It’s not turtles all the way down anymore. It’s just a bunch of oddly stacked turtles on a ridge in some water on a planet.

What follows after this.

I’d still like to write a blog post about testing code. This article about levels of abstractions relates to that future testing blog post in so many ways.

If you’d like me to put some focus on that, let me know by using the poll on the right side of the screen!

Tips on how to conduct a retro

/ timmeeuwissen / 2 Comments

For: scrummasters and teamleads

The most important thing with retro’s is that you have them. But when you have them, there are a couple of things that you can do to optimize and get the most out of them.

When to do the retro

Try to schedule the retro after the sprint, around the moment you do your demo. Since the team will already start looking back on two weeks and see what has happened and how they can demo their achievements, this is an ideal moment.

Use sticky notes

Let everybody write down their own positive and negative points on sticky notes. Some members may come prepared with some sticky notes that they have gathered during the sprint (if you see that there’s not enough quality feedback you can suggest doing this to the team). Each note can get a + or a – in the top.

Create a board with two or maybe three lanes. A lane for things that didn’t went so well and a lane for positive things. When someone is done, let them put their notes on the board. Each member can see if one of their points was already put on the board. If so, let them stack. Big stacks, usually indicate big concerns regarding that point.

Some benefits of doing sticky notes instead of going sequentially through all members:

  • everybody can write down their own thoughts, and don’t have to remember them through the talks of others
  • you can monitor actual participation in the retro, instead of having a ‘what he / she said’ or ‘I have nothing’ answer
  • you get to know some sense of how big a concern actually is
  • you can take the notes with you to process them later and not have everyone waiting for you

What to put on the notes

It’s important not to narrow the scope of these points. Let people tell that they’ve had a good barbecue, a nice birthday or a dog that died. Because influences from our personal lives into our professional lives, are as real as the other way around. Being able to briefly share your joy or sadness on something, makes this meeting something to look out for, and it’s an easy way to share stuff with your team and fortify your future collaboration. When a team member feels heard and seen, he’ll tend to stick around longer.

Run through the notes

Start with the points of concern. This is because of two reasons. You don’t want to spoil a good vibe, and people seem to cling on to the vibe they left a meeting with. This way, the momentum you’ve built during the discussing of positive things will carry on after the meeting. Create piles of all + and – notes

Guiding the meeting

Rotate members to read the cards (different member per retro). This trains them in speaking and conducting meetings (even though this is a very small and safe meeting), which will help them in the future. Also, you’ll prevent biassing the meetings with the tone of one person that always reads the cards.

Let someone take notes, but only on the action points. So when the team discusses the cards, only write down how they think they can do better. When the meeting is over, create a page with a retro template in Confluence (or any other tool you use). Take the stack of + cards and write them on the column ‘what we did well’. Take the stack of – cards and write them on ‘what should we have done better’, and take the notes of the discussions and put them on ‘actions’.

Revisit the list of previous action points at the end of each meeting and compare them with the list of actions from the previous time. Don’t add unsolved actions to the new action list. When an action didn’t get recurrence, it fell out of grace and might have not been a thing for an action point after all. Do ask which of the actions have been done, and update your previous actions so they get marked done. You can look over-time if actions get recurrence. This enables you to detect inefficiencies within your way of working.