Feeds:
Posts
Comments

Archive for the ‘Agile Back to Basics’ Category

In a recent tweet,

If you must do some pre-project prep, so be it. Please don’t name it “Sprint 0″ that makes it seem valuable. It isn’t.

Delving further into the tweet I learned that “many use Sprint 0 to enable bad habits” (don’t disagree), that it maybe should be called “project chartering” instead and that a more common definition of a Sprint is “a time-box for delivering a Product Increment”.

So what is the common goal of a Sprint 0?

Starting-Line-300x200The Sprint goal (by my definition) behind a Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable”. If you are ready to deliver business value then Sprint 0 is officially done.

Do all projects need a Sprint 0?

I say projects here quite deliberately as a team that is already functioning and already delivering are highly unlikely to need a Sprint 0 unless a specific set of features coming up dramatically impacts the ability to deliver business value inside of the Sprint.

If your organisation is onboard the DevOps train and XP practices are well established then you may not need a Sprint 0. If environments can be created and built upon in a day, if standards and frameworks are well understood then you may be ready to start delivery business value straight away.

This ultimately is highly dependent on your organisational capabilities.

Where does story elaboration fit in with respect to Sprint 0?

Teams quite commonly use the time whilst in Sprint 0 to also elaborate further the User Stories for the first value delivering Sprint.

You don’t have to have elaboration one Sprint ahead, but it can potentially help reduce carry overs, reduce time spent in Sprint Planning and ensure that task cards (if you use them) are well defined.

In an ideal world User Stories would be small enough and complexity low enough that carry overs are minimal and elaboration can occur within the Sprint.

What cadence activities should occur in Sprint 0?

Sprint 0 should be, from a process perspective, exactly the same as any other Sprint. It should be planned upfront through Sprint Planning, work should be broken down into items that are achievable within (ideally) 1-3 days, it should be slapped up onto a story wall/task board and tracked, Daily Scrums should talk about what everyone is doing and enable collaboration and sharing. At the end of the Sprint you should demonstrate what you have achieved within the Sprint Review, “Hey take a look at this box, this is the box that builds our code and automatically deploys it. Here look at it compiling and this is the result (good and bad) that it generates”. The Product Owner may not care but I can assure you the rest of the team will. Additionally it is a great opportunity to start reflecting about how you have worked together as a team and see what can be improved.

Just as per other Sprints the work that is done in Sprint 0 should be prioritised. If it doesn’t enable you to deliver software in a Sprint then it probably isn’t high in priority.

So in essence, all the standard, normal Sprint activities that occur when business value is delivered should also occur in Sprint 0.

How long should Sprint 0 be?

Just like value delivering Sprints, Sprint 0 should be timeboxed. The ideal value to set this timebox to is the same duration of your value delivering Sprints. When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process – were you able to achieve what you had planned?

The trouble with this is that in almost all cases the team’s velocity has not been established and consequently the likelihood of not delivering to expectations is high. If you are going to fail on estimation versus delivery (which I can safely say you will) then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message? How long will it take for pressure to be pushed onto the team?

For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This is where the concept of “Sprint 0″ as a term fails and you see people then try to fix it through using “Sprint -1″, etc. This slippery slope further erodes management trust.

I fail to see a magic bullet for this particular problem other than having good planning upfront and always asking “do we really need to do this to begin delivering value?”

What if the team is able to deliver value earlier than then when the Sprint will end?

Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates. If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint.

What if the team is unable to deliver value by the end of the Sprint?

If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little. If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now?

How long after Sprint 0 is finished should you wait to start doing Sprints?

Don’t wait. Get started delivering that value!

Where does team onboarding fit in?

The day you start Sprint 0 is the day all the team should be onboard. Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops.

What are the common pitfalls of Sprint 0?

The obvious one is that teams never get started delivering business value. They stay in this mode of never being ready and there is no drive or motivation to move out of it. Sometimes this is for very valid reasons, for example, developers don’t have PCs or an environment to work in; but often it can be just rats and mice outstanding.

This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner.

So what is the Scrum Guide definition of a Sprint?

The Scrum Guide defines a Sprint as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

So by the above definition it is wrong to call everything that I have said above a “Sprint” because it doesn’t result in a potentially releasable product.

