Four Steps beyond “Just Start”: Assessment (One of Four)

This is the first article in a series of four, I'm going to write about four actual steps you can take in the real world to get started down the agile path.  Before I tell you what my four steps are, I want to make sure to say that there are many ways and it depends on the team, the work and the organization you belong too. That said, I think the four steps I'm gonna talk to you about, generally speaking, are a good way to begin.  These articles are missing loads of stuff that we may possibly need to care about at some point, like technical maturity, architecture flexibility, mature coding habits, and tight release planning. I am turning a blind eye to all these things for now, because maybe, just maybe, those things are all set.  Once we get our Agile process going, those things, if they are, in fact, issues that need addressing, will be exposed.

The four steps are:

  1. Assessment
  • Organize the Work
  • Develop your team
  • Understand your customer

You will notice that only the first step has an ordinal number.  This is because the bulleted steps should be taken in the order that makes the most sense after an assessment is complete.

Assessment (Sprint 0)

Anytime “assessment" is the word, we have to be careful.  People get very twitchy around being assessed, which does not mean, I repeat, does not mean judged.  What it does mean, is that we need to know where we are now before we can make a plan to go somewhere else.  Your GPS would be hopelessly confused if you asked it for a route, but were not at all clear where you wanted to start from.  “Siri, take me to 555 maple street, and don't ask too many questions”.  As you can see, it might be hard going.

To kick off the assessment, ask a few questions to the people who we hope will achieve great things with Agile. Keep in mind, how you ask these questions is just as important in how they are answered.  Just circulating a survey monkey may not get you the incites you want.  

The questions are of three types:

  • Questions about the problem we may need to solve
  • Questions about the how the people on and around the team think
  • Questions about the baseline Agile enablement level of the people on the team

Some samples

  1. Are you happy with the results we are getting now?
  2. What is the largest barrier blocking us from the results you seek?
  3. What are you doing now, or have done in the past, that work great?
  4. Why do you think doing Agile will make things better?
  5. What worries do you have about Agile?
  6. Have you had any Agile training, if so what kind?
  7. What are the top three things you believe about Agile?
  8. What is your favorite dessert?
  9. What is your favorite thing to do at work?
  10. What is your least favorite thing to do at work?

 

These questions should be asked individually to all the folks who will make contact with Agile, from the newest programmer to the most wizened executive.  Then, its best to get the whole team together to see what they have come up with.  It is important that the “assessor” does not make decisions for the team or chart a way forward alone.  The results are to be used by the team to create the themes and epics from which we will prioritize a backlog of activities that will have the greatest results for the least amount of effort. (See what I did there?)

Those epics, that are likely to be identified, are the next 3 steps listed above and covered in the subsequent articles in this series.

For more detail about putting an assessment together, I can help.  Just send an email to doug.birgfeld@theagilewave.com.  I am happy to help, or put you in touch with somgeone who can.

 

douglas birgfeldComment