For agile to work, it's important to evaluate how your team and your project are doing. Qualitative feedback, such as from reviews and retrospectives, can be valuable. But at some point you may need more quantitative information to improve your project. How do you decide what metrics to gather?
The upcoming Agile Development, Better Software & DevOps Conference West in Las Vegas features four incredible keynote speakers with very dissimilar but equally important topics. Lee Copeland, program chair for the conference, summarizes the keynote presentations and tells you what you can expect.
In your quest to figure out how your team is doing with its agile process, gathering data can be useful—as long as it does not add significant overhead to your project or get in the way of delivering customer value. Don't let the desire to quantify your improvement get in the way of improving.
The role of demonstration in a sprint review often takes on more importance than it should, even to the extent that some teams refer to the review as a demo. By focusing on the demo you risk having the team do all the talking, rather than a two-way conversation between the team and the stakeholders.
When adopting agile, organizations can be plagued with quality imbalance. Bob Galen found that all agile testing practices and activities can be grouped into three categories: development and test automation, software testing, and cross-functional team practices. He reviews these "pillars" of agile.
Bob Galen has noticed that when it comes to agile quality and testing practices, people tend to be either all in or under-practicing some techniques. But it is the interplay across practices that is most important for effectiveness. Here, he discusses his three pillars of agile quality and testing.
Self-organizing agile teams still need management, but they need a different kind of management from the autocratic style many teams in nonagile organizations have. A "post-heroic" leader is able to shift from an authoritative manner to a collaborative one as needed to optimize team performance.
We estimate to make decisions and to give an answer to the question, "When will this be done?" But estimation has limits, and trying to estimate too precisely in an agile project is wasteful. By driving the backlog based on priority, you can better deliver what is valuable to the business.
The classic discussion for agile estimation is about whether points or hours are better. But there is now a third option: a movement called #NoEstimates. It actually does involve estimation, but you break down work in priority order and estimate only when you know enough to estimate accurately.
Meetings are a crucial part of the communication process, but they endure a lot of ridicule. You can’t do away with them entirely—meetings are essential to an agile process like Scrum. Rather than avoiding all meetings, it’s better to work at making the times you meet with people more effective.