A hallmark of lightweight software development methods is the notion of emergent design. The idea is that the design of the solution will emerge little by little as we build up the code in small increments, typically using test-driven development with very short red-green-refactor cycles. When it goes well, we avoid a number of problems. We won’t create a comprehensive design and write a lot of code that only leads us down a rabbit hole that’s hard to climb back out of. We won’t get carried away with our natural creativity and over-engineer the thing way beyond what our customers want…

Backlogs, Teams, and Working Tested Software are the fundamental preconditions that must exist for an organization to be able to do agile well. In agile these three things have very specific meanings. Compromising on the quality of the backlog, the completeness of the team or the definition of working tested software always decreases agility. Backlogs Most organizations underestimate the amount of time and energy it takes to create backlogs with the needed level of granularity. User stories written in a consistent format 1-3 days in size Agreement on method of collaboration Teams Teams that don’t stay together and aren’t able…

A year ago, your organization adopted the Scrum framework. Scrum helped you break down functional silos, improve communication with stakeholders, increase collaboration on your team and across teams, and facilitate cross-disciplinary skill development among staff members. It was exciting at first. Everyone was engaged and everyone was enthusiastic. Stable teams were established, and work was allocated to teams as deliverables were completed. People began to spend their days in team spaces designed as collaborative work centers, rather than sequestered in cubicles like so many hermits. In every Sprint, teams built trust with stakeholders and learned more about the business domain…

A truly Agile organization will always have these three things in place: Cross-functional teams Clearly articulated backlogs The ability to produce incremental, working, tested software. Anything that gets in the way of making these three things a reality is considered an impediment and removing the impediments is the work of an Agile Transformation. Mike and Dennis delve deeper into this topic in our latest vlog post.  

I’ve recently heard challenges to the validity of the product owner role’s relevance.  Given that we “don’t know what the product needs to do up front” and we encourage teams to collaborate to detect “what the product needs to do” during the process, why do we need product owners? I believe this challenge is one that makes sense deep within the process and the team – when looking at what the team is doing, from one sprint to the next.  However, I challenge the premise of the argument – but to do that, I need to shift your context from…