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.
One of the practices in the Scrum methodology is the sprint. A sprint is a short time frame in which to get the most functionality in a product within the time frame.
Since we published our Digital Enterprise Shift report a few months ago I’ve been involved in quite a few conversations about “Digital strategy”. What is a Digital strategy? Is it a “one size fits all” thing? What does it mean to an organisation and its business?
When changes shock your company!
There’s a specific agile tool which I think every early-stage product team should use, regardless of whether they’re following the Lean Startup methodology. Lean Startup drew its roots from agile software development.
There are several terms used inappropriately or incorrectly in software development. In this post, I look at some of these terms and the negative consequences of misuse of these terms.
We say people over process and talk about nothing but process. We debate the merits of XP, Scrum (ala .org or alliance), kanban, SAFe, and DAD. We debate the value of specific practices. Now and then, you'll even hear someone proclaim, "If you are not doing [insert random practice], then you are not agile."
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (June 13 to June 20). This week's topics include accountability, pair programming, fitness and coding, agility as an idea and organizational structure.
Every product company wants to delight customers with a high-quality product, and many engineering organizations naturally focus on process improvements to reach quality goals. But organizational culture eats strategy and process for breakfast. So how do you create a culture of quality?
When I started my career as a software developer, there was a running joke in the company. For each level of management, we should multiply an estimation by 1.3.
When working with a team or organization, an assessment can be introduced as a tool to assist in guiding an agile transformation and team improvement. For me as a coach, it’s an invaluable mechanism to communicate the transformation strategy and to measure progress.
The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices to get even better at creating a great product.