Humor – A Typical Project Launch Meeting

One of the things that I love is how many great videos there are that show the ridiculousness of a lot of corporate behaviour.  This video is a hilarious (and painful) look at one aspect: the way we treat our experts.

Of course, I don’t mean to say that we should never be sceptical.  Rather, sometimes we just have acknowledge reality: there is no magic to make a red line with a green marker.  The role of the expert is to clarify reality to others through their knowledge and experience.

When I am doing CSM and CSPO training, I often am faced with people who want to know how to make high-performance teams with distributed team members.  They are often looking for some sort of magical solution.  This is an example of not being willing to face the reality that distance makes communication slower, less effective, and less likely to happen at all.

I’m sure all of you have interesting experiences of being the expert in something and your audience pushing you to find the magical solution… share your stories in the comments please!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Minor Update: Seven Essential Teamwork Skills

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Summer of Scrum Toronto 2014 Pre-Registration

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Sometimes I Just Need to be Pedantic

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.

Finally:

Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Sprint Review Timing – Article by Mike Caspar

Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it.  From the article:

If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.

Please, for the sake of your team(s)….

When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!

Stakeholders are people too. They don’t want to let the team down either.

(Emphasis added.)

Mike has great experience working with Scrum teams and I hope you read through his other articles as well.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Scrum Team Assessment updates

The Scrum Team Assessment has been used by 36 teams so far including 15 teams in Asia.  The organizations that have used it are involved in many industries including high tech, mining, media, human resources, engineering, telecomm, and financial services.  We launched the official “Professional” version in January and have great success with teams using it to improve their Scrum and Agile practices.

Two interesting results to come out of the Scrum Team Assessment so far:

  • Most Scrum teams are scoring “B’s” and “A’s” on the Scrum rules
  • Organizations are doing a poor job of supporting their Scrum teams to encourage high-performance

Of course, this is still a pretty small sample size.  I’m looking forward to that growing significantly over the next few months.

The latest update of the Scrum Team Assessment includes the following changes:

  • More complete statistical data about how your team compares to other teams
  • Updated expert system rules (these will continue to evolve!)
  • New and updated recommendations
  • Numerous report formatting improvements for better clarity
  • Several minor bug-fixes

This is a minor revision to our “Professional” level tool.  We are still planning a big announcement for new “Basic” and “Advanced” pricing levels soon!  Stay tuned…

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Nice Summary of Personal Kanban

Wired magazine has a nice little summary of personal kanban.  Check it out!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Great little presentation on Retrospectives… and a bonus download!

If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives.  I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago.  Very helpful with some practical information, some great links… I strongly recommend checking it out.  My only concern is that they limit the scope of retrospectives too much.  I have a list of topics that I think can and should be considered in a retrospective:

  • Technology / tools
  • Work space / physical environment
  • Corporate culture
  • Corporate standards and policies
  • Teamwork
  • Work planning and execution
  • Skill sets
  • Interpersonal dynamics
  • External groups
  • Personal circumstances and needs
  • The process you are using

 

This list comes from a presentation I used to include as part of my Certified ScrumMaster course.  (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.)  Here is a PDF version of the Retrospectives Module.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Back to the Basics: Coding and TDD

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team :-) ).  I’ve been doing all the work on it personally and it has been great fun.  The best part of it has been that I’m back into coding.  And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices.  But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end.  My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing.  And… nothing yet for the Python back-end.  This is still a sore point with me.  Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform.  Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code.  Which is funny, because there are tons of open-source extensions for OpenERP written.  Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing.  Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system.  How did the bug happen?

Because I didn’t do _enough_ TDD.  I skimped.  I took shortcuts.  I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”?  Fortunately, the answer is simple to find… but solving it is not as easy as I would like.  I didn’t follow my own advice because I was learning about too many things at the same time.  Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

  1. PHP and PHPUnit
  2. Python
  3. OpenERP (APIs for persistence and business logic)
  4. RML (a report generation language)
  5. Amazon EC2, RDS and Route 53
  6. Some Ubuntu sys admin stuff
  7. VMWare Fusion and using VMs to create a dev environment
  8. Postgresql database migration
  9. Oh, and refreshing on Selenium

