Not all Agile implementations are done well. How can you tell that your team has done it right? Here are Gleb Bryksin’s six signs that a company has a successful Agile process.
Do agile and DevOps really go hand in hand in the real world? Can an agile transition be considered successful without DevOps? What do we need to understand about agile and DevOps? These are just a few questions that have remained unanswered. We talked to Zubin Irani, CEO at cPrime, a full-service consultancy that implements agile transformations and delivers agile solutions, about the importance of agile in today’s tech environment and what it means to be fully agile.
When the forefathers of Agile met to write the manifesto that provides the guiding principles of Agile software development, Wikipedia was just formed, the iPod hadn’t launched, and the first versions of IntelliJ IDEA and Eclipse were in beta. The principles of Agile have not changed. More than ever, we strive to satisfy the customer through early and continuous delivery of valuable software.
Each person has their own beliefs about technical debt, but the whole discussion can be summed up in only a few words: new technical debt is good and old technical debt is bad. “If only it were that easy,” some insinuate.
The same marketing hype that surrounded “Agile” has now switched to “DevOps”; the combination of the two is one way to solve all the issues that IT organizations have been known for. This has generated the chimera of the “full stack” developer, which simply means that now a developer is expected to do it all. What else could it mean?
In the sixth part of his common sense software engineering series, blogger Steve Naidamast gives us a valuable lesson: although many technical managers avoid using Function Point Analysis, this gem is one of the primary foundations in actual software engineering for developing accurate and sustainable project timelines.
Surely you’ve heard of the term Technical Debt something you incur when you don’t invest in a clean code basis from the very start. With time, hastily pounded out code becomes more and more complex and difficult to maintain, it no longer scales, etc., such that costs escalate disproportionately.
After some experimentation, Tomas Rybing is back with another visualisation for teams using the Kanban method. He’s cut the top off of his Priority Pyramid and created The Volcano, which covers bigger teams and more products.
In Part IV of his ongoing series on common sense software engineering, blogger Steve Naidamast shares some wisdom he’s accumulated regarding agile methodologies. Newsflash for the young guns out there: what you’re doing isn’t new or revolutionary.
Spotify’s famously engineered agile practices have become the stuff of lean legend. The company is growing at a rapid rate and continues to employ its unique brand of agile methodology, which is intricately linked to its organic organisational culture.
No concept is more complex and nebulous to a software developer than the one that is suggested by the word “done”. Is there such a thing as a finish line in IT? And if so, what exact requirements should a programmer need to fulfil in order to cross it?
In the third part of his common sense software engineering series, blogger Steve Naidamast takes us through risk analysis and the techniques you’ll need to estimate risk exposure, including a handy a risk exposure calculation.
The Waterfall method is still a process worth considering – a bold statement from blogger Steve Naidamast in his second essay on common sense software engineering, where he talks us through the need for good Requirements Analysis.
Thinking of code as a beautiful work of art is a mistake. But at the same time we need to start seeing coding as a genuine skill that deserves professional recognition, says leading Software Craftsmanship advocate and JAX London speaker Sandro Mancuso.