Agile PM/Development/QA

ScrumMaster and the daily Scrum

For daily Scrum to serve its purpose, the ScrumMaster must truly understand what their role in it is.  I've seen new ScrumMasters go through the motions of asking each team member the three standard questions without much understanding as to what to do with the answers.  The meeting turns into each person talking about what they did, what they will do, and once in a while reporting an obvious obstacle.  Team members end up seeing the daily Scrum as a waste of time.  But the worst part is that often the sprint falls short of expectations and it comes as a complete surprise to the ScrumMaster.

What's usually missing in those cases is the desire (or maybe ability) of the ScrumMaster to listen for the hidden cues in what the team members are reporting.  There are many reasons why this information is not freely offered up by the team members.  Some of them are:

• reluctance to admit mistakes

• desire to keep peace on the team and not create uncomfortable situations

• indifference as to the outcome of the project

• simply not seeing/understanding an obstacle or issue

Those cues should trigger some followup on the part of the ScrumMaster, unless other team members pick up on them.  What are some of those cues?

• Team member keeps reporting working on the same task day after day.  The fact that something is wrong should be easily picked up by ScrumMaster, but in reality it not always is.

• Team member's report is very vague and high level (ex. "working on reports" or "developing customer portal").  This information is completely useless - it provides no insight into what's actually happening on the project and whether things are moving along or are at a standstill.  One of the ways to address it is to break up the stories into more details and ensure that reports are tied directly to those stories.  Or the ScrumMaster has to dig deeper on those during the meeting.

• One team member briefly mentions that they are waiting on something from another team member (or an external entity) during their report, but don't report it as an obstacle.  That's a definite flag that the ScrumMaster should dig deeper to see if there is a hidden obstacle there.

The bottom line - ScrumMaster's job is not just to review/maintain a burndown chart and write progress reports for management.  Their role is to monitor team's progress throughout the sprint and intervene when they sense issues, not just when someone asks them to.  That takes desire to be proactive, skills, practice, and intuition.  But the payback is full understanding where the project is going at any point in time and ability to see failures before they fully realize, so something can be done to prevent disaster.

Posted on Jul 22, 2011 by Gene Mitelman

ScrumMaster's job

Scrum emphasizes that a ScrumMaster's job is very different from a traditional PM.  The intent is to empower the team to make its own decisions and commitments, leading to significantly better results.  Therefore, a ScrumMaster is not an instrument of command-and-control, but rather a supporter/facilitator, whose job is to guide the team and remove impediments.

This is a somewhat simplified view and from my perspective, shouldn't be taken in isolation, especially in environments new to Scrum.  There will be a fair amount resistance from the team, product owner, and other groups with whom the team interacts (such as database and infrastructure support, and other teams on related projects).  This resistance will rear its ugly head in different ways, varying from outright defiance to passive-aggressive sabotage.

If a ScrumMaster blindly follows the principle of being a facilitator, a power vacuum will form.  Since vacuum is not natural, it will be filled by those resisting change.  The result will likely be failure on the project, giving those same people who sabotaged it in the first place more ammunition in fighting change.

I argue that a ScrumMaster must follow the concept of "yin and yang", in that they must be soft in guiding and supporting the team on the project, but be brutal in enforcing the process and rooting out negativity (i.e. remove impediments within the team, not just the project).  It's somewhat paradoxical, but I believe that hard-line on enforcing the process ultimately leads to team empowerment.

Posted on Oct 14, 2010 by Gene Mitelman

Releasing early and often

Agile approaches, such as Scrum, call for fixed-length iterations.  These apply to actually building the software, not so much releasing it.  If you look at Kanban, iterations are completely gone, so there is no specific expectation as to how often the software gets released to users at all.

People who have been doing agile for some period of time, know that while the process does not explicitly tell us how often to release the software, it's always best to do so as often as possible.  Several reasons are often mentioned, such as getting user feedback from the field (helping to shape the software) and starting to derive value from investment (Lean is big on this).  Today, I want to mention another reason you want to release early and often.

