Scrumspect What You Expect

Share

An old adage meets agile and another reason I love scrums!

Office workers in meeting

One of the first management adages we all learn is ‘inspect what you expect.’  It certainly has served well as a reminder that the way to ensure some project, delivery, etc. is on time and budget is to keep on top of its progress regularly. That way, any blocking factors can be detected early while corrective action can be taken to get things back on track.

Unfortunately, putting this adage in practice can often be difficult, as we all have way to many tasks to accomplish in any given day and it is very easy to take things for granted. I learned this the hard way in my first team leader role where I managed a high achieving group of programmers. Mostly, managing this team consisted of define roles, goals, then walking off and letting them work the plan. That worked well until one day a new engineer was transferred into my group and of course I utilized the same management ‘style’ with him. Ernst and I spent the morning white boarding the project, his role, and co-defining the steps he would take over the week to create a module for the system we were working on. Ernst’s first task was to print out the existing code base to study it, then he would be off and coding.

My ‘inspecting’ what I expected him to accomplish would consist of hit and run ‘how is it going?’ inquiries, and the response I would always get was ‘great.’ At the end of the week I called Ernst over to my cubicle to discuss how he implemented his module and to define the next week’s work sprint to integrate the module with our project code base. I found he was nowhere near completion and worked back to find what he had accomplished, which amounted to no code being written. In exasperation I finally asked, what DID you spend all your time on to which he replied “hooking up my printer.”

Now granted, back then given the state of technology it was sometimes difficult to connect a new printer to a mini or mainframe, but this should have taken a half day at most. When I started to inspect where he had problems, I found that Ernst first had to find an unused printer, then an expensive cable, and later he got stuck on finding then installing the correct driver for the version of the OS we were using for the printer. Any one of these problems could have been short circuited if he had he asked any of our team for assistance, since many of us had been through this before.

Too bad I had not been exposed to agile development methodologies back then as Ernst’s lack of progress due to blocking factors would have been exposed the very next morning’s team scrum.  At that point, one or more of the team members could have volunteered or been assigned to assist him, and he would be unblocked and (hopefully :^) more fully productive.

Hence, this is one of the reason’s I love scrums and agile methodologies in general. Although this was an engineering related example, the same scenario could have equally applied in marketing, sales, operations or any other function in our organizations.  So don’t just ‘inspect what you expect,’ ‘SCRUMSPECT what you expect!’

Leave a Reply