I've been practicing agile software development since the early XP days. When the agile manifesto came out it seemed to echo many of the things that I found good about agile software development. For our shop we needed agile software development so we could eliminate waste in the form of unneeded features which contributed to code bloat. To eliminate this waste required the participation of our customers. Customers would meet with us daily in a variety of ways, email, face to face, or in instant messenger. They would see the progress we made on a particular feature and say "good enough" or propose corrections. All in all it was a very efficient process. Likewise, as a manager I met with the business weekly to ensure that what we were working on was aligned with their objectives. In an ideal world, their objectives would line up with the company's strategic plans. This was a perfect synergy of strategy, tactical objectives to achieve the strategic goals, and software development addressing the objectives in two week releases of new features. I often thought about the unexpected by product of this whole process; happy customers and more importantly happy staff. It seemed that no matter how daunting a task I gave my team, they just smiled and got down to work on it. Truly, this was a software development manager's dream. Little did I realize that the happiness was a byproduct of 'flow' and that flow was a direct result of agile software developments' other tenets, namely self-directed and self-organizing teams.
Consider the following principles as described on the Agile Manifesto website:
- The best architectures, requirements, and designs
emerge from self-organizing teams. - At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. - Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done
As a software development manager I was encouraged to turn over command decisions to my team so that they could come up with the architectures, requirements, and designs. My job was to accurately relay the problem and manage any impediments to progress. Our team would get together monthly and review what worked and didn't work and adjust accordingly. My job changed from getting hands on with the code, to supporting my staff, hiring the best and brightest to join our team, and understanding the needs of the business as deeply as possible.
Our team evolved into a very dynamic, highly cohesive, unit that would work together, eat together, and celebrate victories together. From the first design principle, people well versed in architecture started to shine and teach others about better ways to develop software in accordance with design principles and patterns. We moved from good ASP.NET developers to really good object oriented developers. This transition helped us bridge the religious divides of Java and .NET as we quickly started to attend tech talks and pattern workshops with the Java guys (they called us the 'sharpies' (for C Sharp (C#)) and we called them the 'dullies'). How was all this openness, honesty, and good work ethic achieved? Was it the agile software development methodologies we were following? No, it was the fact that in spite of all the hard work, we were all very happy. We took IMPOSSIBLE requests and turned them around in weeks, not months. We were by all measure one of the most productive groups in all of IT at the time. So where did all of this happiness come from? In a word, FLOW.
So, what is 'FLOW'? Flow is a concept described by Mihaly Csikzentmihalyi. I could spend this entire post describing it. But I would refer you to two really good articles on the subject, Frank Heckmans' article on 'Designing organizations for flow experiences' in the Journal for Quality and Participation, and an excellent post by blogger Steve Pavlina on the 7 Rules for getting into flow. The simple description of flow is the experience of happiness, energy, and creativity when someone is perched between impossible goals and insipid, easily achieved goals. In that fine line of tension, energy manifests itself, creativity is forced into play to achieve the 'nearly' impossible, and people just feel in the 'zone', invincible, and most importantly, HAPPY. There's a growing body of research that supports this psychologically, sociologically, and even anthropologically. It seems the state of flow is a very human experience from our antiquity. Flow was something that developed in the early nomadic tribal groups, wherein members were all called upon to participate, lead, follow, and play different roles.
My agile software development teams seem happier than other non-agile teams. I believe it's because agile software development in whichever methodology you choose, fosters flow. Its practices contribute to and create opportunity for flow experiences. Agile software development does this by way of its aforementioned principles, self directed and self organizing teams. These mirror the research done by Emery on the design principle of work organization that leads to flow; self-managing, adaptive group structures. Like the many links one sees to the Fibonacci sequences in nature and the universe, self-organization has roots in autopoiesis, complexity theory, physics, and biology. It would seem that self-organization is the natural order of things and when human beings at work in any area follow it, they are happy.
Emery's research suggested six requirements for human productivity. I will translate these to aspects of agile software development and how managers should structure the organization around that team for maximum productivity and employee satisfaction.
- Autonomy – Self organizing teams are self-directed. You may suggest problems for them to solve, challenge them on the accuracy or completeness of their solution, but you can't employ traditional top-down management with them. You have to give them support and guidance so that they get needed direction enough not to feel lost or bored, but not so much that they feel like they have no ability to influence their success in the organization.
- Foster a learning environment – This is something Google does exceptionally well in theory, they encourage staff to learn new things as long as they are loosely related to the company's overall aims. Agile teams constantly challenge one another to do more, work smarter, and learn new ways of being more productive. This makes people happier as a result.
- Variety – Cross functional teams are advocated in agile software development. Cross training and mentoring are hallmarks are these teams. This leads to variety which helps people stave off boredom. Beyond that, as managers we should constantly be exploring new technologies and encouraging our staff to do the same. It's not technology for technology's sake, it's applied when applicable and at the very least the lessons learned can be applied to the employee's current assignment.
- Mutual support and respect – Loyalty to the team, mentoring, and a healthy respect for each other's various proficiencies are keys to success in software development. Teams who have mastered this are able to cover for one another in absences, pick up and help one another without direction from management, and can self-organize along respective strengths better. Again, the end result is a feeling of belonging, a feeling not of us against them, but rather a nearly familial pride in each other. Agile software teams achieve this by virtue of cross-training each other, mentoring each other, and working as a team on their goals.
- Meaningfulness – This one is harder to quantify for some managers. The suggestion here is that people like to think that their work makes a difference, contributes to society, and helps their employer's bottom line. How does agile software development help to achieve this? By releasing software in regular, incremental intervals. Agile teams release software every 2-4 weeks on average. Projects which take 60 days or a little more are rare. Project lasting 90 days are almost unheard of among agile teams. This means that software developers see their efforts, their code, and their creation, go into use. They get regular, almost daily feedback from their customers about how well the software works. Agile developers make a difference in their customers' lives and as such they derive meaning from their work.
- Upward mobility – Some software developers feel stifled in their positions. They feel like they are spinning their wheels. Their software never sees the light of day and they will never get promoted or receive recognition. Agile software developers on the other hand know they make a difference. They can feel themselves growing as they get mentored, as they pair program, as they evolve newer and more efficient ways of writing software. Just the fact that they are on an agile team or can add experience with agile software development methodologies to their resumes is a huge plus. This in combination with the ever growing list of achievements added to their resume makes them more marketable. The really wise software development manager will promote from within, recognizing his or her employees' growth thus extending their tenure at the company. Likewise, be sure to backfill these promotional vacancies with junior level new hires that show an aptitude for learning and a 'go-getter' mentality. Lastly, as a good software development manager, recognize that at the apex of your senior staff's development, they will leave you for larger, more lucrative projects with national or global companies. Rather than trying to woo them back with unreasonably high counter offers or worse, veiled threats of sabotage or retaliation, celebrate their success within your team. This will build your personal network of former developers (who can buy you sushi someday) and will send a signal to your existing staff that their jobs are not dead ends, that they too can expect a celebratory farewell lunch someday.
So what will happen if you follow my advice? Will you get rich? No. You will not be personally famous. But, if you do decide to adopt agile software development (agile with a small a) then you will most likely have happier, more productive employees. It will help people that work for you get into the 'flow' and that experience by all accounts is meaningful, memorable, and makes a difference in people's lives. And if you're lucky, you may just end up on a list of some of the best places to work in IT, over and over again.