But the Scrum Guide goes on to say:

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective.

which aligns with the above activities that should occur as you prepare to deliver business value. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity (the initial backlog creation being a great example).

What’s in a term?

If you should have for Sprint 0 a Sprint Planning Meeting, Daily Scrums, dev work, Sprint Review and Sprint Retrospective why would you not have a term for this special case that does reflect the word “Sprint” in it, after all, three of the cadence activities in them have the word “Sprint” in them.

If you want to use a different term, lets say “Project Chartering” then you are still having a Sprint Planning, Sprint Review and Sprint Retrospective… but not in a “Sprint”. This seems a little odd and misleading to me.

I feel that the messaging to people starting Agile should be clear and simple and removing the word “Sprint” does not align logically with that. I feel that the word “Sprint” is incredibly applicable and that the definition of “Sprint” in the Scrum Guide needs some common sense flexing of interpretation. I don’t expect the Scrum Guide to change, but do expect some guidance somewhere about how this pre-Sprint is a special exclusion from the delivering of value component in the guideline.

You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.

So what would I call it? I agree that the ’0′ in ‘Sprint 0′ is misleading. I would call it something like ‘Delivery Enabling Sprint’. Make the implicit explicit.

Read Full Post »

A little while ago in a private Agile forum I saw a post by a person who was very frustrated with Agile.

Their main concern was over the manifesto value “Working software over comprehensive documentation”. The scenario that they presented was one, where as a Product Owner, they wanted to understand a few of the business rules that the product had within it. They were informed by the product development team that they would need to create a user story for it, prioritise it against the backlog and when it hit the top of the queue it would get done.

Now the Product Owner chose to put it midway through the queue, but they were still unhappy with the fact that given the team’s backlog it would mean they would get their answer to what they felt was a simple question in two months time.

Why can’t I have just some documentation so that I don’t have to wait two months to get an answer on this? If we were still using waterfall we would have the answer right now.

A few people responded that Agile doesn’t mean no documentation, that there is often the documentation that is needed, but obviously this was one of the rare cases that the needs were greater than normal.

My thoughts on the problem raised were almost completely different:

  1. By not spending time documenting everything the team would have saved time over a prolonged period. If the team had spent time documenting everything to the nth detail then it might have taken a total of two or three months additional effort, for something to only be requested once. Now think about how much extra development work, actual beneficial changes to the customer, that they would have delivered in that time.
  2. The Product Owner chose to prioritise this knowledge below half of the outstanding work. It was always in their power to make it the highest priority item if they wanted to.
  3. There is a bigger issue that is being ingored or overlooked – the fact that the team had a four month backlog. I am not saying that a four month backlog is wrong, I am saying that a four month backlog is worthy of investigation to see why it is so long and whether something can be done about the constraints in the system to lower it. Think about how the team may feel knowing that there is four months of work hanging over their heads. They are unlikely to feel inclined to innovate knowing that there is so much that the product owner still wants delivered.

Do you think if the backlog was only a week long that the original forum poster would have made a comment about the Agile manifesto not working? Of course not, they would have waited only a week to find out that information and the team would have been considered responsive in their eyes.

Read Full Post »

As part of my back to basics series I wanted to spend some time on the topic of Retrospectives, otherwise known as Introspection or Reflective Improvement sessions.

If the Stand-up is the bread, then the Retrospective is the butter. It is simply just one of the most fundamental elements of doing/being Agile there is. Alike Stand-ups, they are just as easy to be ineffective.

At its most basic process this is how to run a retrospective:

  1. Get the core team together
  2. Give the core team 10 minutes to brain-storm their thoughts on how the last Sprint/<insert cadence cycle> went in terms of:
    • What is working well?
    • What to do differently?
    • What still puzzles us?
  3. Group like thoughts together
  4. Choose items to focus on and address
  5. Make actions

Let’s break these items down a bit more:

Get the core team together

It doesn’t have to be in a meeting room. It can be in the pub or in a park. In fact, the team don’t even physically have to be together – you can do retrospectives virtually using a tool like LinoIt. What is important here is that the team needs to feel safe to speak freely and that there is an environment where there are no elephants on the room. If you have a Project Manager or a Product Owner that will not be conducive to such an environment then you have a bigger problem here – re-focus the  retro on getting this fixed!

