Tag: agile

Upside down Servant Leader

My favorite aspect of the agile and Scrum concepts is promotion of Servant Leadership.  As a manager of all types of technical, support, marketing, and project management teams for enterprise software products, this style fits best with my experience of what works, specifically in managing highly knowledgable and engaged individuals.

Leadership clearly comes in many forms, and has been the subject of countless books and diatribes from business consultants and CEOs.  All show examples of how their preferred approach has been successful.  It isn’t a novel concept that the optimal form is dependent upon the individuals and circumstances.  Looking at software business and technical management, here is how I picture it.

military leader

At one extreme is the autocrat – the leader who believes in his or her way or the highway, runs the software shop in military style, simply making assignments of work and enforcing timelines.  Top down leadership.

organization-chart

At the other extreme is what we used to call the upside-down organization chart.  This was a dramatic concept where the manager’s sole role was to serve the employees.  The concept being that it is the leaves on the organization hierarchy that are the subject matter experts, actually do the work, and management is just there to get them what they need.  Some might believe this form is what is meant by servant leadership, but not really.

Somewhere between these concepts is the Servant Leader model.  In this blog I am not here to explain Servant Leadership, there are plenty of others that do it better than I can. For me, it is how I can lead with authority and accountability, while still having each person on the team AND the team as a whole retaining a level of authority and accountability.  It takes the best of each, from the first extreme it provides strategy and direction, and from the second the leader is the facilitator, the remover of outside roadblocks.   Teams are made up of professionals, and both the leader and each team member has a job to do, and this Servant Leadership term for me pulls it all together well.

I am sure you do not all agree with me, tell me why – or share yet another historical viewpoint regarding other approaches.

My progress from Waterfall to Agile

My progress from Waterfall to Agile

Basic Waterfall . . .

My background in software development started in the early 1980s, so the waterfall development approach was fully ingrained in my psyche.  I had always been interested in new approaches and collaborative concepts for iterative improvement and collaboration.

Quality Circles . . .

Starting in my being “volunteered” to become my department’s Quality Circle guru (Japanese Quality Circles were defined by Professor Kaoru Ishikawa in his handbook, “What is Total Quality Control? The Japanese Way”, Prentice Hall, 1985).  Remember those?  Few people do and I am not sure they got far outside of the manufacturing realm into the core software mindset.  But they were the first time many of us experienced the concepts of Brainstorming, Fishbone Diagrams, and other team based idea generation methods.

JAD Sessions . . .

Now back to waterfall and agile.  My first experience in moving from the “throw requirements over the wall” approach to collaborative software requirements was the JAD (Joint Application Development) session.  While the overall project still followed the waterfall methodology, at least the up-front specifications were done in a team setting, and with participation from all parties across the software life cycle, from customer through to the QA and Deployment engineers.

Nightly Builds . . .

The next major step was on a very large project with multiple development sub-teams (I had the one handling integrations and communication protocols), where the outrageous idea of an automated nightly build was instituted.  Radical, and fought against, it actually worked!

Developer Demos, Pair Programming, Shorter Iterations . . .

Then the changes just kept coming.  By now I was up the management chain. I switched to smaller companies and had more control over what the full software and QA teams did, and new concepts were attempted.  Resistance seemed to always be the biggest issue, but I’ll talk about that another time.  For me, each attempt brought some new insight (and much hindsight) into options other than the traditional release schedule and documentation requirements.

Extreme Programming and Agile Life Cycle . . .

Now I am deep into the concepts around Agile development, and focusing more on how to contract and specify customer needs rather than implement.  One last thought here, is that I strongly believe that there is never 1 right way, and there is still a place for pieces of each concept I learned along the way.  The challenge (and fun) is fitting the best approach to the problem and project at hand.

This was my experience, I would love to hear yours so please comment.