What is Polaris?
The north star relative to which you should set the course of your projects and meet your actual needs. Do everything in your power, without setting boundaries for yourself and going beyond your preconceptions, to achieve your goals.
Polaris is the result of years of experience developing software for big companies. It is not about ceasing being agile; it is about being radically agile and adaptive.
Manifiesto Polaris
01
Steadfast in Agile principles. Flexible when it comes to adapting the method to meet the needs of each project
02
We do not just deliver software that works; we also deliver software that is well made and makes businesses move forward. The secret of our success is making our clients grow.
03
We simplify things as much as possible so that people can fulfil their true potential. No code line, sticky note or meeting happens if it does not add value.
04
We are people, and so are our clients. We create an inclusive work environment where all of us listen, motivate the others and cooperate with each other.
05
We are committed to the team and the needs of the project beyond individual roles and personal interests.
06
We use our experience to stay one step ahead, anticipating risks and improving on the client’s initial idea.
07
We give feedback with courage and receive it with humility, striving to improve all the time. So, if these principles are not being adhered to in your project, please speak up.
The 9 basic principles of Polaris
-
True North
Agile withstands all changes; your wallet does not.
True North makes us lift our head from the keyboard so that we do not lose our way.
With one glance we know why we are in the project, what the red lines and keys to success are, how we plan to get to the finish line and how budget progress.
See more about True North. -
Agile Delivery
Results over methods.
Nailing the timing of events and copying the framework of the day cannot be the goal. Following a method to the letter and the project still going wrong or some of the parties being unsatisfied is also a failure.
See more about Agile Delivery. -
Continuous Discovery
You are not a hamster on a wheel; every project needs a strategy.
A good product owner is often required to have superpowers. You can create a good backlog by only using design practices. Otherwise, the result most likely will be something that nobody needs. -
Worthy Metrics
Metrics, not adverbs of quantity.
Metrics provide us with visibility and transparency. They serve as a link between business and technology and can centralize relevant information from different work tools. -
Risk Focus
Not talking about risks does not make them disappear.
It is clear that empiricism and adaptability minimise risks, but they are not enough. Focusing on risks during the day-to-day development of a project can make all the difference. -
Adaptative Framework
There are no silver bullets.
“My company is different.” “Here we do things in a particular way.” “So and so is just a bit special.” “This project is strategic; there are many eyes on it.”
We have heard these phrases countless times... and yes, we truly are all different, yet we ignore these truths when we think we can apply the same method as a de facto solution. -
Technical Quality
Just because it works does not mean it is right.
A good digital product is not only usable and attractive; it must also be maintainable, secure, scalable, stable… Technical excellence is a non-negotiable must in order to avoid cost overruns in the future.
No matter how many rules and good engineering practices are defined, the best bet is for the entire team to share the responsibility for built-in quality. -
Productive Mode
Bad habits ruin the best minds.
There is no method that can save an unproductive team; it is a “chronicle of a death foretold.” Hence, the smart thing to do is to incorporate good working habits into the method itself and facilitate their adoption in projects. -
Team Experience
We are not – and we do not want to be – robots.
Project management is halfway between an art and a science, where people are one of the most complex parts.
Making the “individuals and interactions over processes and tools” principle tangible and real is a sure bet to make things work.
Agile works – but it is not enough in a client-provider context.
Cristina de la Bandera
Agile Business Development
Why Polaris?
The problem is not what Agile says but what it does not.
Over the 15+ years we have been agilely developing software for large companies, we have realised what the actual needs of projects are and, more importantly, which aspects are covered by agile methods and which aspects we have had to bolster with our own practices to complete them successfully.
There are no silver bullets... No matter how hard we try, the world is full of exceptions.
Unfortunately, trying to always apply the same magic formula only leads to frustration and failure because it will never work if we do not consider the different environmental conditions (the type of contractual relationship, the challenge, the degree of technical complexity, the organisation of the teams, etc.).
Agilism has become an end in itself.
Its essence has been watered down as a result of building a whole Agile industry around it, where methods and practices have been put above goals and results, and certifications and training above actual experiences.
What Polaris is not.
We have not reinvented the wheel.
No, we do not reinvent anything. We arrange everything so that it makes sense based on our experience. There is no need to panic. It is pure Shu-Ha-Ri: our experience leads us to redesign the rules.
It is not a radical departure from traditional development.
It is indeed to understand that some elements of traditional management can be useful. And that we must speak a language that is similar to that of our clients. But without carrots and sticks and without quiting our values.
It is not a catalogue of tools.
It is not a question of turning tools into procedures but of commitment to and attitude towards values and a manifesto. Nor is it a question of devising a new method with more events and artefacts; we take advantage of our experience and take what we know works – smartly.
It is not lowering our standards.
We are not going to be complacent, or less disruptive, or less disciplined, and we will not do what we are told to if we do not think it is in the project’s best interest. It is an approach on paths that are different from the current ones, focusing on what is really important for a project.
It is not another agile thing.
This is not a rebranding of Agile or a new twist on Scrum Masters. It is the real, first-person experience of all of Paradigma’s knowledge circles, finding together a better way of doing things.
Publications
Loading posts…
Would you like to get the most out of our experience managing agile projects in real environments?