Archive for the ‘Coaching’ Category

• Best Links of the Week – June 18th 2010

  Date: 2010.06.18 | Category: Agile, Coaching, Daily Scrum, Links of the Week, Scrum, ScrumMaster, Transitions | Response: 0

  Some new links to share and idea to learn.

  1. What Does an Agile Coach Do? – Considering an Agile\Scrum Pilot?  Don Gray talks about what you might expect from your new Agile Coach.
  2. Should the ScrumMaster Also Be a Member of the Team? – Clinton Keith provides his perspective to a common question\scenario many Scrum teams face when starting out (with good dialogue in the comments).
  3. Pathologies of the Daily Scrum – Experience report from a session at Agile Ottawa identifying ways daily standup meetings breakdown and some suggestions to improve your daily meetings.
  4. Institutionalized Agility – Rob Myers discusses some of the common obstacles when your organization decides to “go Agile”.
  5. Balancing Agile – Special guest poster, Alan Shalloway, talks about the role of management in an Agile process.
  6. Do You Need Iteration Zero: A Case Study – Jim Shore examines a common practice when starting up new Agile teams and critically evaluates how necessary it is today.
  7. Why Your Agile Project Cannot Be a Success – List of 32 items that increase the risk of failure for your Agile project and point to signs that you do not understand Agile.
  8. The Dangers of Agile Development – Jeff Anderson takes a humorous look at some of the real risks posed by Agile projects.
  9. Making Change Stick – Steve Denning looks at the ten practices\principles to understand when leading a change effort.
  10. The Myth of Utilization – If your computer slows down at 100% utilization, then why do we ask our team members to do the same?

• Best Links of the Week – Mar 27th 2010

  Date: 2010.04.27 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Planning, PMI, Quality, Refactoring, Testing | Response: 1

  More good links to share with others.

  1. Ouija Board Estimation\Seance Sizing – a new method for estimation that relies on team, not the undead.
  2. Is the Agile Community Being Unreasonable? – InfoQ takes a look at the friction between the PMBOK and Agile principles.
  3. Toyotas’ Journey from Waterfall to Lean Software Development – Henrick Kniberg takes a visit to Toyota and peaks under the hood to see how a Lean company develops software.  What he finds will surprise you!
  4. Defining the Last Responsible Moment - Karl Scotland puts some meat on this fuzzy Lean concept by looking at the cost vs benefit of delay.
  5. Managing vs. Coaching vs. Mentoring - Jurgen Appelo makes the distinction between these three concepts.
  6. The Problems With Acceptance Testing – thoughtful entry by Jim Shore reevaluating the importance of automated acceptance testing on Agile projects.
  7. Alternatives to Acceptance Testing – more from Jim Shore on what can be used in place of automated acceptance testing.
  8. More on Automated Acceptance Testing - George Dinwiddie adds his perspective to the topic of automated acceptance testing.
  9. The Path to Frequent Deployments – a report from Kent Beck, author of Extreme Programming, on how to  increase development speed by moving from annual to quarterly to monthly to weekly and finally to daily deployments.
  10. How to Be a Great Tech Leader – Richard Kasperowski talks about the technical elements needed to succeed when running an Agile project.

