|
Henry Ford: Master of Lean Agile Processes Henry Ford, founder of the Ford Motor Company, was a captain of industry who revolutionized production. He also was one of the greatest influencers of the processes we call lean and kanban today. John Yorke believes Ford's ideas about process improvement made him a pioneer for systems thinking and agile software development.
|
|
|
Prevent Disaster by Righting Cultural Dysfunction on Your Team The space shuttles Challenger and Columbia were two of NASA's biggest disasters. Investigations into these accidents discovered the engineering issues responsible, but management practices and cultural barriers also were found to be contributing factors. Does your organization have a healthy culture that lets you safely voice concerns? It could help you prevent tragedy.
|
|
|
For Agile to Succeed, Put People First There’s a lot of buzz in the agile world today about becoming more technical, automating everything, and learning the next miracle tool. While it’s important to establish a process, and tools can help with many steps of the software development lifecycle, the human contribution to project delivery is still the most important. Here are some qualities agile teams should encourage.
|
|
|
Endgame Testing: Exploring Your Agile Product End to End The main goal of endgame testing is to test the system end to end from the user's perspective. This should ensure continuity between components developed by different teams, continuity in user experience, and successful integration of new features. Endgame testing will often identify gaps that are difficult to discover inside agile teams, including flows across the product.
|
|
|
Slim Down Your Test Plan Documentation Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.
|
|
|
Has Continuous Deployment Become a New Worst Practice? Software development has been moving toward progressively smaller and faster development cycles, and continuous integration and continuous deployment are compressing delivery times even further. But is this actually good for businesses or their users? Just because you can deploy to production quickly and frequently, should you?
|
|
|
Paying Off the Technical Debt in Your Agile Projects Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.
|
|
|
Are You Agile? An Assessment Can Tell You Plenty of companies want to be agile and go through the motions but are not really agile. An agile assessment allows you to evaluate how teams or even organizations are doing in their agile journey. But like any useful tool, there is no shortage of assessment options available. Here are the acceptance criteria to look for and a framework for using an agile assessment.
|
|
|
Code Health Kaizen: Self-Organizing for Agile Improvement People at Ben Kopel's organization were interested in improving their code health. It was something the engineers had control over and leadership didn't need to be involved, so code health was a great candidate for a self-organized initiative. Ben details the meeting they held, their discussions and plans, and how an agile team empowered themselves to improve.
|
|
|
How Businesses Stay Agile: The Art of Being Retrospective The greatest use for agile in business is in changing how you tackle problems and projects. Rather than defining the whole project and setting a “way forward,” an agile approach takes things much more iteratively. That means meeting as a team on a frequent and regular basis to share problems and successes, then making improvements as needed—being retrospective.
|
|