Everyone participates in iteration planning meetings

Everyone participates in iteration planning meetings

Today is the third and final day of the Agile Boot Camp being hosted by ASPE SDLC Training. I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery. I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy. In order to appreciate this article, I suggest you read my thoughts and experiences from the first and second days.

First, the excellent Davisbase, LLC instructor finally revealed his contact information. I confirmed with him it was ok to share so here goes:

Rod Ashton

rod@davisbase.org

801-918-4092

I can’t stress enough that Rod’s real world experience in corporate IT project rescue and his on premise company Agile consulting experience were extremely valuable to making this course very pragmatic. Rod would physically step from the center of the room (Agile practice, process and theory) to his immediate left (real world) frequently to segue from theory to practical real world experience based guidance. This made the course triple in value for me. Lastly, at the end of the day today on the course feedback sheet, the best I could come up with on “needs improvement” was having white-boards for team exercises.

The third day is where everything really came together. Thus, without much lead in, here are my bullet point notes from the day:

  • When asking why, consider 5 level of “why’s” to get to the bottom of the real need
  • For developers that are stuck or struggling to break down a blob of work into tasks, lead them through their internal thought process of developing the blob with “what are you doing to do first? What are your going to do next? Next? Next? …”
  • For product folks having trouble articulating what they really are asking for, try “if you could wave a magic wand, what would you want?” to break the potential log jam of real world constraints and competing priorities to get them to spill.
  • Make all changes in small increments in order to “tweak” the output in order to achieve cadence.
  • Always, rule of thumb = “simplicity”
  • Considering the above two bullets, start with 2 week duration iterations in order to get feedback sooner and see results of incremental changes sooner.
  • Agile plus continuous integration maybe the next hot thing in efficient and effective software development.
  • To start to build team commitment, PM or Agile Coach or Scrum Master lock eyes with team members to get personal commitment on initial story execution until team auto-commits by default.
  • No brainer, but how many organizations are realistic on capacity? 6 hours a day max on average of real employee productivity.
  • Everyone, everyone, everyone involved in an iteration participates in iteration planning.

I captured some helpful tips on how to establish a new team’s initial velocity:

  • Plan to do the hardest stuff first
    • Tolerance for mistakes from management, nay saying peers and others are higher initially and less so as time marches on.
  • Time box one hour for estimating to encourage quick decisions and less conversational off topic drift.

All in all, it was a lot of material crammed into three days. Rod did a great job keeping the class moving and keeping attendees awake and engaged. Plus, as I said before, his real world experiences merged with the Agile principles and process really made the course outstanding.

Now, my challenge is bring all this knowledge into practical execution with multiple agile and non-agile development teams plus non-agile infrastructure and all the classic corporate IT structures.

, , , , , , , , , , ,

Can you really multitask?

Can you really multitask?

Today is the second of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.  In order to appreciate this article, I suggest you read my thoughts and experiences from the first day.

With the basics of the history and the initial ground rules out of the way, now the class can dig into the meat of Agile.  The instructor started the second day with an interesting exercise. We were asked to do three things, each time boxed to two minutes:

On a piece of 8.5 x 11 regular white paper, do the following (2 minutes each):

  • Write as many numbers as you can, 1, 2, 3, 4+
  • Write as many letters of the alphabet as you can.  When you reach Z, start again with A
  • Write as many letters and numbers as you can: A1, B2, C3, D4+

At the end of each 2 minute writing exercise, he captured the top number of entries from the class.  What was interesting and the point of the exercise: no one did particularly well on the letters and numbers exercise.  Even the clever people that tried various techniques to write faster failed to write as many entries as either numbers or letters only.

The point = people can’t multi-task as effectively as they think they can.

Or as I’ve come to appreciate this topic:

Context switching has a price.  That price can be around a 20% loss of productivity as a whole when someone is assigned an additional concurrent task to complete.

Many, many articles support my statement above. One classic is Joel Splosky’s “Human Task Switches Considered Harmful

Early in the day, someone asked the instructor to share his opinion on if a team commits 100% to start being Agile, how long should it take to go from starting with high frustration to running smooth with little to no frustration.  Mind you, this is just his experience seeing companies and teams take on Agile, but in his opinion:

