Why your project needs up to date HTML slices

Ok, here’s the situation: you’ve started your project, currently your team has frontend developers and backend developers. Everyone is happy and doing their parts.

As frontend developer I can tell you that the fastest way to slice or prototype pages is working with plain HTML files. It allows you to work with your (S)CSS and JavaScript files without any issues of caching, server-side compiling, etc. It just works.

What happens when the pages are ready for implementation?

You guessed it, it goes to the hands of the backend developers who will do their magic: create the components for choose your favourite CMS here.
At this point we’re still happy, everything is working just fine and the project will be delivered on time.

First iteration

A couple of days have passed and some JIRA tickets have been raised: we need to fix something in the frontend.

No problem, the frontend developer will open up the HTML files and do the proper edits.

Iteration two hundred seventy six

At some point between revision 1 and revision 276 someone updated the backend CMS component and not the HTML static file. Probably the change was simple enough, there was no need to involve any frontend dev.
That is actually fine! It’s way cheaper, project-wise, and faster to develop.

Now, be careful, that decision might cause a lot of trouble in the future, when new major features will need to be added. An out of date slices will force us to download source files from production. We all know those files can be messy, with random ID’s everywhere, extra empty divs, inline styles, uncommented code…

So, what’ the proper way of applying frontend changes?

frontend-workflow-v2

 

I would add that in case of a JavaScript change, even if we’re using Grunt or similar you might be able to do the change yourself. The issue might be that not everybody has it installed locally. Although I would certainly recommend it 😉

Also, if the project has enough budget to have a frontend developer on board, the above workflow is useless. Just send everything to the frontend dev.

Conclusion

Try finding balance!

This best practices should not be a burden, if you get used to it I think you’ll get real benefits. If someone is capable of changing a component’s markup, is also capable of editing plain HTML files.

You should always keep your static HTML files up to date. Not with content changes but markup. I’m not saying it’s easy or cheap but it’s the right way to iterate. Not all projects will have the budget or client will to maintain this code standards. We, as professional, need to advice and convince our clients this is mandatory. In the end, it will probably save them money.

I hope now you have better insight of how you can be more productive and have a better future-proof code in your projects.

Have something to add? Leave a comment down below.

Our motto: Deliver with Efficiency & Quality

Over the past 10 years we have been involved in a whole host of CMS/DAM/web implementation projects of many different kinds (clients of different types and sizes, as a prime contractor, a vendor integration partner or onsite with the client’s teams), and throughout that time we have always stuck to a single mantra: deliver with efficiency & quality to guarantee maximum customer satisfaction.

No matter what constraints we have faced in terms of managing the different projects, we have had to adapt and adopt. It has never been our goal to simply turn up and impose our rules, and it goes without saying that project management is deeply intertwined with corporate governance and enterprise policies.

In that sense, our project managers have their own cultural backgrounds that constantly enrich our internal Project Management Practices. Their principal goal is to deliver “good work, on-time and on-budget”.

We have nonetheless had the latitude to come up with our own PM approach, notably for fix-time projects. We made the decision to rationalize our position by taking account of 2 fields of perception: observations and corporate values.

Perception is where you look and how you look.

jim-denevan-02
Jim Denevan or how to leverage our perception

 

First of all let’s talk about our observations

  • A software development process should be undertaken within the framework of a broader business commitment. That is why it is vital we understand exactly where the needs are coming from.
  • A more easily accessible knowledge, a Do-It-Yourself attitude and the product-oriented marketing have led everyone to think solution before needs, and unfortunately the vital phase of defining the real needs is sometimes skipped altogether.
  • Methodologies and organizations are intrinsically linked by culture, people and processes.
  • Agile methods demand mature relationships between business and IT, something which is often underestimated.
  • Corporate governance policies demand structured and uniform reporting procedures in projects that influence the choice of methodology.
  • Profound shifts don’t happen overnight in big organizations.
  • It is important to remember what the initial idea was: why are you doing the task in hand?
  • We can’t expect an all-encompassing model from the start.
  • The same tool in a different context can generate different results.
  • The requester has a good reason for making his request. Respect that.
  • Academic project management methodologies offer a starting point, but sticking to them reduces the scope of possibility.

