In 2007, when I was introduced to the concept of eXtreme Programming (XP), our team was ultimately able to achieve zero-defect deliveries. When I think about what enabled us to achieve this, I can offer the following thoughts.
Have you ever wondered why some Scrum teams perform well and others don't, even though they're all cross-functional teams with motivated, T-shaped people?
Do we suffer from an overreliance on tools -- one that distracts us from an important concept in the Agile Manifesto?
Stop trying to document every single risk, issue, assumption, dependency, and task milestone that could ever impact a project, and start actively managing the main, most important risks across teams.
Putting together a good Scrum team is not easy. Sometimes people aren't able to perform optimally as team members, and there are a variety of possible causes. Here are some of the most common that I have run across.
Are your Scrum teams worried that they've achieved less (in story points) in the current sprint? Are you worried about velocity going down?
Continuous integration is an important process for protecting against build errors and code breakage. Here is how we achieved it.
How do we actually come up with innovative ideas? Here are nine practices I follow.
Agile facilitates perfection through adaptation, and adaptation is enabled through feedback. Retrospective feedback becomes, in fact, proactive.
It's not a good idea to map each story point to working hours; it conflicts with the reason for using story points. To solve our problem, we can nonetheless do something similar. The solution is to not model the story points in detail but to define them at a higher level and in a reverse way.
I recently asked myself whether our Scrum education system is functioning well. Do we simply tell our trainees what to do in a given situation and then make them look for help the moment the situation changes?
What I want for my team is to become Agile. I want us to approach problems together with all of our different backgrounds, education, and experiences. This leads me to think that I could use the Candle Problem to illustrate this initiative.
Small incidents in my personal life always help me improve my work with Agile teams. I recently learned lessons from an incident with my car and its warning lights.
Building actuarial models is a challenge usually approached via Waterfall -- and such projects suffer from the same issues software development projects face when managed this way. Therefore, we tried implementing Scrum for a recent actuarial modeling project.
I believe that to succeed at anything personally or professionally, leadership is required. And in most companies, to take the lead you must change the corporate culture, but culture is a tricky and difficult thing to change.
How a function point (FP) estimation method helped our Scrum teams overcome challenges in managing metrics, governance, and service-level agreements.
Working in different companies, it was always difficult to convince my reporting managers, who have a strong connection to the traditional Waterfall approach, about tying the calendar dates of my delivery plan to important milestones. . . .
Even as an experienced Agile coach, I recognize that uncertainties surround the practice of estimating user stories by using man-hours or story points. Here I'll try to come to my own conclusion.
To successfully scale Agile in an organization requires a balance between securing alignment from other functional areas and coordinating cross-team activities.
Burn-down charts are one among the important metrics that help senior management gain insight into the current status of the team. Can they be used to replace status reports?