This blog post is for those of you who are unaware that there is a major debate in contemporary software development happening now, today. People have been wondering about the value of Test-Driven Development (TDD) for a long while
If you are near the Boston area, this Thursday, July 10, and want to see some sparks fly—or at least engage in lively debate—come to the Agile New England meeting July 10.
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 James Betteley, London-based build and release engineer, rugby player, and cyclist.
What I am going to say is radical – this will put you outside your comfort zone and challenge your thinking. I will share the how, the why and the benefits.
One of the most significant books on startups, defines startup as temporary organization aims to find sustainable business idea. It’s not about coding, testing or anything related to development. It’s all about the search.
Just because you have a college degree doesn’t mean you have learned anything. That is the main problem I have with most traditional education programs today. School has become much more about getting a degree—a piece of paper—than it has about actually learning something of value.
But for me as a developer there seems to be a wall around our team. Behind this wall the management dragons roam. Sometimes balls of flame fly over the wall in our direction, setting our little project on fire, by dictating rules that just don’t make sense, and we can do nothing but putting out the flames, or can we?
Resisting the temptation to implement a story is very hard for a dev team – it is all too easy to get carried away in introducing a new idea as a reusable asset.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (June 27 to July 4). This week's topics include pair programming, agile vs. real life, collective ownership, product owners and the pursuit of empowerment.
The Agile Culture is a must-read book for anyone in I.T. management whose organization is struggling with transforming their organization from the classical waterfall software methodology to an agile methodology.
Recently I’ve been butting heads with some people on the subject of Ownership, Responsibility and Accountability. There seems to be a very unhealthy obsession with these things sometimes, and I think this is indicative of a less-than-ideal culture.
Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.
One of the familiar tensions in management is how you encourage or discourage people from bringing you problems. One of my clients had a favorite saying, “Don’t bring me problems. Bring me solutions.”
"We have come to value “Individuals and Interaction over Processes and Tools”," but reality tells us otherwise.
I started out this blog post writing about shared accountability for agile program teams. Accountability is an interesting, large topic that gets skipped over quite often in our agile community. In fact, I found in my writing a realization that we don’t have a great track record for defining it. So here’s my take.
Frequently in peoples’ careers, ascension to the ranks of middle management is rapid. But then something happens. A small number of people break through, but the majority of folks seem to reach those middle tiers and then stall out.
But the moral of the story is: handovers are hard. And essential. And worse, often the person doing the handing over is doing so because they’re short on time and, for whatever reason, not responsible for the next phase of the project.
Blogger Michael O. Church wrote a comprehensive post about the culture of programmers in Agile environments, particularly with respect to arbitrary or non-external deadlines.
Most product owners I’ve seen in the videogame industry are much closer to project managers than business owners. Their primary job is often the coordination, planning, and prioritization of the cross-team dependencies that the scaled-up nature of game development tends to create.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (June 20 to June 27). This week's topics include software development terminology, lean startup tools, sprints, estimates and dealing with kids.
One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others.
When my kids were young, my wife introduced a concept for this question that she got from her family that is so brilliant in its simplicity that I wonder that this isn’t common knowledge with all parents. Something they should tell you during Lamaze class.
There’s a problem with the assumption that we can “know” stuff. We can’t know stuff about the future. Guessing, or estimating, as we call it is the current alternative. To improve, we can at most try to forecast.
We’ve all had incompetent colleagues. People that tend to write bad code, make bad decisions or just can’t understand some of the concepts in the project(s). And it’s never trivial to handle this scenario.
In the latest of a series of posts examining Agile adoption in organizations and businesses, blogger Suzanne Miller takes a look at specific Agile practices and how they can be evaluated. She mostly talks about governmental organizations, but the evaluations are valuable for all organizations.