I've spent the last few weeks trying to write a blog post about why Agile software development is inherently more difficult for games than other software. I came up with reasons that are purely circumstantial, rooted in business models and development environments. Nonetheless, it is the situation we are in; the good news is, we can change it.
It was over ten years ago that Agile was introduced to the development world. In that time, the development methodology has found great success. But Agile's short programming cycles often promote a common question: What about the long-term focus of a project or product?
Rarely do I encounter someone in this industry who openly acknowledges being overpaid, but when it happens the conversation is not what you might expect.
Last year Google announced they would no longer provide a 'downloads' feature on google code hosting for new projects. Starting January 15th 2014, creating new downloads would also no longer be possible for existing projects.
One of the key reasons scrum and agile have become increasingly popular is that Agile enables you to get to market faster. Faster time to market changes the game.
We all know people who are energizing to talk to. Whatever the topic, they are full of energy. They make ideas better. Moods improve when they are around. And there are people who fall into the opposite camp.
I believe that many of us are solving a problem we think our customers have. We might even be trying to solve a problem our customers really do have. The challenge is that our customers don’t always see it that way.
I often wonder how projects fail to be agile enough even though the team consists of talented team members. So today I am planning to summarize a few points that are the biggest hindrances to being agile in a team-based environment.
It’s not too much of a stretch to say that hedge funds are a new type of Software Company. After all, they have more developers per capita than the latter, and they generate more cash flow per capita, if they are any good.
When releasing a new product, the first step is to find product customer fit quickly. The minimum viable product (MVP) encompasses the essence of the Lean Startup ethos. An MVP helps go through one cycle of the Build-Measure-Learn loop. Lean Startup author Eric Reis warns “Customers don’t care how long something takes to build. They only care if it serves their needs.”
Even though the industry is thirteen years removed from the initial introduction of the Agile Manifesto, the word "Agile" is still a hot topic. "Does it really make things better?" is a common outsider's question. "Try" can be a powerful word in the hands of a mature team.
It appears that beer has the quality that makes it a secret productivity booster, which is never advertised as such, but rather taken jokingly. Heh, you weird programmers, who can create something useful while drinking beer? That’s what an ordinary human might think.
I am struggling with my stakeholders and product owner on a discussion that how and what kind of features should be inside product roadmap for this year implementation. As soon as I saw it, I noticed something is missing. The most important missing element is agile spirit.
It’s about time to nag the product owner, isn’t it? Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:
All seasoned programmers have lived through and can tell the tale of the lost project. Some of these projects were conscious decisions while others were secret skunk projects.
Recently I was part of a "Daily Scrum Meeting" in a reputed product development company. Being a huge fan of Agile and a committed practitioner, it was concerning that people were actually adopting it the wrong way. In this blog post, I will share some lessons learned from this meeting.
A person willing to be a great developer should consider a bug as a threat to his position, as a threat to his credibility, as a threat to his programming skills. That is the attitude that will make him/her a great developer.
No doubt, if you are just starting out as a programmer, you have already experienced how difficult it can be to get a job without having much or any experience.
I’m suggesting that most companies have a core infrastructure that is fundamentally predictive-convergent. Using adaptive-emergent techniques, language, methodology and tools is fundamentally destined to fail in predictive-converegent companies. It’s not that agile can’t be adapted or scaled to work in these predictive-converegent companies, it’s just that it requires a different language and approach.
Organizations increasingly face the challenge of how to strengthen employee engagement while their workforce increasingly work from remote locations or while mobile. There is a great opportunity for internal communications to take a leading role with developing a plan that addresses these challenges with greater use of communications channels.
In full disclosure, I'm writing this as a "Chief" Architect (I can't help but picture a big headdress), and I've spent the majority of my career as an "architect" (note the air quotes).
By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Ralf Quebbemann, Java developer with a special focus on Maven, and a dedicated Blues guitarist. Some of his most recent DZone contributions include:
Starting with the control/data plane concept, I broke apart the cloud into multiple planes and then focused on how the layers would communicate to enable a cloud management platform that inherently scaled in and out as well as up and down.
Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic have a look at the 10 things a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go: