Managing projects successfully is so often about striking the right balance! Deciding how much we take on; where to apply our precious time and brain cells during each project; and how to balance our need to organize the work with the fact that so much is uncertain. Three of our experts weigh in this week on the testing shortfalls that moving to Agile can actually highlight; the tough conversations required to have any chance of reducing that ridiculously long project list; and ways to achieve a meaningful, evolving plan via a practical planning process.
When Agile Developers Test Well [and why it Matters]
by Alan Koch
When we were riding our software development barrels over waterfalls, how well we tested was not a terribly big issue. Insufficient developer testing contributed to the ills we experienced, but it was only one of many contributors -- and certainly not the biggest one.
As we become more Agile, we strip away those things that contribute to the pain of the waterfall: We replace big bang development with iterative development. We replace up-front predictive planning with adaptive incremental planning. We replace massive signed-off Requirements Specifications and painful change control with a progressive refinement of our understanding of customer value. And we draw our distant customer with U-shaped involvement (high at the beginning and end of the project but low in the middle) into a continuous dialog.
As the whole development process becomes more efficient and Agile, any lack of discipline with which developers approach testing becomes more and more obvious -- and painful to the project overall. We can't satisfy our customer with crappy code. And we can't move forward when we're constantly going backward to fix defects.
So how should the testing part of your Agile project look, to ensure you realize the benefits of Agile, without simply shifting to a different source of rework and delays?
Read Alan's detailed advice
Strategy and Delivering the Right Thing
by Kent McDonald
Have you ever worked for an organization that has too many projects? The situation is usually characterized by endless discussions of how long this particular project will really take, whether the hero project manager can take on one more project, and how you could implement the newest, shiniest methodology to "leverage the synergies in your over-allocated resources" (translation: burn out your employees).
Not all projects deserve to exist. An organization's strategy is supposed to guide what projects get the go-ahead. The strategy needs to be simple, useful, known, and understood. Once it meets those criteria, you can use it to improve the chances of delivering the right things, assuming you are willing to have some tough conversations once in a while. Read how to have the hard conversations about whether your project is a necessity or an organizational distraction.
Spotlight – Other Project Templates, Tools, and Techniques
Planning is a Process, Not an Outcome
The project schedule is the most recognized project management artifact. Stakeholders embrace the schedule as a sacred covenant with the team. In reality, project plans are just the best approximation of the (often very uncertain) future based on today's limited knowledge and information. But a typical schedule format with lots of tasks and dependencies can unfortunately can give the illusion of precision and set-in-concrete accuracy that just isn't so. So how we handle the process of planning is critical -- to continually ensure our plans are realistic and meaningful, and that "the published plan" at any point time is interpreted appropriately! Here are Alan Zucker's 6 tips for improving the planning process to work well despite typical project uncertainty.
[BLOG] What matters most in planning and scheduling?
[BOOK EXCERPT] Scrappy PM - "Why Plan? Let's Just Get Moving!"
[TEMPLATE] Agile Technique Brief: Agile Planning
[BURNING QUESTION] How do I get estimates from people when the work is uncertain?
Agile Method Brief – Feature Driven Development (FDD) – SPECIAL
This Premium resource is free to registered Members until June 16, 2016
Feature Driven Development is useful because it demonstrates that you can focus on domain modeling on an iterative and incremental project, and because it demonstrates that agile-like methodologies can scale. FDD shows that teams can spend a short amount of time at the beginning of the project to establish a clear understanding of the domain in which they are working and use that understanding to formulate a rough plan without getting stuck in analysis and design paralysis.
Get the Template »
Corporate Subscriptions and Licensing
Want your team members to have their own access to templates and how-to resources for their project work? Need to share documents and deliverables beyond your project team? We make it easier with affordable corporate subscriptions and licensing. Detailed information regarding corporate options is available online. Give your whole team, or even the entire organization, cost-effective access to our comprehensive online library of resources. You already know how helpful it's been for you. Now it's time to share with everyone else. Find out more »
Not sure if corporate terms apply to you? Check out our licensing terms at the top of our Terms of Service page, in refreshingly ordinary, everyday English.