• Best Links of the Week – Mar 13th 2010

  Date: 2010.04.13 | Category: Agile, Coaching, Communication, Lean, PMI, Scrum, Transitions | Response: 1

  Sorry for the long delay – I’ve been swamped.  Now back to the great links.

  1. Large-Scale Agile - Jim Shore talks about the seven factors to consider when trying to make Agile large.
  2. What is the One Thing You Can Do to be More Agile? – various vendors at the Agile 2009 conference provide their answer to this question during this five-minute video.
  3. Intro to Scrum Video – Bob Hartman and Arif Gangji provide an eight-minute video overview of Scrum.
  4. In Praise of Middle Management – this article explains how leadership from middle managers is essential for driving change brought on by Scrum.
  5. The Role of Test Manager in an Agile Organization – Johanna Rothman talks about how Agile transforms the role of Test Manager from one that schedules resources to that of coaching, removing obstacles and building organizational capacity.
  6. 78 Things I have Learned in 6 Years of Agile Coaching – Jean Tabaka shares her accumulated wisdom about Agile and change.
  7. Top 10 Questions When Using Agile for Hardware Projects – In this interview, Larry Maccherone discusses how Agile is applied on software-hardware projects.
  8. You’re Just Going to Fail, So Don’t Bother – Scott Downey, Scrum Coach at myspace, discusses why Scrum is so difficult for many organizations and identifies the six hard truths you eventually confront when using Scrum.
  9. Agile Roots – A Personal History – Jim Highsmith, a signatory of the Agile Manifesto, discusses the origins of the Agile movement.
  10. The Wrong Lessons from Toyota’s Recalls – and the Truth - Jeffery Liker gives his take on the Toyota recalls and what they say about Toyota’s highly touted manufacturing process.

• Why do you care so much (about Scrum)?

  Date: 2010.02.22 | Category: Agile, Coaching, Scrum | Response: 1

  I am really passionate about Scrum – I see the Scrum framework as a powerful means for organizational transformation and reconnecting alienated people to their work and their peers.  IMO, Scrum works because of its simplicity of roles and rituals and is transformative because it engages the imagination and creativity of the people who participate.  Scrum is about self-organization, communication, visibility, accountability and what I call the Sprit of Scrum – the sense of camaraderie, common purpose and commitment – drives our actions on Teams.  Where some people see weakness or omission in the framework, I see strength because Scrum relies on individuals and interactions to fill in the gaps, not process and tools that may (or may not) come with the framework.

  However, over the past couple of weeks, there has been a fair amount of criticism directed at Scrum (some deserved and others not so much).  There are a few specific examples that I could link to and write strongly-worded, emotional counter arguments, but that just continues the invective.  What irks me so much about many  Scrum critics is they want to take advantage of the large mindshare of Scrum to gain wider distribution of their ideas.

  Some critics just go over-and-over-and-over-and-over again about how whatever it is they are doing is so superior to Scrum, how Scrum is so bad and how they are so right.    Really?  Who gave these critics the monopoly on right and wrong, better or worse?  If you have a different set of principles, that lead to different set of beliefs and actions, it does not mean the other people are wrong, stupid or even misguided.  Having separate ideas and principles exist side-by-side is called pluralism and is generally considered a strength.

  So I ask the question of these Scrum, “Why do you even care?”  If Scrum is something you do not practice any more, find value from or you have tool that better suits you and your principles, why do you have to come and leave a big crap in my pool?  Why do you have to make things more difficult for the people who really care about this thing called Scrum, the people who really do care and are invested in the outcome?  Why don’t you just go to your side of the room and do your thing and leave us alone and let us do our thing?  It is not that I don’t like your ideas, but I’m focused on my goal and your not helping me, so I would prefer you just stay over there and do your thing.

• Speaking @ Fullerton Code Camp – Jan 30 & 31

  Date: 2010.01.04 | Category: Agile, Coaching, Conferences, Extreme Programming, Planning, Presentations, Scrum | Response: 0

  If you are looking to see me speak in person, be sure to come to the Fullerton Code Camp.  I will have three presentations on Agile.

  1. Experiencing Agile Through Games: Are you bored at work? Is your Agile team devoid of fun? It could be that you are following the mechanics of your process, but missed out on the critical insight, the “ah-ha” moment, where everything clicked and it all fit into place. Come to this session hosted by Carlton Nettleton and he will demonstrate as many Agile principles and practices he can in 75 minutes through a variety of short simulations and games. Walk away energized and excited about working on an Agile team.
  2. Agile Planning Workshop: Every time I speak about Agile software development, I often hear this statement, “Agile teams never know when they are going to be done.”  With the teams I coach, this is not the case.  Come to this workshop and we will walk through the steps I use when planning an Agile team.  Learn the practical tools and techniques for estimating, planning, reporting progress and keeping the stakeholders in the loop. This session will focus more on principles and tools used in Agile planning.
  3. Debunking Myths About Agile Software Development: With so many myths surrounding Scrum, Extreme Programming, Lean and Agile software development these days how is someone supposed to succeed with these processes when there is so much half-truth and opinions masquerading as practice and fact? In this workshop, we will look at the myths surrounding planning, deadlines, documentation, architecture & design, requirements, testing, pair programming and other common misconceptions about Agile teams. By the end of this session, Carlton Nettleton will provide real facts about Agile software development, refuting many of these myths once-and-for-all.

