This week I launched agilepatterns.org to help meet the challenge of enterprise scaling. In this posting I set out the rationale for doing so in terms of recent high-profile IT failures, and the need for genuine sponsorship for deep organizational change.
Lets have less talk about “The Scientific Method” and more talk about “Tidying up the Kitchen” - or is it better in French? Mise en place…. come to think of it, don’t the Lean community have Japanese word for this? Pika pika.
It’s been quite the summer for debunking widely held beliefs. Last month there was a broohaha over an article in New Yorker from Harvard academic Jill Lepore that attempted to poo poo Clayton Christensen’s widely heralded thesis from The Innovator’s Dilemma.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (July 4 to July 11.) This week's topics include scaling agile, dev of the week, the bystander effect, whether developers need degrees and kanban.
Rituals act as social glue, help pace your work, and foster discipline. Like your regular morning coffee, they give your team structure and stability in an ever changing environment.
Ok, so if software delivery isn’t like manufacturing, then what is it like? There must be some analogous model we can endlessly compare against and draw parallels with, right? Well, maybe…
In this video I answer a question about fitting into corporate culture when you come from a different background.
The phrase, “definition of done” comes out of the agile movement. But there is no reason why it needs to stay there. In fact, I would argue that many of the problems we have in the software industry are because most organizations only have one definition of done, “If we ship this today, can we make money?”
Now Kanban is not something I have practiced but for completeness of this series I wanted to write an article on it. So I have spent the last few weeks reading about what is Kanban and is it agile.
Almost all of us have worked for a company at some point in our careers that just couldn’t seem to get out of its own way. The ideas were right, the talent was strong, but the execution just wasn’t there.
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.