Agile values, principles, practices explained

Think back to when you were a child.  Didn’t your folks tell you to be a good little kid?  I’ll bet you didn’t have any idea what a good little kid was, but your parents infused in you the thought that other people mattered, that your family was important, that good people are kind and generous.  You probably still didn’t understand how any of this applied to you until your parents gave you a very specific set of instructions:  share, wait your turn, be polite, and don’t talk back.  Then, when your parents saw you playing on the swings, they told you to give your friend a turn.  When you went to the movies, they made you go to the end of the line and wait until everyone in front of you paid to get in.  They made you kiss your aunt on the cheek, say thank you when you got a present, ask for a second helping of pudding and say thank you when you got that second helping.  Your parents where teaching you a value by focusing on the supporting principles which in turn were supported by practices and finally implemented through techniques.

A value is an abstract, broad preferences related to appropriate courses of action or outcomes.  Values don’t change based on circumstance and can be governed by objective (avoiding pain) or subjective (wanting fame) motivations.  They reflect a sense of right or wrong.

A principle is a rule that has to be followed but can be ignored.  It’s less abstract than a value and can often be determined by looking as behavior.  Principles, in my definition support values.  So by observing a number of principles, you can often times determine a particular value. 

A practice is a set of behaviors that can be applied directly through behavior in different situations.

Finally a technique is a set of detailed specific behaviors, often tied to a particular situation that support a practice.

4 ways to keep the daily scrum from becoming a status meeting

Ah, the daily scrum, so often misused as an instrument of status (see https://youtu.be/i7_RPceEIYE for a discussion).  Often the way the daily scrum is conducted lends itself to a report of status.  The team answers 3 questions in a round robin fashion.  It often sounds like this:

·      What did you do yesterday?

I went to meet with Joe and had to fill out an HR form.  I also wrote 13 emails and filled out my timesheet.  Oh, yeah, I also wrote a little code.

·      What will you do today?

Well, I’m going over to the other building to talk to the stakeholders about next month’s sprint.  I’m also going to three meetings about the user interface. On top of that I’m going to Yorka’s Greek for a gyro with Felice.

·      Are there any blockers?

No blockers.

Not a fruitful exchange, is it? 

 

The heart of the daily scrum is to use it as a micro planning and coordination session for the next 24 hours, not so everyone can share their status.  Status can be gleaned from a simple task board, a burndown, a burnup, or other information radiators. 

 

Here’s some ways to promote focus on the sprint goal and coordination during the daily scrum:

1.     Recast the questions to focus on a consumer/producer conversation like so:

What did you complete yesterday that we can consume?

What will you complete today that we need to consume or coordinate?

Is there anything out of your control that will prevent you from reaching your objective for the day?

2.     Recast the questions to focus on the sprint goal like so:

What did you do yesterday to contribute to the sprint goal?

What will you do today to contribute to the sprint goal?

Is there anything out of your control that will prevent you from contributing to the sprint goal?

3.     Abandon the questions and focus on 3 questions and focus explicitly on coordinating like so:

In order to make progress toward the sprint goal, what do we need to coordinate today (e.g. technology, people, process)?   Make sure this question says “what do we need” as opposed to “do we need”.  The former infers something needs to be coordinated.

4.     Focus on the tasks and PBIs that are in progress. Rather than a round robin by person, the daily scrum becomes round robin by PBI:

For PBI xyz, do we need to coordinate anything for today’s progress? 

 

One more thing.  The it’s the daily scrum, not the standup.  You don’t have to stand up.

 

As you can imagine, there are a lot of other ways to keep the daily scrum focused appropriately.  Try your own experiments and inspect and adapt.  Just keep the heart of the daily scrum in mind.

Spitting stories not sprints

Splitting stories through vertical slicing is something you’ve probably heard and are practicing.  Now you’re probably thinking “I’ve done that before, this is simple.”  If that were the case, many of the agile consultants would be out of the job.  It’s harder than you think to have the discipline to slice features up.  It’s also tough to be disciplined and make sure that ever iteration has multiple features in the iteration. 

 

Often times iterations become boxes of features – when planning the sprint the question asked is “what can you deliver in 2 weeks” as opposed to “what can you grow in 2 weeks”.  Creating two week feature boxes is encouraged by a lot of authors that talk about release themes – people misunderstand that to mean that sprints should be themed.  When push comes to shove the sprint is extended to meet the completion of the theme.  Sound familiar? 

 

Thinking in terms of a pull system rather than ‘pushing’ work into a sprint will go a long way.  I’ve had students that said their software is extremely complex and nothing can be produced for weeks on end.  Consider this – do you compile and check out what the code is doing only after the end of weeks – I hope not.

 

A 2 week sprint is 2 weeks of time, not an estimate of what the team thinks can be completed in 2 weeks which is then extended to accommodate the estimated features.  You’ve got to think backwards, that will help quite a bit. 

Coach yourself out of the job

 

I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 

 

When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.

 

When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.

 

I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.