Now let’s us introduce you our values

  • A good working relationship with a client is based on a constructive company-2-company relationship, structured team-2-team cooperation and a fair individual-2-individual collaboration.
  • Remember that you will learn from your initial choices.
  • Share the same goals and support one other.
  • Resolve situations that sap your time and energy.
  • Choose the right tool for the right job.
  • Don’t use all the colours just because you have them on your palette.
  • Make sure you are on the right track.
  • Guarantee a common understanding.
  • Demonstrate agility with the product, the method, the organization.
  • There’s always somebody that will use your product, and somebody that will maintain your software.
  • Listen carefully and respect other people’s constraints.
  • There’s no bad methodology, there’s no best methodology, there’s no point confronting waterfall and agile. Choose whatever solution works best for the situation in-hand.

When you are playing the software development game your secondary goal is to setup to play the next game.
Alistair Cockburn, Agile’s father

For our project management we deal with 2 dimensions

Driven by our enlightened understanding and inspired by the values of objectivity, efficiency, openness and honesty, our project management approach has been broadened to encompass two dimensions.

A cooperation framework for a future proof collaboration

Focusing on controlled planning and on broad and transparent communication, this approach is used to build a relationship with the client during first-time projects, one-shot projects or when handling program management issues. Based on waterfall methodologies, the phases are clearly defined and sequential:

  • Initiation to guarantee a shared understanding of the needs , expectations and perspectives;
  • Planning to reach an agreement on scope and timing, organization and risks;
  • Controlled & Monitored Execution with open communication & fast feedback, with close cooperation during the testing phase.

The aim of this framework is to identify the best way of working together in conjunction with the client. The approach is consequently a circular one, paving the way for the next project by means of an extensive closure phase to assess lessons learned and review the next steps.

Graph_04-EN-2The method focuses on control and communication, which means that numerous deliverables are required:

  • Engagement framework
  • Project Statement Of Work
  • Functional Contract, Solution design & Detailed planning
  • Monitoring reviews
  • Issue tracking with JIRA
  • Product evaluation & acceptance report
  • Project closure record

A fast-delivery framework in a mature relationship

Usually adopted when a mature working relationship has already been established with the client over the course of previous projects, this light and agile method demands a clear commitment in terms of roles and responsibilities. Guided by iterative development and agile methodologies, this approach is based on iterative cycles backed by delivery contracts:

  • Inception to define high-level requirements & engagement;
  • Elaboration using the iteration plan;
  • Execution involving strong collaboration;
  • Transition to review delivery and acceptance;
  • On-going assessment for strategy assurance and scope refinement.

Graph_04-EN-1The method is suitable for product enhancements (change management) or large roll-out projects that involve adding new features to a central environment based on new needs highlighted by a country/division assessment. These iterative cycles can also be run in parallel within the framework of a larger program. That is why the method is based on a light and versatile organization:

  • One project master, responsible for scope, communication and planning;
  • One product owner, usually a client representative or a commission agent, who can make quick & firm decisions, ensure that the functional strategy remains consistent and accept the deliverables;
  • One technical owner who plans and takes action in order to deliver on-time (this is usually a lead developer who is directly involved in the build).

All kinds of additional players may get involved at specific times or for specific reasons. The initial statement of work is put together when the project first kicks off, and then all subsequent communication is handled through our JIRA environment until the project is formally closed and the evaluation reviews are completed.

Our years of rich experience have shown us that these 2 frameworks can cover most situations, as long as the client doesn’t ask us to follow their own policies. Project management is not a science, it is simply good sense driven by experience, basic techniques and positive collaboration.

Being Agile depends on mind, personality and organizational structure.

