Archive for the ‘Tools’ Category

• Reading List (1st Half of 2010)

  Date: 2010.08.23 | Category: Agile, Coaching, Communication, Documentation, Lean, Personal, Retrospectives, Scrum, ScrumMaster, Team, Tools, Training, Transitions | Response: 0

  Wow!  I have read a LOT in the last six months!  I guess that is one of the advantages of being on the road for about six months.

  1. Understanding A3 Thinking – excellent description of how to use and create an A3: a Lean tool for executing Plan-Do-Check-Act (the Deming cycle).  This is the definitive source on A3, Henrik Kniberg has an Agile example and template on his site.
  2. Getting the Right Things Done – good description of the concept of True North, developing strategy from True North and the respectful nature of Lean, the rest is kinda dull.
  3. Pedagogy of the Oppressed – unique perspective on the characteristics of oppression, the oppressed and the oppressors; liberation for both the oppressed and the oppressors originates when the oppressed become fully engaged in the human dialogue of being, not simply exchanging roles with the oppressors.  Interesting connections to corporate life in the 21st century.
  4. Project Retrospectives – discussion on the importance of making a deep-dive examination of a software project when it finally is complete with detailed exercises and agenda.  This is great book if you want to know more about retrospectives.
  5. More Secrets of Consulting – just brilliant!  If you liked the first book, this one has so many practical gems for the consultant.  The only tedious parts of this book are the references to his other books.  My favorite tool: the Wishing Wand.
  6. The Future of Management – this book was a favorite of the CEO at my last client.  There are many Scrum concepts in the case studies provided.  Too bad that many of the principles of self-organization and empowerment supported by the executives never filtered down to the teams
  7. Coaching Agile Teams – WOW!  This is an awesome book, deep and rich with many profound insights on the various roles of an Agile coach.  In addition, Lyssa provides practical tools to improve both the coach and the individual.  This is definitely a book to return to again and again.
  8. Training From the Back of the Room – this is my favorite book from the last six months since it has had the most impact on my personal performance.  It has changed my perspective on how to train adults with its sound theory of education and myriad of exercises which bolster learning.  Share this book with anyone who trains adults (thanks to “Agile Bob” Hartman for tweeting this book title!)
  9. Practices for Scaling Lean & Agile Development – comprehensive companion book to Scaling Lean & Agile Development (which is very good on Lean and Scrum).  This book is full of good stuff, but just too long.  Unless you are a guru (or wanna be), stick with the first book.
  10. Succeeding with Agile – Mike Cohn has put out another great book based on his years of practical experience with Scrum.  This book is also pretty long, but not tedious.  A great read if you have some experience with Scrum, but want to improve the overall experience, apply targeted improvements or figure out how to expand the reach of Scrum in your organization – it covers it all.
  11. The Back of the Napkin – provides a framework on how to apply visual thinking tools to explain and sell ideas.  Since most of the work I do is conceptual, being able to draw a powerful picture is a useful skill.  A nice addition to my consultant toolkit and I look forward to sharing it with others (I didn’t find the companion book that useful, so skip it).
  12. Hitchhiker’s Guide to the Galaxy series (not pictured) – these books were consistently entertaining, surreal and light; most were less than 200 pages.  The pace slows down around book 3 (Life, the Universe and Everything), but delightful nonetheless.  I cannot believe I just discovered them in my mid-30′s!

  Believe it or not, there are a few books I did not get a chance to read.  I guess these will have to wait until after vacation.

  • Leading Out Loud – about finding your authentic voice in business.  I bought this to get some ideas about leadership and self-organizing teams.
  • Hope is Not a Strategy – I need to understand the sales process better and improve my ability to sell.  This looked interesting.

• Best Links of the Week – New Year Edition

  Date: 2010.01.05 | Category: Agile, Links of the Week, Scrum, Team, Testing, Tools, Transitions | Response: 0

  New Year links, a little late, but ready for your review.

  1. Defense Procurement Goes Agile – a summary from the Agile Process Leadership Network’s (APLN) October 2009  meeting describing how the DoD is moving away from waterfall to an iterative, incremental processes.
  2. Mixing it up with Agile & PMI – Orange County PM, Donna Reed, makes the claim that to be a successful Agile PM one needs to “move away from ACTIVITY-BASED project management toward VALUE-BASED project management.”
  3. Starting Scrum: What Would be the Logical Position of a Classic PM – SM or PO? – a Google groups discussion posed by a member with some excellent commentary.
  4. Synchronize Rather than Overlap Sprints - Mike Cohn explains why aligning Sprint end dates within one or two days of each other is a much better way to coordinate multiple Scrum teams.
  5. Agile Antipattern: Changing the Definition of Done – Bob Hartman discusses how the pressure to meet deadlines is simply “deficit spending” on your project with a bill that will get paid off sooner than you think.
  6. Welfare CSM Day 3: Experimental Mobiles & Rainforest Birds – interesting experience report about a different type of Certified ScrumMaster trainer; be sure to read the comments for additional insights and reflections by the other participants.
  7. UI Test Automation Tools are Snake Oil – an opinionated piece from Michael Feathers on the value of that expensive UI test tool gathering dust in your organization.

