Two Lessons in Motivation

The Setup

The following two stories are from my time at Motorola (1999 to 2014).  They provide illustrative examples of how the same team can have widely differing experiences, depending on the software development process used.  The second example also illustrates the difference between Agile done well and Agile gone bad (done only in name but not principle).

Waterfall

In 2006, Motorola launched the biggest project I have ever worked on:  a three-year development project for hundreds of engineers to not only launch a new line of top-end two-way radios but also simultaneously create new software platforms for those radios and the programming software to operate on.  We had just obtained SEI Level 5 a year or so before, so we were confident that our approach would be successful.

The project was defined using our well-established waterfall approach.  Marketing had produced an MRD (Marketing Requirements Document), and the first six months of the project were to be dedicated to translating that MRD into a TRD (Technical Requirements Document), which would then be used for the actual implementation of the software.  All of the Milestones were well documented in the project plan.  Nothing was left to chance.

When our team started the six-month requirements phase, the first thing we did was enroll in the Motorola golf league.  TRDs and other technical documentation take their toll on the hearts and minds of good engineers, so a distraction was needed we felt, in order to stay motivated.  Two afternoons per week during that requirements phase, you could find us on the golf course getting motivated.

It was not until the end of that first six-month period that the project managers became aware that we had fallen behind schedule.  The documentation had been progressing, but there were new requirements previously unforeseen that also had to be produced.  No worries, they said, this lost time can be made up during the implementation phase.

When the implementation phase fell behind schedule, that's when the PMs started to worry.  No matter how many meetings they held, they were not able to get the project back on track.  Some people were let go for this failure.  

The project fell further and further behind throughout the first two years.  In 2008, they sent two senior VPs down from Illinois to keep an eye on the project.  Even with senior leadership attention, we were unable to make our first delivery date on time.  Luckily, leadership had been well aware of the risks involved in a large "big bang" approach, so they had made limited commitments to our initial customers, and the financial penalties were kept to a minimum.  The product did ship in the end and became a highly successful line of radios for the company, but as with many software projects it was late and over budget and almost everyone was working overtime from the first realization that it was late (about a year and a half into it).

Agile

In 2010, Motorola rolled out Agile across the company.  Team by team, we all learned the Motorola Agile way, and my team embraced it better than most.  The key in the beginning of such an Agile transformation is to have managers who are willing to allow their teams to self-organize and self-manage.  Not every manager at Motorola was willing to let go of their need for command and control.  But the managers in our department who were onboard with the change allowed the individual teams to successfully embrace a Scrum-like framework and self-managing of our projects.  Our team flourished in the new Agile environment.

In contrast to the 2006 experience, our mindset when embarking on the 2010 product was one of urgency.  We had embraced the iterative and incremental approach to software development, rather than the big bang approach where everything is delivered at the end, so we had deliverables due by the end of the first two-week iteration.  I remember leaving my first Sprint Planning thinking, "Oh shoot, we only have two weeks to produce this first piece of software."  There were no golf tournaments for us that fall.

We stayed focused.  Rather than meeting on the golf course, we met daily at our Daily Standup to briefly discuss what we were working on and what our impediments were.  We met regularly with our stakeholders to get input on the requirements.  Rather than spending six months reading an MRD and translating it into a TRD, we were simultaneously writing code while developing new requirements in our backlog.  Everything was prioritized according to value.  The entire focus was on rapid development of working software and refactoring as needed.  We were working in a truly Agile manner, and we were motivated.  We met our commitments that fall.

Other Teams' Deviations

Not all of the teams had embraced Agile as well as ours had.  When I asked some of the other teams' members what they thought of Agile, they would either spit or curse at you.  It was not a positive experience for them.  Their managers, rather than allowing the teams to self-manage, were using the transparency of the Agile tools to micromanage each team member.  As people reported time on a particular task, so that the team's burndown and burnup charts got updated to show team progress, their managers would look into those tasks and demand of the team members why they had spent 3 hours on  a particular task and only 1 hour on another task that the manager deemed of higher importance.  These engineers did not enjoy being micromanaged.  They were not motivated by Agile.  And they did not actually experience Agile, since their managers had not embraced the proper mindset.

Lessons

The lessons here are two-fold:  1. The short time-horizon of the iterative incremental approach gives the team a much higher sense of urgency than the long time-horizon of the phased approach.  2. If managers do not get out of the way and allow teams to self-manage, they kill the motivation that such self-management normally produces in teams.  

One of the fundamental ideas behind Agile is that engineers are intelligent, can make good decisions when allowed to do so, and the collective mind of the team is better than the individual mind of a manager. Allowing teams the freedom to create solutions to the problems with which they are presented will lead to the best solutions.  Motivated engineers who own their product and productivity produce the best results.

So implementing an Agile approach is not sufficient.  Implementing an Agile approach that actually lives up to the Agile Principles is required for the best results.  Everyone involved needs to be onboard with the approach.

<<Previous  |  Next>>