New Agile Team, 100% dedicated resources = 12 weeks or approximately 6 iterations

New Agile Team working with a vendor = 24 weeks or approximately 12 iterations

New Agile Team + vendor + contractor(s) = 36 weeks or 18 iterations

In more Agile terms, the project team requires the durations above in order to have more of a constant/predictive velocity and established cadence.

It was striking to see how the external elements of vendors and contractors double and triple the time it takes for a team to achieve a predictive Agile rhythm.

As we learned about good story creation and planning poker and relative estimating, I jotted down some Agile success themes that struck me throughout the day:

  • Product Roadmap creation forces collaboration amongst all stakeholders.
  • Serious Agile success is achieved when the business starts asking how to use Agile for their business work to be as productive as IT.
  • Stories are from the user perspective, who, what and why … if you can’t define the “who”, then stop all work/discussion on that story.
  • Agile requires a culture that encourages everyone to ask questions of everything
  • Stories can come from anyone on the team … developer has an interesting idea about a product feature?  Write up a story for the backlog.

One of the more challenging topics to get ones waterfall head around was the planning poker or story estimating.  I wasn’t alone, a number of technical folks were asking questions around how it is possible to say this work takes “8 units” without completing that phase with “ of hours/days/weeks”.  Most classic corporate IT budgeting and projects need estimates of actual X features completed by Y.  Agile works under more of a “line of credit” concept stating: given Y amount of time and Z resources, X features will most likely get done assuming some velocity with cadence achieved.  I’ve tried to capture this challenge in more detail in this previous post on “Agile versus Classic IT Budgeting”.  For many classic corporate IT shops, this is a huge cultural challenge to overcome.

I am looking forward to getting back together tomorrow for the final day of talking about how to slot in stories based on priority and work units against the roadmap as well as release planning.

, , , , , , , , , ,

Demo Early, Demo Often?

Demo Early, Demo Often?

Today is the first of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.

The first day covers the history and an introduction to Agile.  It also covers the forming of Agile teams, creating the product vision, focusing on the customer and the product road map.  The instructor was a little slow to get going, but once he got past the high level introductions and the brief history of Agile, things started to move quicker and get more interesting.  The class is full of people from all industries and job roles.  There are people from manufacturing, health care, insurance, government, consulting and financial services.  There are developers, managers, business analysts and project managers.  The class is mostly people without much if any Agile experience, so the pace of the course is perfect for the majority of the attendees.  Given my personal research and light weight implementation of a hybrid of Agile principles in past professional lives, I could see the course moving through material and concepts much quicker.

The instructor had us split into three and four person teams to do some exercises that support the content of the course.  Each team is given some very loosely defined requirements such as make paper airplanes that can achieve a certain goal or organize a pile of colored paperclips.  Once the exercises are completed, the instructor reveals the Agile specific principles involved in the particular activity.  This teaching technique is a creative way to get introduced to the theory before actually being told that theory from a strictly academic sense.  In the examples of the paper airplanes, team members self-organized into airplane designers, developers and testers based on the ad hoc team members basic personal/professional strengths.  I was amazed my high school mentally distracting interest in creative paper airplane construction coupled with the CWRU Strosacker quest to make paper airplanes glide gently over the crowd to softly bump into the main screen to the gleeful cheers of the students in the audience that came in handy today.

After today’s session, in chatting with the instructor, I learned he is a 25+ year veteran of globetrotting in order to rescue projects that are in trouble for time and/or budget reasons for American Express and other multi-national firms.  His hands on real world corporate and consulting experience gave additional credibility to the course material.  Some of his helpful, but maybe not strictly textbook knowledge shared included:

  • Demo early, demo often = don’t wait till the end of the Scrum sprint to demo the product increment.  Get feedback ASAP in order to handle possible course correction.
  • Team best practices =  Open and Honest Feedback = Direct, Specific and Non-punishing
  • Plans are useless, planning is indispensable.
  • Documentation is required, but only to the lowest level necessary.  “Do what it takes to barely get by”

I am looking forward to getting back together tomorrow to talk about creating and maintaining a product backlog, prioritizing that backlog and estimating work plus release planning.

, , , , , , , ,