Brainstorm for 10 mintues

There are five points I want to make on this sub-activity:

  1. The duration to reflect on is not important, but framing and frequency is. Retrospecting once every three months is not being Agile. The more frequent you can do this activity the better. Keep in mind, as you increase the frequency you may need to spend less time doing this activity – ie if you choose to retrospect each day then it could be a ten minute activity.
  2. Ensure the brain-stormed items are put on a single post-it note and are clearly legible so that you can take a photo of it later. There is nothing more annoying then spending time capturing/documenting the retrospective. Take a photo of the outcomes and stick the photo on your team’s wiki.
  3. I sometimes like to add a fourth item, “Lessons learned”. I believe that celebrating what we have learnt together as a group is very powerful and enables both sharing of information and a recognition that we aren’t perfect and it is a good thing to always learn.
  4. Sometimes people like the second question to be phrased as a negative and not solution focused question – ie “What isn’t working well?” vs “What to do differently?”. The benefits of the “What isn’t working well” approach is that it doesn’t assume root cause and leads to potentially better solution analysis later within the retrospective. The downside is that for the people that aren’t good with dealing with criticisms this can sometimes be confronting. I don’t think it matters which you choose, just be aware of the risks given the wording and work out which format better suits your team.
  5. The focus on the reflection is not what was produced but how the team worked together to deliver.

Group like thoughts together (affinity mapping)

Notice that I didn’t say how to do this? That is because your mileage may vary based upon your approach. The Scrum Master can do this once everyone has written their thoughts, or the core team can do it themselves – either one at a time or as a collective. You can read them out or get the team to quietly read it themselves, the options are really endless. My personal preference is to get the core team to affinity map themselves and then to verbally skim through the non grouped items and spend more time on the strongly grouped themes. Items under “What still puzzles us” should be answerable on the spot or may become a focus area.

Choose items to focus on and address

Usually I would choose the strongly grouped themes but there is a risk that you miss something important that can significantly improve your ability to deliver as a team. What is important is that the items you choose to focus on are the ones that will result in marked improvements for how the team will work together.

It is a rookie error to focus on ten things within a single retrospective. If you have two weekly Sprints, you ideally don’t want to focus on any thing more than three (five at absolute tops) actions. This is because you want to ensure that you are making changes and if you have too many actions then nothing will change and then you will loose all support from the team for doing this practice in the future.

Who makes the suggestions of the changes? The core team does. It shouldn’t be the Scrum Master who is imposing change on the team, it should be the team embracing an environment of continuous evolutionary improvement.

Make actions

So along with only having three actions you want to ensure that these actions address the root cause of the problem (ie you are not solving the wrong problem), that the actions have clear owners, dates (if possible) and value.

The best actions I have ever seen out of a retrospective are ones that the team writes as stories and then feeds the stories back into the release or sprint backlog – ie they get treated like everything else. Because they are treated like everything else they get a priority and estimate which means that they have to have value as agreed by the whole team in order to work on them in the current Sprint.

If you aren’t going to write them up as stories and add them to your backlog(s) then make sure the first step you do in your subsequent retrospectives is to review previous actions. It is a smell when actions get carried over from retrospective to retrospective – it is symptomatic of items that weren’t perceived as important or that the team feel that continuous improvement is not important.

Conclusion

Software development isn’t simple. The only way that we can improve in the complexity that we are working with on a day to day basis is the reflect and adapt. Sprint Planning and Sprint Reviews are the way in which we reflect and adapt the work we are doing. Retrospectives are the way we reflect and adapt how we are doing our work.

Read Full Post »

Can them what you will – Daily Scrum, a Huddle or a Stand-up, but whatever you call it a Stand-up is one of the simplest Agile (and arguably knowledge and service management) practices  out there. Three questions are answered by the “core team”:

  • What I’ve done since we last met…
  • What I plan on doing till we next meet…
  • What is impeding me or may soon…

Simple right? Wrong!

These very simplistic set of steps have led many to believe that the key purpose of a Stand-up is as a progress report. To set the record straight:

The key purpose of a Stand-up is the opportunity to collaborate, share and support each other in the delivery of valuable outcomes.

