A while back I wrote that crowdfunding can be a distraction to startups from working on their products. While I still believe that, one of my clients have shown me that the two can be put together to create a community of people who passionately care about your product and are investing their time and ideas (beyond the $10 or $50 or whatever amount they contribute) in helping you deliver an outstanding experience.
“We don’t have much custom development,” said Pam, the IT manager at a small manufacturing shop in the cosmetics industry, “and we mostly do integrations with our ERP. There is no need for a staging environment.”
“We hire the best developers and our code is fully unit tested,” says Rupmeet, who manages a team of seven developers working on an analytics product in the cloud, “thus we don’t have problems deploying directly in production.”
There is a lot of emphasis on reducing waste in Lean but one aspect that is as important, if not more, is the drive for continuous learning. So much so that I think that “lean” is a misnomer for a process that fosters a culture where kaizen is the highest order of emergence in the organization that successfully adopt it.
Few years ago, I came to a personal realization that learning is what makes my life worth living (alongside with my family and friends). At the time I wrote an article in which I declared “I learn for a living!” and threw away measurements putting my skills against some kind of grading scale – I realized that such scales turn my goal into a race for an award represented into a grade and take away the intrinsic motivation I feel when I push myself to learn something for the sake of learning and the sense of mastery that follows.
Openness to ideas, collaboration, communication. These are some of the things one of the agile teams I am coaching values and likes to keep doing. They’re valued equally as tracking issue in Github, regular refactoring of their application framework throughout the sprints or fixing bad coding practices.
In last week’s article, I have argued that most software code is at what I called maturity level 1-3 and only those teams that practice coding as a deliberate discipline achieve level 4. At this level they are controlling every aspect of their deployment, like configuring the application, managing shared libraries and third-party dependencies, deploying or migrating their database, etc. They are also taking advantage of scripted builds, continuous integration and automated testing, which are pre-requisites for successful adoption of agile and lean methodologies.
But there are two more levels (and maybe more can be achieved through innovation) that are pushing the limits of what is possible with code. Arguably, these levels are only possible thanks to advances in virtualization and cloud technologies and may be beyond reach for certain type of software products that have to deal with traditional infrastructure or where the maturity of the tools available is making it harder to go beyond level 4. (Those projects are possibly limited more by tradition and mindset than tools, though.)
I am often asked to give advice on the most important processes a software team needs to implement for managing their code. The discussion usually moves from version control, to branching and merging strategies, unit testing, code reviews, static code analysis, build automation, continuous integration, test automation, code coverage, stress testing, etc. But one aspect I find as important as all of the items above is the scope your code controls. That is, how many things sit outside your codeline and how can you ensure your code is complete.
When you think of code, what comes to mind first? The lines that define your application features I presume. But those features don’t come into life in a vacuum, solely from your code — unless you’re coding The Matrix that is
I recently learned that a local software development company decided to implement Agile “properly” and in the process let go everyone with any process knowledge of experience. “Dev will do it themselves” was the message these people got at the door.
(If anyone is in need of good people with experience related to product or project management and delivery, customer engagement and similar email me at firstname.lastname@example.org to put you in touch with few I know very well.)
While advising a client how to properly implement agile methodologies like scrum recently, I was talking about the importance of automation to their team and mentioned that automation starts with standardization. What I meant was that to reduce the cost of automation they need to standardize the platforms and technologies they use for development and production. The reaction from their people got me thinking. Their response was ‘Are you saying we should ask everyone to use only one programming language? We are a small company and we have been trying to attract talent by letting them choose the best technology they think will help them do their work.’
Operating Dev came about as an idea inspired by DevOps, which aims to bring software development and information technology closer. While the definition of DevOps may still need clarification, a major focus of this blog will be on the gap that DevOps is trying to fill in – the disconnect between software development and IT operations. I would like to use this blog to discuss DevOps and additional related practices and methodologies in an attempt to share some of my learning with other people and get feedback from the readers.