Enterprises, in general, are not known for their innovative capabilities or for their short times to market. Most ideas die in the ‘would legal approve?’, ‘it is too complicated’ or ‘what if?’ phase. The term innovation in most enterprises is an empty phrase and on one part that is a shame since they have the means to fund new propositions from which we might benefit. On the other hand, to be honest, I think it is okay. It leaves room for individuals, startups and smaller companies. Let other people have a piece of the pie also.
But sometimes you get the opportunity to start something new within a company. The simplicity in which you could set up your shop normally does often not apply here. There are rules and regulations, there are numerous departments that want to have a say in things and everybody has an opinion on what and how you should do things. You could say that this is ‘just how things are’ but you also know that the whole success of starting up and validating a new product or way of working is based on speed. In order to gain speed you have to be like Asterix and Obelix a bit more. Be the small team that gets out there and fixes the things they need in order to make their idea a great success.
The following tactic I often use when creating new products in medium to large organisations. These projects often have a secondary function besides delivering working products in a short timeline. They also prove to the rest of the organisation that it is indeed possible to accelerate and deliver better software sooner. They can be used as change accelerators on multiple subjects.
1: Choose the technical path of least resistance
While I am normally very interested in new tools and tech, in the context of an in company startup, where we are not in control of these tools, I’ll make sure that I’ll pick the stuff that I know already works. I will rather choose the older not so sexy continuous integration tool that works suboptimal than the new tool they ‘will finish in the next month or so’.
2: The simplest working (technical) solution is often the one we pick
The stuff we make is there to serve certain business goals. Validation of those business goals with real life users is what we want to achieve asap. So when deciding on architecture, how to create certain functionality and which tools we should use, this is leading. What is the quickest way to get the desired functionality to the user? We don’t need all the ‘free’ extras a certain framework will give us for ‘later’ use if we can easily create the functionality ourselves right now. We however never choose a wrong or dirty solution. Quality remains non negotiable.
3: Second best is best sometimes
In regards to both functional as to technical challenges it is often very natural to pick the best possible solution. And spent a great amount of energy and time on this. But in cases where the first solution is time consuming or adds more complexity than needed I often switch to the second best solution pretty quickly if this solution means more speed of delivery. Also here: We however never choose a wrong or dirty solution. Quality remains non negotiable. A great way to find the balance is asking the business if a certain feature (in the most optimal way) is worth 2 weeks of budget. Or would they be okay with the second best solution which might be around 6 days? Let’s have a healthy discussion about value and options.
4: Go to production in the first week
The step from test to production often tends to be a bureaucratic, overcomplicated process in enterprises. You sometimes have to beg for the proper rights on your own instances. Because of that it is a good idea to try to deploy your ‘hello world!’, a minimal setup of your app to production asap. I always want to be able to prove we can get our ideas to production if we want to and not end up in a situation where going to production is the ‘only’ thing that needs to be done. And then find out that this will take 3 months… The longer you wait getting to production the more problems you will have to solve in the end. Also keep in mind that some things just have a very long throughput and a lot of approvals needed so the sooner you set things in motion the better.
5: Talk to everyone
When starting something new in an enterprise one of the hardest things is to find out who, what and where. There is so much outdated documentation and non-documented initiatives that you might have to use, know about or connect with. Mostly you will find at least three collaborative workspaces with documents and none of those standardised. Often the start of a project there is one big blurry cloud of (mis)information. The quickest, and the most fun, way is to talk to as many people as you possibly can. Explain what you are doing and what information you already have. They can point you to the right (and sometimes wrong) direction. I cannot stress the importance of an overly proactive mindset when doing something no one else seems to be doing like your in company startup or project. Maybe needless to say but the amount of people you will talk to will decline over time since you’d gathered more and more useful information.
6: Micro teams
I am a very big fan of small teams (often 3 or 5 people) without strict defined roles. I have never experienced a team of 6 or bigger even that really was as productive and effective as two teams of 3 persons. While the micro teams have no strict roles we have this assignment which is: fix everything that needs to be fixed in order to achieve the shared business goals. Small teams tend to work much more focussed and the amount of needed meetings are really low.
7: Make sure you all have the same norm
Every team member should have the same norms in regards to product and software development and on how to work together. Quality is not negotiable so proper description of functionality, automatic testing, ci, cd, proper commit messages, verifications of requirements etc are the bare minimum here. No one spends more than half a day on a problem without consulting a team member. These are our standards and we agree to honour them. I always make sure to spend some time on these subjects while starting the project and am never afraid to change them or add/remove things we think we as a team need.
8: Find team members who like to work like this
For me this is a very comfortable way of working but a lot of people, especially those who work in an enterprise, do not like it very much. They might feel better in a settled environment with two week sprints and strict defined full time roles. And that is okay. Different strokes for different folks. One of the beautiful things in life. It is just important to explain the way of working very clearly when doing intakes and specifically see if you have the same norms concerning this way of working. See if someone gets really energetic when talking about the mission you are about to go on. Because it will not be an easy smooth mission. You will need all the energy you can get.
9: Avoid enterprise agile if possible
Enterprise Agile is often something that does not comply with the essence of agile software development I think. The 10 tips of this article do not align with a ‘one way of agile working’ where every team has to work the exact same way. Personally, I often tend to start with no real defined process at all. I start with a design sprint in which all core team members and counter parts from the business participate, which is followed by sprints of one week. If we, as a team, feel that we miss something regarding the process we can easily add this. Often it is not even needed. So no PI planning, planning sprints and quarterly tribe meetings if not really needed. I avoid the ‘one way of working’ since in this case it would mean a delay of delivery.
10: Public relations
Don’t forget that people will be curious about what you are doing. There are many colleagues who will like to see you succeed and are willing to help wherever they can. There will also be people who are sceptical and who think that your way of working isn’t suitable for the company. Some will be inspired by you and your team but some will feel threatened. Your ways are not their ways. The best thing to do is share as much on your successes but also on the struggles you were in. The problems you faced. The decisions you had to make. Be honest about the things that didn’t go very well. I often create sessions in which we present our way of working, the product and where we stand at the moment. You could compare it to a demo and/or review but without the dogmatic discussion about what a review or demo should be. Everyone is invited but absolutely free to join or not. you could also use newsletters or make vlogs/blogs or create and Slack channel. Anything that can help you in sharing the things you and your team are doing.
This way of handling things formed during the past years and helped me a lot while starting something new or while doing projects. It means hard work and you will probably end up taking a lot of responsibility. Responsibility which normally other people would/should have but since the alternative means no freedom in your choices and much longer throughput you might be better off taking it yourself. And it will make you even more committed to make it a success. In fixing the stuff. Be more like Asterix and Obelix. And don’t forget that it’s not you when frustration hits but that “These Romans are crazy”. I hope I could inspire you and/or help you through writing these lessons learned down. If you have questions or need any help, please don’t hesitate and contact me.