During the past years along with the advancement and integration of information technology and digital experience within the business processes of companies and organizations, a lot of management methodologies and definitions have been created. In order to form processes towards the goal of easing project management along with efficiency and successful results. It’s the golden era of certifications after all, expanding to a technical, non-technical and theoretical spectrum.

A lot of methodologies include the agile terminology. The importance of being agile is not something new but it is now being accepted and recognized by a wider group of professionals. The term Agile derives from Latin “Agilis” and the meaning is: “to do and act”. Throughout the years the meaning of agile has been also characterized by being quick or alert. Different approaches including almost every phase from business analysis to project closure and software development to quality assurance have emerged. Most of the approaches are very similar with comparable tactics, differentiating mainly on the new areas (business topics) of implementation. Being agile is not another new business process or methodology, it is a logical process of how things should be working. We can all retrieve agile implementation/behavior tactics and actions, before various methodologies became popular or recognized.

The success of any agile methodology requires the existence of specific personality quality assets and traits of the people that implement the methodology. A list of indicative traits follows:

  • Be Active and Resourceful.
  • Be Able to make Educated Guesses.
  • Have, share and Test ideas.
  • Research and Learn.
  • Elaborate and Analyze.
  • Communicate efficiently.

Specifically for the IT sector, Agile methods like Scrum can provide a framework, but:

  • It’s the programmer’s mind who creates software, write or do not write quality code.
  • It’s the business analyst’s mind that filters all necessary input from teh stakeholders.
  • It’s the project’s manager’s mind that keeps implementation aligned with the customer’s needs and within budget.
  • It’s the QA team’s mind that reviews and provides the necessary input for improvement and corrections.

There is need to train people for agility and help them follow agile methods but this is just a stepping stone within the organizational environment that should provide the personality and teamwork traits of agility. A provision that is not an easy and fast but an ongoing internal cultural change management process.

Another value point to mention regarding the success of being Agile is to know the form of Agility we implement. For example, we all know that the initial phase of requirements and design is an extremely important phase and the driving factor of success of any project. By omitting and not pay attention at this phase will lead 100% to an agile behavior (not agile good practices) that its goal is not to improve the product but to apply temporary fixes, correcting and hiding design mistakes and poor documented stakeholder requirements.

Thus we have to distinguish between agility that tackles and improves a project task and agility because of poor organization and design. These are completely different.

Another example is quality assurance, an integral part of every project’s implementation. A poorly executed QA means that the agile methodology implementation during development was either not efficient or overlooked. Again, we will be forced to take corrective actions with agile resolutions not towards a well-executed project but towards a project that will just pass the contract’s terms. The bottom line is that agility has many faces and we must try to “wear” the effective one. A lot of agile-inspired projects start out with great hopes and commitment to moving through projects in a fast and energetic way but they often end up embracing failure and unhappy customers.

According to Sutherland and his Agile manifesto the four basic tenets of Scrum that guide efforts to achieve quick turnaround of product development with high participation and quality assurance are:

  1. Planning Is Useful. Blindly Following Plans Is Stupid.
  2. Inspect and Adapt.
  3. Change or Die.
  4. Fail Fast So You Can Fix Early.

The Agile concept is cultural at heart and methodological on skin. It is impossible to apply any methodology within an organization if the general culture does not support it.  Agility should be applied to all functional levels of an organization. For instance in Finance, HR, Regulation, Production, Sales, Marketing not only IT. The reason is that every project within an organization internal or external is impacting parameters that are affecting more than the project itself. It is impossible to have agility in Sales and have an opposite attitude in Marketing.

Another major difficulty takes place through the usual scenario of involving more than one company in a project. For example the interaction between a software house using agile methods and a customer whose corporate culture puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users.

Work that does not produce real value is madness. The correct agile methodology of “working product in short cycles to allow early user feedback so we can immediately eliminate what is obviously wasteful effort” in this case becomes just a theory and Agile becomes another recent “cool” term to mention.

To summarize agility about culture, flexibility, attitude, personality and philosophy that leads to effective, beneficial and non-bureaucratic practices throughout the entire business.