Development/Scrum checklists – because no one is perfect

Checklists are incredibly useful beasts. Especially short ones. Humans tend to forget – especially when they are excited, tired, angry, frustrated or bored. In addition, if one does not repeat the same task day in, day out, it’s easy to forget what to do.

Of course I expect you have well trodden processes for issues, tasks, code reviews, coding standards and the day-to-day activities, and these are ‘fresh’ in everyone’s mind. It’s the 9am Monday, 5pm Friday activities where crucial mistakes are made.

So here are some checklists for the tail-end Scrum ceremonies and processes, so teams don’t forget to ask (or do) the basics.

I recommend you make your own checklists, which feature the questions you keep forgetting to ask, or activities you keep failing to do!  The shorter the better.

What to ask at a sprint planning meeting

  • What’s the goal/theme of the sprint?
  • What’s the absolute must-haves?
  • Can we pull in lower priority stories to increase productivity?
  • Who might be taking the build at the end of the sprint?
  • What critical deliveries are being worked on elsewhere in the company that might affect us?
  • Who are the key stakeholders that need to be involved in feedback?
  • Who is on holiday?
  • What other corporate events might take time out of the sprint?
  • What does success look like?
  • Are there any critical issues you know need fixing?
  • What stories should we groom during this sprint?
  • What items from the retrospective do we need to keep in mind?

What to ask at a sprint review meeting

  • Does this review change the priority of, or cause the introduction of more stories? Who needs to follow this up?
  • When do you need a build packaging up/distributing?
  • Who is really is going to be using this build? What for?
  • Did we meet/exceed/fall short of the goal? Why?
  • Does anyone need more information on this build?
  • How are we progressing in our overall strategy?

What to do with the build & configuration control

Hopefully much of this is already automated…

  • Package up the installations with latest documentation
  • Check digital signatures & logs
  • Copy files to a segregated area
  • Update associated release documents for ISO auditing and internal recording.
  • Make any necessary escrow deposits (don’t know what this is? See NCC).
  • Record any new 3rd party licence usages
  • Virus scan the build

What to do to with source control and other systems

  • Label source control at the date of the last successful build
  • Move any other bug tracking/task tracking software onto the next phase (e.g. TFS iterations)
  • Move any outstanding tasks over to the next sprint.

I hope you find this list useful – it’s not designed to be exhaustive or perfect!

Values Driven Development (VsDD) Part 2

In my previous post I described how we should create a list of values to drive our development.

In this post, I’ve created a fictional picture of how values might fit into the pipeline of work.

You could argue that Values should come first, and I would agree, but typically they are often secondary.

You may also notice the controversial inclusion of Religious beliefs into the value chain. Whilst the wise know that a professional work environment works best when religion (and politics) are left at home, we can’t ignore that an individuals belief system will, and does, affect the choices they might make.

Values Driven Development



Values Driven Development

I hereby coin the phrase ‘Values Driven Development‘ (Value with an S).

Please do not think this is a Software Methodology like Test Driven Development, Behaviour Driven Development, or even Stackoverflow Driven Development, which is similar to asking your cuddly toy on your desk what the problem is.

Values Driven Development is the philosophy and methodology of using ethical, moral, professional and aspirational values to drive a software development company versus the current perception of value (aka money).  Think of it akin in style to the Agile Manifesto‘s values, but prevalent at all levels.

Although there are overlaps with Tom Gilb’s Value Driven Development, my proposition is inherently different.

I will describe how a typical perception of Value could restrict corporate growth and employee satisfaction when coupled with Agile methodologies. I’ll explore some example values and how they could influence the decision making process. There’s nothing scientific, no hard data, just opinions.

None of the following statements are, in anyway, to be associated with the internal workings of MooD International.

The risks of agile pipelines

It may be no surprise that software businesses want maximize their Return On Investment, driven by C-Level ‘Outcomes’. This typically trickles down the employee stack into a value driven pipeline (Value without an S). User Stories have business value –  or they don’t get done. The backlog is filled with a large stream of valuable work that is aligned to some business outcome. The teams will be busy being successful. Sounds great, right? Let’s high five our Agile process!

Targets are targets, you’re very likely to get what you want, or probably less, very rarely more. If you think “We value exceeding targets over meeting them” is the answer, then you are a sheep. There is a huge risk that the outcomes themselves have limited the potential for growth.

Agile/Scrum can make matters worse as the teams can be lead into a false sense of security, thinking that the best work they could be doing is in this ‘value pipeline’. Depending on how good your PO is, or how confident your team is at jumping around the PO, it’s hard for the team to challenge that. The culture can quickly become purely ROI/Value driven. Which sounds great to some, but you only get what you ask for.