Let's take a scenario from my recent experience.  We had to implement some major structural changes to a system that was written years ago and our team have been supporting for the last two years.  The changes took about two months to implement.  We managed to mostly keep other requests for changes from creeping in.  These changes were pretty big, so stakeholders were cautious of deploying them into production too soon.  As they were dragging their feet on allowing deployment into production, we started implementing newly requested features.  The further it went, the more features were added, causing even more apprehension on behalf of the stakeholders.  I knew it will eventually come to a head - and it did when two months later some of the newly added features were needed in production, but couldn't be deployed.  This finally forced the stakeholders to commit to doing thorough UAT and scheduling deployment in a timely fashion.  In the meantime, we've had some tension between users and the team because of not being able to get needed features out.  And needless to say, there's been a fair amount of stress due to big-bang deployment instead of steady release schedule.

What I'm talking about here is FEAR.  Once changes are perceived as being pretty big, everyone (including the team and the stakeholders) starts getting nervous about releasing them.  Common response to this fear is to delay deployment.  However, that is completely counter-productive.  The further you go, the bigger the changes, the greater the fear.  You don't want to get to the point where it paralyses the team into inaction.  The solution is to deploy as early as you can, without compounding the fear of the consequences.  I've heard the saying "if you're gonna eat a frog, you might as well eat it right away, because it ain't getting any prettier".  I full-heartedly agree with this advice.

Posted on Sep 03, 2010 by Gene Mitelman

On optimizing the whole

Recently, I worked on a project that required us to access vendor's software via API.  Before starting the project we agreed on two interface points with the vendor - one at the beginning of the workflow on the front-end and one towards the end on the server.

While waiting for the vendor to get their pieces done, we started implementing the UI that would allow us to demonstrate the flow to the client and start getting some feedback.  I was looking forward to the completion of the first interface piece by the vendor, so we can finish implementing the start of the workflow.

Two weeks later, the vendor completed the first interface point.  To my dismay, it turned out that they implemented the second part first.  So we had to continue waiting for the other piece of functionality, before proceeding with our development efforts.

Unfortunately, I didn't specify that we wanted the two pieces of functionality done in a specific order, since we needed them both to complete the project.  I just assumed that they would be done in the order of the workflow, so I had noone to blame, but myself.

I'm sure it made sense to the vendor to do things in this order.  Of course, from the perspective of the overall project, it would be much more efficient for them to deliver this functionality in the order that would support our efforts.  We could deliver the project sooner and more efficiently.  That's what the Lean approach concentrates on.

Of course, various agile approaches already give you a tool to help you do that - communication.  When you're responsible for delivering functionality (even in the same iteration or sprint) - talk to the people who need it to see if having it delivered in a certain order will optimize overall project delivery.

Posted on Aug 23, 2010 by Gene Mitelman

Agile is not for everyone Part I

Agile is definitely a great approach to make good teams (and developers) better at what they do.  However, as most Agile project managers and coaches discover fairly early on, it only works when people are willing to embrace it.  Here's a recollection of my experience on a project where it didn't work out so well for a developer (but there is a silver lining).

It was the first Scrum project for this company, so we started very small.  Our team consisted of 2 developers, a tester, and a ScrumMaster (myself).  First sprint was a little bumpy, as team members were trying to figure out how to do things the agile way.  However, next couple of sprints went pretty smoothly.  To increase throughput, management decided to add another developer to the team.  Let's call him John.  He's been working in another group at the company and came highly recommended.

Everyone, including myself were very patient with John during the first few weeks, expecting that it would take him some time to catch on to the sashimi principle.  However, as time went on, John has not completed a single task.  During daily scrum, there was always some caveat and long explanation as to why things are not getting done and a promise that it will be completed that day.  As the pressure was building, John started saying that tasks were completed, but I had my doubts.  Needless to say, a couple of days later, I started seeing the tester fail everything that John had implemented.  I had several conversations with John, explaining how important it is to finish one thing before moving to the next, but it wasn't working out.  One of the other developers started volunteering to clean up John's mess on a daily basis.  I was hoping that would cause him to step up to the plate, but I was wrong.  As we were approaching the end of the sprint, things were slipping, team morale started spiraling downward, and quality of deliverables had definitely dropped.