• Shaking Up Those Old Bones

  Date: 2009.02.18 | Category: Extreme Programming, Scrum, Tools | Response: 0

  Jeff Patton has a good blog entry on why he is creating user story maps to maintain the Big Vision.  At the last conference in Boston, I attended his tutorial on user story maps.  Organizing the Product Backlog into a backbone of critical features, a walking skeleton of a barely releasable product and a series of releases is definitely the way to go when dealing with a large collection of user stories.  The best thing I like about the map idea is that it is visual.

• Picking The Right Tool

  Date: 2008.11.21 | Category: Agile, Coaching, Collaboration, Tools | Response: 0

  Last week, I ran a “lessons learned” exercise using the Wall of Wonder.  There were some issues around trust and safety with this group and I did not think the venue of “lessons learned” was the right forum to confront these issues.  So, when one of the participants piped in with a suggestion to do the exercise anonymously, I figured it was worth a try.

  First off, let me say there is a time and a place for anonymous feedback, especially when you think the results will be skewed one way or another on how one or two key actors will respond.  In this case, it probably would have been a good idea to do anonymous feedback, just not with the tool I selected.  The tool I selected relied on people owning their comments by reading them out loud and then answering questions posed by the group in order to provide clarification or further refinement.  Wall of Wonder is designed to generate a free flow group discussion and analysis of ideas in rapid succession.

  By running the exercise anonymously, what I ended up with were a bunch of post-it notes gathered from everyone, reading them out loud and asking people if they wanted to comment on what they thought the author intended.  It had a less than satisfactory result; people were trying to guess at the author’s intent and not revealing their own thoughts and feelings.  Well…that is not exactly true, it was just very indirect.

  So, next time you think you might want to gather anonymous data, don’t use a group exercise like Wall of Wonder.  Try things like secret balloting\anonymous dot voting on pre-selected topics or even a Triple Nickels exercise.  Just select the right tool for the job at hand.

• Wall of Wonder

  Date: 2008.11.06 | Category: Agile, Coaching, Collaboration, Communication, Conferences, Tools | Response: 0

  At the SD Best Practices 2008 conference, I attended a tutorial by Ellen Gottendiener where she showed a storyboarding technique she calls the “Wall of Wonder” – it is a way to capture modern day “cave art“ifacts of our discussion.  This facilitation technique is a combination of individual work followed by sharing with the big group.  This technique allows big groups to tackle hard problems while respecting each individual’s thinking style and encourages collaboration.

  It is well-known (by people who facilitate a lot) that when you work in large groups that the extraverts are often the loudest and first to speak in group exercises.  Often times it is their ideas that permeate discussions and drive solutions.  However, many times the introverts atre the often the one to have the really profound and insightful comments that move the discussion into a new, exciting and interesting directions.  How do we find a tool that can challenge both the extraverts and introverts?  Let me show you how in the example below.

  Here is how the “Wall of Wonder” works; I will be using an example of a software team trying to decide what is in-and-out of scope for the next release.

  1. Gather the group in a large space where there is plenty of room to move around and there a good-sized wall to work on.  Have people arrange\group themselves any way they see fit.  Be sure each person has a marker and plenty of post-it notes\index cards to write on – everyone should have the same color ink and paper in order to foster annoyminity.   Use this opportunity to instruct the participants what and how you want them to write on the post-it notes\index cards – “write big enough to be seen across the room”, “give the headlines”, etc.
  2. Start with an image related to the problem the big group is trying to solve.  Remember, in order to think well as a group, we need to think well alone first – we want each person to think silently about the image that is coming up.  “Imagine you are at a party with our customers after this next release and one of our customers is shaking your hand about what an awesome release we just delivered.  What are they talking about that has them so excited?”
  3. Now give the group the focus question, the question that has brought this group together.  Instruct the participants that once the question is read they are to begin writing ideas on the post-it notes\index cards silently.  “Write down all the features that need to be in the next release.”
  4. After a timeboxed period of time has passed, ask each person to read one example of what they wrote.  When they are complete, ask them to post their item on the wall.  This technique helps focus participation and injects energy into the exercise through movement.  Anyone may ask for clarification.
  5. After five or so items have been placed on the wall, begin to ask the participants if they can sub-group the items into categories.  It is important to stay nuetral during the “Wall of Wonder”, so do not force the issue, eventually the items will coallesce into groupings.
  6. Continue until all non-unique items have been read and placed on the wall by the participants.
  7. If there are no groupings, now ask the participants on how to group the items on the wall.  Once the grouping is finsihed, ask the participants “Is this list complete?”.  If not, return to step #4 and repeat.

  Hopefully you can see how this tool works and give it a try next time you need to engage a big group in some creative problem solving.