Usually the best ideas occur when people stop and think, or just try something else out. But when there’s targets, and a stack of ROI priority stories – failure isn’t an option, and there’s little capacity for free-thought, innovation or taking risks. Scrum can stimulate a highly intense and stressful work pattern, it’s not called a ‘walk’ its called a ‘sprint’. In all the amazing speed agile provides, it can give the impression that value is being delivered, whilst driving into submission talented, creative individuals. Today’s developer has to tolerate a vast amount of complexity in their work. Such complexity requires an amazing amount of brainpower, willpower and focus. Are we getting the most value out of them? – is the big question.

Is Agile broken?

No, of course not. The Product Owner should be responsible for making sure that they are fostering an awesome team environment, but sometimes that can be lost due to a sustained barrage of ‘must do’ work. You could argue that one possibility is to spark up an R&D agile team to allow creative software types to design and prototype new cool toys in their own playpen. – Enter the land of team-envy and reduction in team morale for all other teams! Besides, that may use only a fraction of your team’s potential. Imagine there’s a dev called Jo, Jo had all the bright ideas last year but is critical to Project X, so he’s not allowed in the R&D team. He might actually make you a few million with his next crazy idea, but still I don’t believe the answer is to move him because of his track record.  That’s just the talent you see, rather than the talent yet to be discovered.

What to do?

Change the culture. Put values first and foremost, from the top down. Make the values public, caring, meaningful. Foster the independent growth potential of all employees, not just the rockstars you know about. Let those values help guide ROI and value judgements and where necessary produce examples of how those values could manifest and change decision making.

Example Values

We value supporting employee’s creativity and innovation over continual backlog work.

e.g. Rotate employees out of a sprint to do what they want, and show the team afterwards.

We value continuous professional development over ‘resting on your laurels’.

e.g. that conference they’ve been going on about, send them on it. Insist employees keep learning, and provide time for it.

We value telling the customer the project will be late over making teams work unreasonable hours.

e.g. The cost of recruitment, burnout, morale is not free. Quality reduces in tired employees. Demonstrating integrity, honesty and caring goes a long way.

We value repeated, sustained business with customers over impulsive or risky delivery schedules

We value paying employees their fair market rate over just what we can get away with

We value quality over quantity

We value the work you’ve not done over blindly following a request

We value face to face communication over email

We value focusing on getting a single job done over having many jobs ‘in progress’.

We value failure of a task over never having tried something challenging

We value our reputation for tight web security over any customer deadline

Where’s the profit?

What’s the cost if you don’t?


My next post shows a diagram of how I see the hidden world of values being used to drive a more focused set of work items aligned to values.

Agile code reviews

Here’s the TL;DR on this video from Olivier Gourment on Agile Code Reviews.

The video refers to slides you can’t see (extra download), historical facts and books, and audience participation, here’s the short version:

  • Have a check-list for things you should do in your code review.
  • Why? Because  humans make mistakes.
  • Many industries used check-lists very successfully to reduce fatalities, improve safety, quality and to eliminate the potential for human error. It has been proved to work tremendously well.
  • Humans tend to give up if the items in the check-list are out of date, lack value alignment or are too numerous.
  • Agile teams can use check-lists in an agile way – constantly inspect and adapt them.

How do we Introduce them?

  • Humans naturally choose to rely on habits and behaviours that they find easier.
  • If you want to make a change in your organization, you have to make it a habit….. Friends don’t let friends get away with committing  un-reviewed code.
  • Keep it simple, short and valuable.
  • Once it is in place at a basic level, and habitual, the team can start adding items.
  • Code reviews are best done together. The conversation alone can invoke better ideas.
  • Decide as a team what the policy is for interrupting/scheduling reviews.
  • Try not to have more than 1 day’s worth of code, or 200 lines per review.
  • Senior developers can be reluctant to expose their code to reviews, or perform them. – it is a difficult challenge.
  • Reluctance issues can be resolved by getting those individuals to elaborate what check-list they would create for another developer, find out what is valuable to them. (Ownership and autonomy)
  • Be wary of adding contentious items, they will affect buy-in. For example,”Errors should be caught” – is non contentious. “Coding style” – is more contentious.

Do you do code reviews in your organization? Do they help train good behaviour, prevent escaped bugs? Or are they tiresome chains around your wrists? Discuss below!

How much time should a Product Owner dedicate to their role?

Given a successful product where new features and issues are always cropping up, and the PO is responsible for just ONE product, share your vote!

Daily Standups in Scrum – What’s the purpose again?

Have you ever seen heated blogs, posts and forum discussions around how evil/great Scrum daily stand-ups are?