Like I said, FUN!  But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish.  As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments.  Now I have to clean up.  Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit).  And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests.  Ideally, I might even consider throwing some code away and starting from scratch.  One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this?  Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach.  It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Agile Estimation with the Bucket System

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Planning Game for Agile Estimation

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Start of a True Team

I wrote this article for our Real Agility Newsletter, but I wanted to share it here too, just in case some of you don’t get it.  I think this is important to share because it gets to some of the deep values of Agile and good teamwork.

- – - – - – - -

The team really is important. Last month I wrote about love. This month, I’ll write about commitment. Our team has gone through some extreme tests this last month. Commitment kept us together.

Our business has been through crisis before. In the second half of 2005, my own financial mis-management led to near-bankruptcy for the business and for myself personally. My dear long-suffering wife and business partner, Melanie, kept things under control as we recovered. In late 2009 the Great Recession hit us hard and we had to cut our staff back to just Paul and myself by laying off three talented friends and cutting work to a loyal subcontractor. That was incredibly painful for everyone involved. A similar crisis occurred again in late 2011, although it wasn’t as severe. In September last year, our projections were showing a looming crisis… but we narrowly averted any layoffs when a smaller consulting deal closed and one person was let go for unrelated reasons. We still needed more work, and in late fall we were expecting to close three important deals.

In January we knew we were in trouble. Business was not booming. In fact, those three important deals had fallen through with nothing obvious on the horizon to replace them. Our office management was in a shambles with two recent changes in staff and very little continuity. Our accounts receivable had several items that were waaaay overdue. We were starting to dig deep into our operating credit with no obvious way to climb back out. The partners, Paul, Travis, Melanie and I started to talk about serious stuff: deep layoffs. We were worried we may even have to cut all the way back to just me doing work (mostly CSM classes) – a staff level we haven’t seen since 2007!

Two weeks ago, the four partners had an emergency weekend meeting after our early February attempts to build sufficient immediate cash flow failed. We consulted for over four hours around a single question: what should we do? Our projections were showing us running out of credit in just four weeks, our business development pipeline was almost empty and the few things in it were clearly long-shot deals, at least in the timeframe we needed. It seemed almost impossible to avoid deep layoffs. Our love for each other seemed almost irrelevant to the crisis, despite the depth of our feeling.  The consultation was difficult and filled with despair.

My memory for exact words is poor. I remember concepts, relationships and feelings. During that weekend consultation, one thing really stood out: we started to talk about commitment. We talked about what it would mean to be committed to each other and to the business vision of transforming people, process and culture. Most powerfully, we talked about the commitment of our newest employee, Nima, who seemed determined to go to the ends of the earth, to the very last moment to help us all succeed. As we talked about commitment, we came to our most powerful decision: sink or swim, we are all in this together to the end.

After that critical point in our discussion, we set some goals, determined some important activities, and decided to go literally day-to-day in deciding if it was time to wrap up the business. And, strangely enough (I say ironically), we decided we needed to shorten our planning cycle from a month to two weeks, increase the discipline of our team’s interactions to bi-daily check-ins, create a detailed set of dynamic plans for the two weeks, and have a review meeting at the end of the two weeks. Sounds a bit like an Agile team, doesn’t it?

What happened? Well, we’re still around. We’ve closed enough business that our projections are now showing us staying in a steady state financially for the next three months. That’s a dramatic turnaround from just two weeks prior. We aren’t going to run out of credit. In fact, we now have enough prospects that we expect to be extremely busy in just a couple more weeks. Our end-of-cycle review, which happened on Friday, was still difficult. There is still great uncertainty about many things. But the one thing that is crystal clear, strong as steel, and deep as the deepest ocean is our commitment to each other to succeed together. We are a true team.

- – - – - – - -

If you have similar stories to tell, I would love to hear them!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

A Conference Call in Real Life (youtube)

I’ve started to show this video in my public CSM classes (see sidebar for scheduled courses) as part of the discussion about why co-location for Agile teams is so important.  The video is a humorous look at what conference calls are like.  Probably the most notable part of it is the fact that on a conference call you can’t see people’s body language and facial language which are important cues for efficient communication:

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Two reviews of SAFe (Scaled Agile Framework)

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail