Video Spotlight
Agile Sponsors
Featured Whitepapers
- Learn Ways to Keep Schedules and Costs in Line With Requirements Change Management
- Java Deployments in an Enterprise Environment
- Challenges & Characteristics of Enterprise Continuous Integration
- Build Release Plans That Deliver Customer Value!
- Improving Traceability and Auditability Across the Development Lifecycle
Upcoming and Recent WebCasts
|
| Another lesson I learned from my home renovation project is that while you can follow the steps of an agile process and still not be agile. The people on the team need to want the process to work.
It's been a while since I've posted here, in part because life has been busy with the birth of a child and moving in to the newly renovated house. I did learn some things during the past months that I hope are worth sharing here. As I mentioned in my last post the renovation project didn't finish as well as it started. I initially thought that the problem was that we had not followed the process correctly; We didn't meet frequently enough and we didn't work off of a list, and we never set short term expectations for what would and would not get done. A short while after the contractor was mostly done with the project I discovered that things were worse than I thought when I received a surprise bill for "extra" work that was done months before. Given all of our communication and availability (towards the end we saw the contractor almost every day) how was it possible that we had such different expectations about the state of the project? I realized that the problem was deeper than simply not having the right number or kinds of meetings, or even having the right agreement (our contract stated that extra work needed to be approved in writing in advance). The problem was that the contractor didn't buy in to the idea that he had to be direct and honest about what he expected so that we could react. In other words, he had to actually participate in our collaboration for it to be successful. This would not be terribly interesting to software developers except for the fact that I've seen the same problem on Agile teams: the team follows all of the steps but there is someone (or more than one) who goes through the motions of the agile process, yet he holds back the team. I've been thinking about how to work with people like that. The good news is that following the process lets you detect who "gets" agile and who doesn't. If you have a daily scrum and you listen to when people share what they are working on, you will realize if people are working on things that are not on the backlog. When checking up on this you need to be careful not to change the tone of the scrum from "sharing" to "status reporting" however. Once you figure out that someone isn't keeping to the spirit (either not really sharing progress, or doing something else) you need to figure out:
If the issue is one of the first two coaching can help. If the problem is the latter then you have to decide:
Set as favorite
Bookmark
Email this
Hits: 3577 Comments (0)
|
| Next > |
|---|
Agile Marketplace - Announcements and Special Offers
Webcast: Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!
Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial
Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper
PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now

