What is agile?
Agile is often misunderstood. Agile (with a capital A) is a group of methodologies including Scrum, Kanban and XP. But can you still be “agile” (little “a”) without using a specific Agile methodology? The answer is yes and there is a just as much value in being “agile” as doing “Agile”. So what does it mean to truly be agile?
On Being Agile
The agile manifesto lists 12 key principles (http://agilemanifesto.org/principles.html). Let’s examine these one by one.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. An agile company remembers the end user is the reason for building the product in the first place. Early delivery allows for customer feedback. Customers often can’t articulate fully what they want, but they can sure tell you what they don’t want! Getting your product in front of the customer as early as possible is key to starting discussions about requirements. Development teams often think they understand requirements and what customers want but too many projects have delivered software only to find they missed the mark in what the customer wanted. This could have easily been avoided by showing the business users the product before it was finished. This leads to point #2.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Change happens. Anyone involved in building a product (especially software) will tell you the customers’ needs change as a result of a change in sponsor, subject matter experts, process, organizational strategy, or regulations. What is important is that we continue to iterate the product until the customer is satisfied. If this is a product going to market, this will result in higher adoption rates, higher customer satisfaction, and potentially a higher sales price. Where we struggle with this is when 3rd parties are involved. If organization is building a product and charging the customer for the build (or conversely being charged by a 3rd party who is building software for use by the organization) contracts come into play. Generally these contracts have been negotiated as fixed price contracts leading the two organizations to argue about who is going to bear the cost of the changes. It is important that a contract is negotiated with agile in mind. A time and materials contract is perfect for an agile project – and while most organizations are put off by this type of contract, studies have repeatedly shown it is the most cost effective type of contract as flat rate contracts are padded to ensure the seller doesn’t lose money on the transaction. The advantage to the purchaser is they can cancel at any time and walk away with a working product (albeit less functional than they desire).
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. The environment is constantly changing yet the product being developed often stays static and requirements are not adjusted in response to the changing environment. By delivering working software and providing value early on, teams are able to pivot to changes in the market or deliver early should it be necessary.
- Business people and developers must work together daily throughout the project.
Have you heard of “Together Everyone Achieves More = TEAM”? Working as a team means breaking down barriers, communicating regularly, listening and responding to others needs. By meeting every day (even for just a few minutes) and by co-working team members are always ready to lend a hand, brainstorm and work collectively to solve problems. Who better to be on the team than the business people who know the problem, know the users and know the market/environment where the product will function. By working together daily, the developers have no excuse for not seeking clarification, asking questions and showing what they are building while they are building it. On the business side, by listening to conversations and watching what is being built, business people can easily correct a product going in the wrong direction or an assumption. Business people are great at product testing and product design, why wouldn’t you want them on your team?
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. At the heart of this statement is the belief that everyone wants to do a good job and help others. Nobody tries to build a bad product on purpose or waste everyones times with rework. It isn’t necessary to micro-manage your team if you allow them to make and own their own plan. Regular demonstrations of the product allow you (as the manager) to review their progress and tools like burn up/down charts allow you to estimate when the product is going to be complete (or provide sufficient value). The team will tell you what they need to get the job done – whether it’s tools or pizza.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Have you ever sent an email that was misunderstood by the recipient? I think we’ve all done this. So much is lost in the written word. It is a unilateral communication. There is no option to clarify by asking questions, and the sender receives no feedback to indicate whether the receiver understands (no eye roll, no look of puzzlement, no quizzical brow). In a face to face conversation, the receiver gets an opportunity to ask questions, reiterate the message and nod to indicate an understanding. Nowadays there is no excuse for not having a face to face conversation. If the team isn’t co-located (meaning at the same location) then Skype, Google Hangouts, FaceTime etc can facilitate a common understanding. The biggest barrier may now be time zones, with offshore outsourcing, the team may find they are working different hours. Take this into consideration before offshoring – set up a time each day where the team can meet to ask questions and check in with each other. If this cannot be done, think carefully before proceeding – the money saved by outsourcing will be lost if the requirements are misunderstood and the wrong product is built.
- Working software is the primary measure of progress. In traditional software or product development, requirements are gathered before design, design completed before build. Masses of documentation is generated early in the project. But if the project budget is reduced the team has nothing to show for their effort other than documentation, whether requirements or design. These have no value to the customer. In fact in most software projects there is no value to the customer until right at the end of the project. Even during the build or test cycle, the product is still incomplete, may be full of bugs and simply is unusable by the customer. I suggest it is better to produce something small, start to finish, that provides value to the customer. This quick win can do wonders for your project. The customer is happy, may be willing to pay for it (great for cashflow), and can give you feedback into which direction the product should go next. Everyone wins.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The team needs to be able to keep up. They should only take on as much work as they can reasonable get completed before the next meeting with the user/client. No late nights or weekends on a regular basis or the team will burn out, become unhappy, create turnover, or create errors. Nobody wins if this happens. Have the team commit to what they feel comfortable with – no more. If they accomplish what they committed to then everyone is happy and the team becomes more confident.
- Continuous attention to technical excellence and good design enhances agility. In general terms, aim for reusability, think about how easy it is for new team members to join your team and catch up on the project. For software teams, well formatted code, normalization of data, reusable code, rework, in line documentation, design patterns – will all enhance your team’s agility.
- Simplicity–the art of maximizing the amount of work not done–is essential. The 80:20 rule (Pareto principle) suggests that 80% of the value is delivered after the first 20% of the product is developed. By taking the product to market the business is able to start receiving a return on its investment long before the product is “finished”. There may be no point in spending the last 80% of the project trying to attain the last 20% ROI. Additionally, by keeping the product simpler, future testing and re-factoring are easier, the end-user is likely to have a better experience as the product is easier to learn.
- The best architectures, requirements, and designs emerge from self-organizing teams. Self-organized teams learn how to think for themselves and how to work together to solve problems. Teams that require someone else to organize them often rely on that same someone to solve their problems, come up with designs and basically “spoon-feed” them. Why not teach your team to fish instead of feeding them fish?
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. In relation to #5, periodically give your team opportunity to tell you how they could be more efficient or improve quality and then help them implement their idea. Sometimes this is simply a process change within their control but sometimes this requires outside intervention such as co-location, equipment or other corporate policy changes.
In summary being agile means being able to respond to the needs of the customer quickly, whether these are driven by the outside environment, market conditions or the organization. Agility is a way of being – it’s a behaviour based on a team’s mindset and not a methodology. Any team can be agile whether or not they are doing “Agile”.