RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Managing an Agile Software Project : Page 3

Discover the factors that can cause an agile project to succeed--or fail.

Agile Values and Principles
Before I conclude, I would like to walk through the values and principles in the Agile Manifesto. As a manager, it is your responsibility to set the culture for your department. You must define the values and principles your department operates by, so it's important to differentiate between practices and principles. Practices can be prescribed. Scrum and XP prescribe practices. They also prescribe principles. Agile does not prescribe practices. Agile is a classification of software methods based on values and principles. The practices of XP and Scrum are examples of ways to implement agile principles.

The four values of agile software development are to emphasize:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
The Agile Manifesto places a heavy emphasis on people over tooling. Because software teams must deliver software, the teams that follow agile processes value delivering software over other artifacts that are not. . .software. These four values define an agile mindset. You can find the twelve principles of agile software development online. I would like to go through each one individually:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  2. Delivering software is the valuable service that your team provides to your customers. A status report is nice, but in the absence of working software, it is hardly a substitute. An architecture diagram is often pretty, but there is no ROI in the marketplace if users cannot use the system. You should elevate delivering software to the top of the priority list. Whatever else also has to be delivered can be delivered after the working software. We also emphasize continuous delivery of software. This means we do not do a single release. We release early and often so that the customer can use the software as it evolves.

  3. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

  4. A traditional software team might take a full year to deliver a large software project. Twelve months into the project should not be the first time the customer can change his mind. In contrast, an agile software team will demonstrate the state of the software early and often, allowing the customer to evaluate whether or not it perfectly meets their needs. The software team can incorporate any feedback early and often. If the customer has made a big mistake, the software team should be able to help the business by reacting quickly and changing direction. Failure to accurately predict the future should not be an unrecoverable mistake on the part of the customer.

  5. Deliver working software frequently, from every couple of weeks to every couple of months, but prefer shorter timescales.

  6. Prefer a short cycle time. Agile software teams deliver full releases frequently. Customers can use full releases, whether for internal use or for release to real users. The more real feedback the customer can give, the quicker the agile software team can make essential changes. Often, customers do not know what will work until they can use a software feature. As they use released features, they'll come up with ideas for improvement.

  7. Business people and developers must work together daily throughout the project.

  8. There is no substitute for humans working with other humans. Relationships between humans are the key to good working environments. Business folks and developers who do not know each other have a huge disadvantage when compared to teams where all involved see each other on a daily basis.

  9. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  10. You cannot manage software with assembly-line principles. Software is a specialized form of knowledge work, and folks on a project team need to be highly trained and experienced. You cannot swap team members out like standardized parts on the Army's M-16 assault rifle. Each team member is unique and has unique ideas. As a manager, you should motivate them and set them loose. Remove any environmental roadblocks such as inadequate tools. Give them the responsibility for delivering the project. Then give them the authority to do what is necessary.

  11. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  12. Some studies have concluded that only seven percent of communication is verbal, or in the words themselves. Tone of voice accounts for 38 percent and non-verbal clues accounts for 55 percent. Therefore, if you choose email as your only means of discussion, you are losing 93 percent of available communication bandwidth. That is no way to run a software project. Using face-to-face communication leverages the full power of communication.

  13. Working software is the primary measure of progress.

  14. There is no substitute for showing the real software to the customer. A status report has no teeth.

  15. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  16. The architecture of the software system should promote an environment where technical complexity rises linearly. In contrast, many software systems have exponential complexity graphs. This causes future changes to be more and more difficult to make. Over time, a system may become unchangeable because of its complexity. You should keep the complexity curve linear for sustained development.

  17. Continuous attention to technical excellence and good design enhances agility.

  18. Keeping the software design clean will enable you to change it as necessary. Duplication is a particularly egregious software sin. As logic gets duplicated, changes to business rules might require similar changes in multiple places. This hinders agility.

  19. Simplicity—the art of maximizing the amount of work you don't have to do—is essential.

  20. Companies often face the buy vs. build decision. Even after you have decided to build a custom software system, you also have the opportunity to purchase components as opposed to crafting every line of code yourself. A common buy vs. build decision today is to use an object-relational mapping library instead of writing every line of database access code by hand. Equally important is helping the customer simplify the proposed solution if the problem at hand can be solved with a software system of significantly less complexity. Keep everything as simple as possible. Be wary of developers who are proud of complex code. Instead, rewrite complex code, and make developers proud of simple code.

  21. The best architectures, requirements, and designs emerge from self-organizing teams.

  22. You have presumably hired good people. Put them together so they can work to refine the process. Unilaterally prescribing a rigid process will ultimately frustrate your people and will not lead to maximum throughput.

  23. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  24. Use retrospectives to discover how to become more effective. Harness the intelligence of every team member in this process.

It is not easy to manage an Agile software project. You will never know it all, so expect to be a continuous learner. Never hesitate to listen to someone who has an idea for improvement. As a manager, every good idea does not have to be yours. In fact, if every good idea is yours, you probably have some staffing problems. Always delegate authority along with responsibility, and empower your people to succeed. Reach beyond your company into the community and other parts of the industry. Share ideas, and do not be afraid to admit fault. Change immediately when you discover you are going in the wrong direction, but do not change any part of your process without evidence that it is not working. Hire and keep good people. Give them the tools and authority to succeed. Then get out of their way.

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. His company specializes in Agile coaching and helping other companies double the productivity of software teams. Jeffrey is a MCSD.NET, Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Headspring Systems is available for consulting.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date