• Best Links of the Week – Christmas 2009

  Date: 2009.12.25 | Category: Agile, Coaching, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  A bag full of Christmas links.

  1. Grooming the Product Backlog – Laura Brandenburg talks about the role of requirements management through the Scrum Product Backlog.
  2. Make the Product Backlog DEEP – more on good practices for maintaining the Product Backlog from Mike Cohn.
  3. Why is Agile so Hard to Sell? – describes some of the issues growing Agile in the enterprise.
  4. Is Scrum for Lazy Project Teams? – looks at the misconception that Scrum does not challenge teams to work their hardest.
  5. When the Scrummaster Becomes the Impediment – different perspectives on how to solve the problem when the Scrummaster becomes a bottleneck.
  6. A Day in the Life of a Scrum Team – a short 6-minute YouTube video of a Scrum Team in their native environment.
  7. Agile Business Analysts – what is the role of the business analyst on an Agile team?
  8. Building trust – five concrete things you can do to build trust on your teams.
  9. Something in Agile Needs Fixing – Rob Bowley summarizes the Open Space discussion on the topic of “Agile isn’t solving our customers problems because they aren’t here.”

• Best Links of the Week – Dec 18th 2009

  Date: 2009.12.18 | Category: Agile, Coaching, Communication, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  Here are links to the best of the blogs for the week of Dec 18th 2009.

  1. A ScrumMaster’s Checklist – a comprehensive checklist from Michael James offering four areas a ScrumMaster should pay attention when coaching: the Team, the Product Owner, the organization and the technical practices.
  2. Agile Leadership: Methodology Ain’t Enough – the Hacker Chick brings us a blog article about the management beliefs and behaviors which support the growth of Agile teams.
  3. When Should QA be Engaged in an Iteration? – Hiren Doshi PMP discusses the role of QA on a Scrum team and tackles the myth that QA folks “have nothing to do until the end of a Sprint”.
  4. Five Reasons to Hire a Coach for Agile Teams – Ester Derby talks about five pitfalls of DIY (Do-It-Yourself) Agile coaching.
  5. Scrum Doesn’t Do Anything – explanation of how Scrum only comes to life when people are added to the framework and the importance of the following the rules by Tobias Mayer.
  6. Practical Agility: On Estimation – Dave Rooney describes the Agile estimation lessons he learned while undergoing a recent move.
  7. Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise – Vijay Narayanan over at InfoQ discusses the importance of having an development environment which supports your Agile process.
  8. Flipping Out – short description of how Flickr uses Continuous Integration and a Single Code Base to add features to their application without branching.

  There was a lot of great stuff to read this week, unfortunately I can only go with eight or so entries.  Cya next week!!