• Great Tool For Training

  Date: 2008.09.18 | Category: Presentations, Tools | Response: 0

  A coworker of mine shared with me a great tool to help people know when it is time to come back from breaks during a training session - ZoomIt.  It is designed to allow you to zoom in on parts of your screen during a presentation and annotate the screen, but I find the reverse timer the best aspect of this tool.

   

  Say you are doing a training and want to have a two minute break.  Instead of trying to synch up everyone’s watches, just use this simple tool and people can visually see how much time they have left until break is over.  I was a bit skeptical that this tool was valauble, but during a recent training engagement, I noticed I had lost a lot of time in my class waiting for people to come back from breaks.  With the addition of this simple, unobstrusive tool people came back on time from breaks.

  ZoomIt is a must have for anyone who does a lot of trainings!

• Task Board Example

  Date: 2008.05.29 | Category: Agile, Scrum, Team, Tools | Response: 0

  Just wanted to post some pictures (sorry, they didn’t make the move – 01/31/2009 CEN) of the Team’s task board as yet another example for people who are curious about how this looks and feels. It is a very, low tech Team tool for talking about the work they are doing. We have three states for work: Not Started, In Process and Done.

  Each task is on a purple post-it note, has the person’s initials so we know who the owner is and has a size: S (0.5 days), M (1 day), L (2 days). The sizing idea came from the Team because there was resistance to estimating tasks in hours. So, now we estimate in task points and that information feeds the Burndown chart which  you see in that section. We also have a section for Obstacles, which go on their own post-it notes and a section for items that get Deferred, or dropped, from the Sprint.  It is all very elegant and easy to use.

  I am really pleased with this experiment I am running for this Sprint. One of the Team members said (without prompting), “I really like the task board. It makes everything visible and real.” You simply cannot pay people to say that!

• Management Tools vs. Team Tools

  Date: 2008.05.02 | Category: Agile, Extreme Programming, Rugby, Tools | Response: 0

  Just this week I participated in a WebExchange of yet another “enterprise Scum tool” with all the cool database, web access and reporting features you could dream of. Apart from some serious misunderstandings of just what Scrum is and how it can be made scalable, the tool was OK. It had some nice features, did some interesting things with traceability (oddly enough ignored tests), but it was not a tool I would recommend for any Scrum team.

  Over the years I have worked with teams, I have tended to avoid these electronic tools since they do not support the dynamic I am trying to foster when I work with people. I want people to talk face-to-face with each other and I want them defer complexity and detail until the last responsible moment, i.e. the Lean concept “decide as late as possible”. I want to encourage the growth and development of collaborative, cross-functional, self-organizing teams. IMO, these tools hinder the creation of that dynamic more than help. [Please note, I am ONLY referring to Teams and Product Owners that are co-located in the same work location and same time zone. I am not so arrogant to say electronic tools are not applicable for geographically distributed teams across multiple time zones. Distributed teams need different tools.] For the longest time, I could not articulate why, well now I know.

  These electronic tools are management tools for reporting up, they are not tools the team needs to create a collaborative, cross-functional, self-organizing team. There is no reason why a co-located Team of 8 to 10 people should be using something other than task board and Excel files to track their own progress, especially when they are starting out. The unfamiliarity of self-organization and collaboration requires simple of the tools that encourage communication. There is only so much you can write on a stickie note or in a field in Excel. To be successful, you have to get out of your seat and talk to someone.

  With so many of these electronic tools, it is so tempting (and so easy) to fall back on “bad” habits of command-and-control. These enterprise tools with their workflows, forms to fill out, work groups, web services and clean looking graphs we can email with a click of a button, encourage us forget that we are trying to become more collaborative, cross-function and self-organizing. We sometimes get so wrapped up in giving the tool the data it wants and follow the process IT lays out for us, we forget the reasons why we wanted to be more Agile. IMO, the only things these tools buy us is the ability to cleanly report up to management. So why does the Team allow a management tool to govern their own Team interactions?

  Before you shut off your brain and dismiss my criticism of these tools as “just another Agile zealot”, I want to be very clear I believe Teams MUST be visible and accountable to management. Teams MUST report their status to management with the metrics they expect in ways they can understand. Not to do this is not only is this disrespectful, but the Team is in for a surprise when management kills their Agile initiative because they are viewed as “rogue”. Providing visibility and accountability is where I can see how these enterprise tools can be valuable to the enterprise, but filling the tool with the information it demands is not the responsibility of the Team. In my ideal world, the Team should not even know the tool exists – you basically only need as many licenses as you have Teams and Product Owners. It is the ScrumMaster’s (or the XP Coach’s) responsibility to translate the Team’s metrics into the tools format since their role is to provide the “management deflection shield”. No one else should be entering information into the tool but the ScrumMasters (or Coaches) and the Product Owners (or Customers).