The Fast & Furious
Many of the projects I have worked on had initial similar traits – understaffed, underfunded, and behind schedule. I call this the Wild West West (WWW) phase. Although this stage is chaotic and stressful, I enjoy this stage of a project. There is a tight collaboration between business and technical teams, lots of challenges to solve and everyone is motivated to get sh*t done. The problems in the WWW phase are standards are not followed, the SDLC is out the window, and quality, maintainability, and supportability are afterthoughts. The WWW phase is often fun, challenging and gets the job done but, it is not sustainable and does not produce a quality product.
Regroup & Breath
After the first release is out the door, critical support items are resolved, and things are generally speaking calm, it is time to regroup and breath. It is important as a team to review the processes that are used and ask some key questions:
- Do we have the fundaments in place?
- Is everyone on the same page of what the fundamentals are (SOLID principals for example)?
- Where do we start to mature the delivery process?
- Is there time allocated in the schedule to mature the model?
- Do we have the right resources for the team to help mature the process?
- Do we all agree on what the definition of “done” is?
- What’s needed to improve quality?
This is an initial set of questions I start with when I in the regroup & breath mode. Maturing the delivery process is all about supportability, maintainability, and having a predictable and repeatable process. Even for the most seasoned teams and IT professionals, it takes diligence, practice, and time to ensure that the core principals are followed.
Back to the Basics
For a project to be successful in the long term, the basics must be at the core of the delivery process. After each deliverable, sprint, or major milestone, I like to review with the team the fundamentals. There are many, but four key aspects stand out:
- Quality – what is being done, for each discipline, to ensure the team is delivering the highest quality possible. I look for specific items such as functional and technical design sessions, UX reviews, code check-in & reviews, and unit and system testing.
- Supportability – support is one of those areas that are often forgotten in the mad dash to get things done. Having spent some time in the support world, I try to instill the importance to the delivery team of building a supportable solution. This means at a minimum of having the appropriate documentation, logging, notifications, and training for support personnel.
- Maintainability – one thing I love about being a developer is that you get to code some really cool stuff. Not only that, but you often get a second chance (refactoring) to make your code better – condense it, make it more efficient and more elegant. Refactoring can be taken too far though – what was readable and easy to follow now looks like Ancient Sand Scripts. My guidance – can someone read the code a year from today and understand what it does? If so, it is probably maintainable code. If not, consider additional whitespace, comments, or a clearer way to write the logic.
- Repeatability – it is vital to introduce a repeatable process in everything that is done within the delivery process. This starts with the UX design reviews and goes through training the support teams. The process does not have to be fancy, automated or complex, but it does have to be agreed upon, dependable, documented, and followed. As the project and team mature, this is an area that consistently evolves. In my experience, this is always a work in progress.
Final Thoughts
The SDLC, design & code reviews, training sessions, and so many other items all contribute to a successful deliverable. The basics are not sexy, but they are the difference between a successful solution that provides value for many years vs. a one-hit wonder. When in doubt, pause for a moment, review the processes in place and get back to the basics.
Until next time.
Chris
My Musings 
Awesome post. I spoke to my lead about the WWW phase and how we are neglecting unit tests in favor of faster delivery. He assured me that, once the project is done, we will take a breather, than go back and refactor code and add Unit Tests.
The reason why he favored functionality over unit tests was because we promised a customer we would have something out on a date. A customer won’t accept a late product because “There is not enough unit tests.” Which make sense.
Is there a way to add unit tests and have correct coding practices in the first phase of a project so the WWW phase can be avoided?
I understand that there is a mesh of theory and application and balances have to be made between correct coding practices and external deliveries.
LikeLike
Hey Darren,
Great question and one that is a constant challenge for every project – even those that are mature. The general approach I take is to spend X% of time delivering functionality and the rest of the time (Y%) maturing the model. For example, in the first release spend 95% delivering functionality, but ensure design and code reviews are part of the process. In the next phase, decrease X and increase Y by a small factor, maybe 5%. For example, in phase II of a project, start retrofitting the existing code base to include tagging for automated tested or introduce VSTO Unit Tests and Acceptance Criteria. In my experience, the ratio between X and Y does not go beyond 75/25 (75 functionality, 25 process improvement) unless you are in pure maintenance mode. Every project is different, but the overall goal should be to deliver functionality and improve the delivery model and quality of the solution.
HTH
Chris
LikeLike