Under the skin of these discussions I’ve witnessed some recurring viewpoints. Some angles demonstrate a god-complex or a big-brother conspiracy fear, more sane angles appear to lose the fundamental purpose with comments like “It’s a waste of time, the team can check the source control check-ins to see what I’ve been up to”. These angles miss the point – It’s all about the team. Not everyone is as amazing as the Most Valuable Player, not everyone is a great communicator, not everyone chats over a coffee in the kitchen to make sure everything is ok, not everyone checks with the testers before they check in risky code. The team is unlikely to reach it’s full potential if they don’t grasp what the daily stand up achieves.

Now, just saying “It’s all about the team” doesn’t provide enough of an answer for me, so I want to get to the bottom of the purpose of the stand-up and a good place to start is our Holy Bible, the Scrum Guide (2011). Praise the scrum god.

…[The Daily Stand-up is] for the Development Team to synchronize activities and create a plan for the next 24 hours.

This to me, is the most important point. Obviously we don’t create a formal plan, but through a quick discussion with the group we can identify quickly:

  • Impediments/Risks to completion.
  • What meetings are needed.
  • Who needs to be left alone, as they’ll be ‘in the zone’ today.
  • Who needs some pairing-up with complex code.
  • What needs testing today, or even tomorrow, so preparations can be made

Now, some may argue that these things can all be achieved without a Daily Stand-up. That assumes that everyone is capable or feels they have the authority to make those decisions, and that they’ve talked to the right person. Recently, some of the most crucial observations made in our Stand-ups have been made by the non-domain experts.

Daily Scrums improve communications, eliminate other meetings, identify and remove
impediments to development, highlight and promote quick decision-making, and improve the
Development Team’s level of project knowledge. This is a key inspect and adapt meeting.

Other than the elimination of other meetings statement – Bravo scrum gods! I strongly believe that the continual communication allows early detection of failure, and quick peer review of decisions. We possibly have more meetings than before, but they are of a higher quality, plus everyone is on the same page every day.

The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal …

The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

I’m less enthusiastic about this one, merely because a clear goal that aids focus has always eluded me. If the goal is “implementing the highest priority stories” (which are usually unrelated), rather than “improving aspect X”, then it introduces inefficiency in development and testing. If the goal is narrower and the team resists work that doesn’t aid the sprint goal, the focus and determination this affords could result in the high quality iteration Scrum promises. So, in summary, checking the progress towards the Sprint Goal is only as good as the goal itself.

… and to assess how progress is trending toward completing the work in the Sprint Backlog.

Monitoring the burn-down can be done at any time, so the assessment doesn’t have to happen in the meeting. The more important purpose is to raise the issue, and have the team come up with actions to get it back on track.

Development Team often meets immediately after the Daily Scrum to re-plan the rest of the
Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner
and Scrum Master how it intends to work together as a self-organizing team to accomplish the
goal and create the anticipated Increment in the remainder of the Sprint.

Toward the end of the sprint, the testing effort might need re-planning, but on a day to day basis we rarely re-plan the remainder of the sprint. Most of the time the Daily Stand-up is over, and everyone dashes back to their seats like drivers at Le Mans. Also, we don’t tend to pre-allocate the work. However, the Daily Stand-ups do allow the product owner to ask any team member how the goal will be progressed in the next 24 hours. Then, collaborative working tools will complete the picture, warts and all.

The Daily Scrum is not a status meeting, and is for the people transforming the
Product Backlog items into an Increment.

To me, this was the most contradictory statement when taken in isolation. In context it actually means that it’s not a status meeting for the Product Owner/Stakeholders. Obviously telling the team what you accomplished yesterday, discussing the burn down and what can be tested – is status. The main thing to note that this meeting is for the team, and no one else. Hence the pigs and chickens analogy comes into play.

So, in summary, the purpose is:

  • Quick synchronization of activities for the next 24hrs
  • Quick decision making,
  • Identifying impediments
  • keeping ‘on goal’

Please share your thoughts if you agree/disagree, as long as you leave the nerd-rage at the door!

Agile Manifesto Posters

On the hunt

I really wanted to find a good Agile Manifesto poster, and failed miserably. I can’t readily print a web page and display it, it’s too  ugly. Nor do I care to register (or provide my email details) to download a poster, that’s not a great way to engage visitors. I also encountered overcomplicated low resolution images – no use.

I wasn’t alone

It looks like I was not alone in my dissatisfaction. Rich Daley blogged about his similar experiences, and I found the same monstrosity he did. Rich was thoughtful enough to provide his own version, which I have used in conversations.

The agile manifesto presented by Rich Daley

Time to hand-crank

I created  some Agile Manifesto posters that keep it simple stupid, and deliver what I need. I didn’t need the 12 principles for a start.

They are both in A4 landscape. I quickly realized I’m terrible at info-graphics and graphic design!

Let me know if you like them, used them, or have found better ones!