When interviewing candidates for roles in product management, engineering or other development related disciplines at most software companies, you receive plenty of resumes with AGILE, CERTIFIED SCRUM MASTER, AGILE COACH, etc. etc. etc. splattered across them.
This may be exactly what you are looking for in candidates. If so, that is great, and in many cases, these are extremely talented and qualified individuals who will become value added members of your organization. I am merely pointing out that the use of the term agile has become bastardized in recent years, due to the fact that ‘waterfall’ has become toxic waste in the software development industry and that the proliferation of use of these ‘agile-centric’ terms is indicative of this shift.
This piece is written from my perspective as a product manager at an early stage startup who was tasked with helping us scale. That sounds like a pretty common problem, but one that is often not solved effectively, so I do hope there is something you can relate to here.
I have had the opportunity to help form several product/engineering teams and to observe the formation and functioning of many others. Some performed well, others struggled and most did both at different points in time. In this most recent experience, I have taken what I have learned up to this point and attempted to apply the good and avoid the bad in working with a nascent team…in many ways a blank slate as far as process was concerned. Fortunately, I have the benefit of working with a great engineering team and a strong counterpart leading the engineering organization and our views largely aligned. I cannot emphasize the importance of being aligned directly with engineering leadership.
Now, when we formed the product development process, it came down to who the people on the team were, not what process should be put in place. We were all familiar with the agile principles, scrum methodology and other various and sundry methods and processes for building software. We also knew that it’s simpler to throw a process onto people then blame both the people and the process when it does not work than to do things in what we considered to be the right way.
So, what do you do? As mentioned previously, we chose to mold the process around the people we had. There is a huge caveat here that you need to take into account. You had better have people who are invested and on board, willing to change, and talented to make this work. That does not mean that the people have to be perfect. They simply must be flexible and have the desire to improve.
After making the decision to base the process on the people, we took the principles that mattered to us and decided to build a process that held to those while taking into account our personnel. We chose not to be heavy handed in terms of the time and effort requirements of the process for those who had to follow it. The principle here was to create a process that would be followed, could be measured and could be evaluated to see if it was stringent enough to work without weighing down the team.
We also desired to adhere to many of the agile principles in their purest forms such as iterative delivery (sprint structure), collaborative teams, valuing high quality code, and postmortems. However, we also chose to schedule dedicated planning time and to pack sprints and attempt to not disrupt them with changing requirements during the sprint (and to be a bit anal about this).
We have had challenges with implementing the process. The first challenge is disseminating the goals of the process clearly to all those who have to follow it and to get everyone on board with the key tenets. If you cannot accomplish that, you will fail.
It is difficult to balance the act of attempting to be flexible, collaborative and also to prioritize planning and structure. The emphasis must be on communication amongst teams and strong prioritization and planning on the part of the product management team in order to allow engineering to execute effectively during the course of the sprint and to create time for the product team to collaborate with engineering throughout the sprint.
The next is to actually follow the process, because it will be a mess for the first couple of sprints. You must stick with it.
Next, is to remember that process is flexible. The only way that a process can exist is to be flexible. The process must be iterative in the same way that you claim your product development to be iterative. If it is not, you will start to move away from the process and it will become antiquated, and it will fail.
Finally, people are first, and the process is second. I hope you see the trend here. Make the process work for the people on the team. If you do that, you can actually create an effective process for developing great software. You can also overcome challenges. You can also more effectively measure the capabilities of a person to work within a defined process. A process will bubble up personnel issues, even if the process is built around the people. It will not hide issues. This does not mean that you have failed to build a people-centric process, but that you now have the opportunity to specifically address arising personnel issues that would have otherwise flown under the radar.
If you need a refresher, here are the basic principles of the agile manifesto. These are what hundreds of books have been written about in the past decade plus. It’s always good to go back to the source of the words that we use so often.
One way to think of it would be as a correlation to the Bill or Rights compared to the mass quantities of legislation we have penned since the creation of the Bill of Rights. I absolutely know that’s an imperfect comparison, but it is only meant to demonstrate the level of interpretation that occurs when simple principles are written down. If they resonate with people, they will make it their own. This can work well or become an absolute debacle or fall somewhere in between.
The Principles of the Agile Manifest:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
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.
The takeaways here are that just stating ‘we are agile,’ or something to that effect is actually meaningless. On closer inspection many teams operate in true agile form and it’s a massive failure, other operate in a mini-waterfall approach and are extremely effective and successful.
The key is to identify a process that aligns with your key values, get your people on board (make sure you have the right people…constantly), implement the process, obsessively follow the process, measure and iterate. Be willing to change. It’s not a failure to change the process. View the process as software. The evidence of progress is positive change.
Email me when Matthew publishes or recommends stories