For those that may not have heard of the above interpretation of a Stand-up’s purpose then let’s take the opportunity to understand it further. As each person answers the three questions what the rest of the team should be doing is listening and wondering to themselves the following questions:

  • How will this impact me?
  • How will this help me?
  • Will my work impact them?
  • Can I help them?
  • Can I potentially learn from something they are doing?
  • Can something I’ve done in the past be useful so that they can learn from it or re-use it?

If the answer is ‘Yes!’ to any of these questions then the team member should pipe up and respond. An effective Stand-up isn’t just the team turning up on time and answering the three questions – it is where teams work together to deliver and reach the delivery goals whilst always upholding the values and principles.

Another common Stand-up myth is that they should be 100% valuable to 100% of the core team 100% of the time. This is simply not the case. As we now understand what an effective Stand-up is you will be lucky to find these opportunities consistently and rarely more than three times in a single Stand-up. In fact, you might go through a few Stand-ups before such an opportunity arises – these uncommon instances of “I’d love to learn more about how to do that, care we pair?”, or “I’ve had a similar problem on my last project let me send through to you what we did”, or “I know that person well, let me talk to them and try to push the impediment out” are what make good Stand-ups.

We’ve all heard of tips like taking difficult conversations offline, ensuring everyone can be heard and timeboxing each person to no more than 2 minutes but here are a few tips that I would additionally recommend to make Stand-ups a little more effective:

  1. Touch your cards. If you don’t do this as you are talking the team is mentally trying to match the first sentence of what you said to the Story Wall. As they are doing that mental matching they are no longer listening to what you saying which consequently invalidates the value of the Stand-up.
  2. Take 2-3 mins before the Stand-up to jot down what you want to remark on. If you don’t do this you dramatically increase the likelihood that you are spending time, whilst others are talking, concentrating on what you are about to say. You need to be in the moment of what the team are saying, not what you are about to do.
  3. Jot down any issues or risks remarked on. Ensure that they are visibly attached to stories with clear owners and status/actions.
  4. Hold each other accountable if a team member is talking about work that isn’t reflected on the Story Wall – get the story written up and prioritised against everything else on the go.

Note: Astute Agilistas will notice the subtle changes in the core three questions. Primarily this is because I have seen effective Stand-ups that whilst they are regular and frequent shift away from the activity being daily. Additionally I like to tack on the “or may soon” to the last question because whilst the question focuses on issues the “may soon” is a focus on possible risks.

Read Full Post »

I have been pondering lately what the purpose of a Scrum Master or Iteration Manager is.

Many believe that it is a 100% full time role. Some are even concerned that there are formal positions springing up for this role.

Here is my stance (and work in progress model) on the role:

The purpose of the Scrum Master role is to create a self autonomous team through the usage of Agile.

  1. It should never be considered a 100% full time role.
  2. It is a transitory role – there to enable a change in the team.
  3. The change is a change from an environment of Command and Control to an environment of autonomy and empowerment.
  4. The goal is to deliver value to customers frequently and regularly through creation of this environment. The goal is not to have a Scrum Master job for life.
  5. They do this through a series of steps.
  6. These steps are based on Situation Leadership with some tweaking:
    • Directive – The Scrum Master is telling the team what to do and how to do it. This is sometimes common when the team is new to Scrum/Agile and are still learning the rulebook.
    • Facilitative and Advisory – The Scrum Master facilitates cadence activities and advises the team on possible options but is not the final say.
    • Cross Facilitative – The Scrum Master engenders an environment where other team members are starting to facilitate the cadence activities. At this stage the Scrum Master is no longer rounding up everyone for the Daily Standups, instead the team self form and remind each other.
    • Coaching and support – The Scrum Master is only there to course correct and even then only does it through team reflection. They don’t advise on options, instead they engender an atmosphere where the team can come up with their own solutions.
    • Double loop learning – The Scrum Master is ready to hand over the team to itself. The team reflect not only on how they are working together but why they are doing practices in a particular way. It is creating an atmosphere of learning transcendence.

So what, you may ask, does a Scrum Master do as their time with the team whittles down? They do what any good team member in a Scrum team should do – they deliver User Stories!

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers