Before DevOps, first…
Assess your software development life-cycle model
DevOps DevOps DevOps
You and your team are ready to learn DevOps and implement the tools, practices, culture.
You even have a learning plan.
But, what led you here? Is it the promise that you can deliver value faster?
Why did it attract you? Why did you not choose to say no, not now, not yet.
Sure, DevOps is great. Deliver value.
But before you go into shaking up your team ,setting up sprints and what not, how do you clarify what will work for you and what will not?
First, assess your software development life-cycle model.
Whether a veteran developer or a newbie, you have heard of at least one model, Agile sound familiar?
Among other’s are waterfall, big bang and iterative.
In each model, some things are done differently, but before settling on a model, the software development life cycle consists of the following steps:
- Planning and requirements analysis
- Requirements definition
- Product architecture design
- Product development
- Product testing
- Product deployment
The waterfall model is strict on defining requirements at beginning and following plan to the end.
But, which of the above steps do you skip? What makes your current model insufficient when it comes to delivering value? Is it up in the air requirements that have not been declared and store in any media and are open to interpretation and modification?
What about the architecture? Using a different database solution at the beginning of the week only to realize that your entire data is best stored in a different type of database or perhaps you need multiple databases and spend the rest of the week correcting mistakes?
Who is in charge of what?
When someone comes at a crossroads, what or who do they refer to for guidance?
But then again, here comes the question, as life itself does life always go according to plan? Is life predictive?
A predictive approach can seem seductive, one who loves planning and seeks to avoid confrontation. Since, other than during the planning phase (at which point the assumption is that logic is the ruling faction in everyone’s head), when differences of opinion may arise, there seems to be no room for conflict since all are united. If someone desire’s something that was not in the requirement, since it might be a breaking change or might need a lot of human resource and time to accomplish, it is either rejected or billed.
An adaptive approach, like agile on the other hand is sought to model an approach that is as realistic as can be to software development, where requirements are not always entirely known at the beginning of a project and micromanagement is shunned since developers are trusted to self motivate and organize. Pair programming where collaboration is encouraged is the norm, whether remote or in person. This has the added advantage of making the team keeps itself in check.
Furthermore, demos are the norm, to best capture requirements and get customer feedback, hence communication is a skill that is needed to ensure a smooth flowing.
However, both of these might not best describe your current state. Perhaps you follow the iterative model where agile sprints are of the waterfall model where in each iteration requirements are clearly defined and generally follow the pattern: Requirements — Design — Implementation — Testing
Whatever model you currently use, understand what and why.
Perhaps you employ the agile model but your team members do not collaborate or perhaps communication is poor and far apart between the team and client.
Maybe you are the planning type but requirements aren’t well gathered and you find yourself at the testing phase of the waterfall model with a half baked documentation of requirements or architecture.
Worse is, you have the iterative model implemented but never finish iterations with every sprint and hurry off to the next iteration only to reach a point where the backlog of features or issues to be solved is so enormous, you have to do everyone a favor and start from scratch.
This is why value stream mapping should be the first concern before going any further with DevOps. And it should be done with everyone on board.
Before knowing how to deliver value even faster, you have to know what activities and processes to let go, enhance or add.