I felt that John has been given plenty of support from everyone to get into the process, but had little hope for improvement at this point.  So as unpleasant as it was, I had to ask my manager to move John off the team.  Of course, the question came up as to how the team was going to handle the workload with one less person, but at this point my feeling was that we'd produce more results without John than with him.
Ironically enough, when John was told that he'll be removed from the team, he was greatly relieved.  Apparently he found it to be extremely stressful to have to account to the team on a daily basis.  He felt much better being left alone for months at a time.

So agile didn't work very well for this individual.  Chances are one day he'll have no choice but to adapt.  However, as I said at the beginning, there is a silver lining here.  Had we been using a more traditional approach, John would be able to hide his inability to deliver for many months, ultimately hurting the project.  Agile brought the problem to the surface very early on, allowing me to deal with it before it got out of hand.  So I feel the process worked very well, even though the result was somewhat bittersweet.

Posted on Aug 09, 2010 by Elena Mitelman

A short story on value of iterations

I've recently experienced first hand what happens when development moves from iterations into big-bang release.

We've been working with a large client with domestic and international operations for over 8 years now.  We initially built a small system to support their sales teams across the country.  Over the years, we've incrementally enhanced the system to cover many aspects of the business.  This system has been called one of the most successful software implementations within the company by its president.  I largely credit small iterations with a lot of user feedback for the successful growth of the system.  We've built a lot of trust at all levels of the company throughout the process.

Recently, we were asked to add a new module to the system.  It was going to take about 4 months to complete the work, so we proposed a phased approach of 4 iterations, just like we've done in the past.  This time however, one of the top managers absolutely insisted on releasing the module as one piece once it's completed.  We fought tooth and nail to build in iterations, but to no avail.  Wanting to keep the client, we had not choice but to agree against our better judgment.

As expected, about 3 weeks into the process the client started getting impatient about progress.  During a review meeting, we again tried to offer a solution by releasing the first usable portion within a week or so, and then proceeding in small increments of usable functionality.  The client continued to insist on waiting until everything is completed.  We started to smell trouble, but what could we do?  We've done everything possible to warn them of impending trouble - and the solution was so obvious (what made it even worse, is that they've seen it work for many years now).

Needless to say, about 3 weeks later, the client wanted to know what's happening again.  This time they got frustrated and decided to ditch all the work that was done to date, opting to build a free-standing module with a lot less functionality and no integration with our system, but a promise of potentially faster release date.  We tried to convince them that what we've built to date was already doing more than the new module would deliver, but it was too late - the relationship was ruined.  In the end, we lost business, the client wasted their money and was going to get less functionality.  All because they flatly refused to to what has been working well for a long time - release functionality in small increments.

Clearly, the problem was that trust was lost.  It's easy to trust a vendor when you continue to see results and feel like your money is going to good use.  When you continue to pay for something you desperately need, yet are not able to use it, you start losing that trust.

The lesson is simple - in addition to other benefits, such as realizing value early and providing continuous feedback, small incremental releases help maintain trust that is essential to the success of the project.

Posted on Aug 01, 2010 by Gene Mitelman

Thoughts on Kanban

I've been using Agile techniques for over 10 years now.  When I learned about Scrum back in 2004, I realized that it was very similar to what I've been doing in consulting for a while.  However, I often had a problem sticking with iterations - many of my projects are in maintenance mode where it's hard to enforce sprint timelines and inability of clients to switch priorities mid-stream.  I was sure that many others find themselves in the same situation, yet Scrum didn't address this issue.

Now, I finally decided to look into Kanban.  To my great surprise, I found that it handles this problem very well.  If you like what Scrum offers, but can't quite follow all of its tenets, check out Kanban - you may be pleasantly surprised as well.

Posted on Jul 24, 2010 by Gene Mitelman