• Importance of the Definition of Done

  Date: 2009.09.04 | Category: Agile, Coaching, Scrum, ScrumMaster, Team | Response: 0

  I was looking back at some old notes of mine from China and I came across a number of questions from the people I worked with about the Definition of Done.  The Definition of Done (DoD) is a very important concept in Scrum and not spending time to construct a DoD is a common mistake with new Scrum teams.

  In my opinion, the DoD provides visibility and alignment on just exactly what it takes to get a user story completed in an organization.  It could almost be seen as a unstructured value-stream map.  We write down the DoD to illuminate any hidden queues in the organization and to make visible the real effort it takes to complete a user story.  It is also there to protect the Team since it cannot be changed during a Sprint.  Nothing irritates me more as a Team member, or a ScrumMaster, to move the goalposts of a Sprint after it has begun, i.e. adding a new auditing requirement to the DoD.

  The DoD is NOT the same as the acceptance criteria for a user story.  The DoD is an engineering checklist for the cross-functional Team.  The acceptance criteria is the checklist Product Owner and stakeholders use to know if a user story is complete.  They assume all the items in the DoD are complete and if they are not (that is called Design Debt), the Team cannot demo the feature at Sprint Review.  You can think of the DoD as the pre-requisites that need to be finished before a story may be shown at Sprint Review.

  Finally, I have found it better for individual Teams to come up with their own DoD rather than be handed one from management.  When first working with a Team, it is normally better to document what the Team is doing and label that it’s DoD and add to it over time rather than forcing some onerous DoD created by some disconnected process people who don’t even do the work onto an uncertain Team.  Of course, there are some basic standards (code reviews, some form of pair programming, unit testing, etc., etc.) that must be in all DoD, but I find most Teams will include them on their own.

  So what to do when your company has 12 versions of the DoD floating around?  Well, that is why you have ScrumMasters.  It is their job to get the various Team DoD in alignment, not the process goons.  The process goons have good stuff to add to the DoD and Scrum is about collaboration, not forcing other people to do your will.  If the process groups want Teams to do extra work, their requests on the Team are made visible just like everyone other.

• Agile 2009: My Greatest Coaching Mistakes 2000-2009

  Date: 2009.08.25 | Category: Agile, Coaching, Communication, Conferences | Response: 0

  Stopped in today to J.B. Rainsberger’s interesting discussion about his big misses in the last nine or so years.  He used an interesting format of people sitting in a circle instead of sitting around conference room tables.  Here is a list of the interesting ideas I jotted down while listening to the conversation.

  • Practices like pair programming, timeboxes, iterations, user stories, release planning, etc. are neither good nor bad.  They are either appropriate for the environment or not.
  • One resistant person is more than enough to bring down an Agile team.  It is better to have people who have a similar style work together and form your Agile team around them.
  • If you are going to do something a stakeholder does not expect – like deliver early or spend time fixing broken tests – be sure to give them advance warning.  In low trust environments, this can be a good first step in building trust.
  • If the response of someone is not what you expected, you need to spend time understanding the significance of what you said and how it was interpreted by the listener.  Consider the worst possible interpretation of your actions to reduce the number of communication surprises.
  • Use smaller user stories when a Team is beginning with Agile to build a sense of accomplishment with the Team.  As they become more experienced and skilled, use bigger stories.
  • Training is about increasing your capability and improving your skills.  Coaching is about reducing interference and improving the signal-to-noise ratio.
  • Coaching is about giving people a new way of working together.  All the Agile tools and practices are worthless if people cannot talk with each other.

• Agile 2009: Distributed Agile Development

  Date: 2009.08.24 | Category: Agile, Coaching, Collaboration, Conferences, Team | Response: 0

  After searching and searching for this ballroom (this conference center is a bit of a maze), I finally found this session being held by some folks from Microsoft, Ade Miller.  They were talking mostly about their observations of working with teams in South America, but did talk about working with Teams in Asia.  This session was attractive to me because I was looking to see what other experiences people were having with distributed Teams and if my recent recommendations were on the right track.

  Here is a list of ideas I jotted down while listening:

  • Get good tooling to minimize the difference being in the Team Room and out of the Team Room.
  • Select tools that are adaptive to the Team’s processes and ways of working together.
  • Plan to travel; use the lower rate of the offsite people to offset the travel costs.
  • Always have one guy from overseas in the main office.
  • There will always be people difficult to synch up with due to time zone differences, so nominate a representative in the Team Room to advocate for them.
  • Avoid component-based architecture and thinking to prevent local optimizations.
  • Make sure every Team has a coach to remind them of the underlying principles and values of Agile.
  • Have a list of books that people should read when onboarding.

  As it turns out, I was mostly in the ballpark.