Back at my second real IT job, we did not have what some would call today “true” agile practices.
I say that because we did a great deal of up-front design work, requirements gathering, and signoffs. Those are all things that most “agile” shops I’ve worked with avoid like the plague.
Somehow though, at that job, we seemed to find a way to get our work done, without burnout, only working 8-hour days (often less), finding time to learn-on-the-job, and all while building a great relationship with our customers.
We played basketball for lunch, sometimes for 2 hours. We came in late, left early and NEVER worked on nights or weekends. Deployments were done during the day, never off-hours.
The team went to technical conferences for a week each year, still took two-week vacations, and enjoyed our holidays off. We stood at our cubes and talked … often.
Morale became so high that developers started pitching in, volunteering to host lunch-n-learns. On those days the company sometimes opened the soda machine for us OR developers brought in a pile of quarters to share with their peers (crazy huh?).
We played video games on the company machines at lunch. It was a fun place to work.
And we did work. We did excellent work.
- We released multiple, enterprise applications to production.
- We maintained countless lines of code that we never got to re-write but always wanted to.
- We made websites, SQL jobs, reports, and desktop applications and took support calls directly from our users.
- We learned on the job, running out at lunch to buy books, helping each other code, and reading tons of articles.
- We supported one another’s software as well as one another.
- When one person had a problem, it was VERY common for a group of us to stop what we were doing and gather around to help if we could.
- Developers researched new technologies, recommended them to the team, tested it all and wrote documentation to justify the changes.
- We wrote proof-of-concept applications to demo new technologies to the team before committing to it.
- The developers not only wrote all the code but also all the documentation.
- We met with the business. Sometimes just one developer in an entire room full of business people to understand their goals, and help them to navigate their options.
- We took our own notes in those same meetings and sent out the minutes to those that had attended.
- We regularly delivered around the office requirement documents, which we developers had written, requesting sign-offs that necessitated our meeting with all levels of management in both IT and the business.
- We developers wrote our own Change Controls when requirements had to be modified.
- We wrote our own acceptance testing procedures and took them around for sign-offs as well.
- Our software development life-cycle was well documented, structured, and we all stuck to it (because your process protects both your team AND your customers).
- Some of us did eventually leave the company (due to a change in management that wrecked the team culture we had built) and when we did, the business folks took us out for lunch to thank us for our many years of excellent service.
It truly was the best of times.
Our process had what some today would think to be a lot of documentation. There was a good deal of rules to follow. The business did not always want to follow the process but the developers were enabled to work closely enough with them to push back and make sure the process was honored.
What made the experience at this company so great was that we were never under a microscope, hours were not tracked, and we never had daily status updates. Rather, we agreed with the business upon a time in which we thought we could deliver what they needed and our team was trusted to do that.
Outside of that basic constraint, we were truly free to innovate and create. We thrived as a team; we cared about what we did and who we did it for.
Reading over the Twelve Principles of Agile, we had all twelve in our repertoire by the time I moved on to another company.
The Wrap Up
If you’re building a team or have one that needs help, I recommend you extend your absolute trust to them like the example I’ve outlined here.
This type of environment is what most everybody, including team leaders/managers, that I hear from actually want. I would say if you don’t want [something similar to] what I’ve outlined, after seeing the results it provides, then you may want to rethink your career choice as a manager/team lead.
What I run into instead is that most managers believe that speed to market is the most important thing. That’s so cute. I could just pinch their little, inexperienced cheeks.
In reality, slowing down, documenting things, upfront design, limiting the scope, and focusing on quality is where projects need to begin. You have to have the courage to change your culture in this regard. And it’s not easy.
Then, the most important part is letting go. Stop micromanaging schedules, worrying about story points, and forecasting your next unicorn release, six-months-out. Nobody cares.
Instead, HEAVILY focus on relationships in your team and especially learn to trust them. Focus on it like your success, the success of your team and the success of your product(s) depends on it.
Because it does.