Agile Principles in Action
There are many people who think that using a set of specific practices will make their teams Agile. As discussed in our previous article on the Agile values, this belief is incorrect. Over the years we have come to realize that agile is really a mindset – a way of thinking differently about software development. Incorporating sprints, user stories, daily stand-ups, and other process-related practices can still lead to failure unless we also change the way we think.
The simplicity of Agile – the Agile Manifesto’s four values and twelve principles – can sometimes mask the challenge of learning to think and behave differently. A culture of agility means embracing ideas that many of us are uncomfortable with, or even fear.
Here is what the Agile Principles mean to me.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Some of us in IT have forgotten that the primary goal of software development is the development and delivery of software; the end goal is not documentation or project plans. Agile development doesn’t force our customers to wait months before software can be seen – we show working software after every sprint – often every two weeks. Then, two weeks later more working software is delivered. Continuous delivery of software allows for quicker feedback from stakeholders, which gives better visibility into the development process, and results in software that is more satisfying to our customers.
The last part of this principle states “…delivery of valuable software.” One of the keys to Agile success is that we are always working on what the Product Owner considers the highest value features. Business value is determined through stakeholder collaboration, and then the Product Backlog is groomed/refined, prioritized and ranked so the team always knows what is most important. This loop of delivering software, obtaining quick feedback, refining the backlog, then repeating the process helps us deliver high value quickly and continuously.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. A reality of most software development is that requirements change often. Market conditions change, technologies change, stakeholders change their minds or come up with better ideas and the list goes on and on. Traditional software development often takes a change management approach to reduce scope creep, which can result in “change prevention”. Agile development welcomes change and treats it equally by putting changes into the product backlog where they are prioritized and ranked among the other user stories. Late arriving, high priority requirements that are quickly developed and deployed to production could potentially deliver a competitive edge. Why wouldn’t we want to incorporate these better ideas into our software?
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequent delivery of working software allows stakeholders to see their user stories come to life and offers short feedback cycles. These short iterations of delivery and feedback help ensure that what is being developed is truly what the stakeholders want. Frequent software delivery also provides high visibility and transparency into the project as everyone is aware of what has or has not been developed to date. Finally, short delivery and feedback cycles reduce project risk because stakeholders can change direction more quickly if a feature is deemed unnecessary, or a feature with higher value is discovered. The days of development teams being handed requirements and going away for six months before showing working code are over – at least in an Agile environment.
Business people and developers must work together daily throughout the project. A key to the success of Agile development is active stakeholder participation. When we interact with someone daily, we form a better relationship with them, we understand each other better, we tend to ask more questions, and we make decisions that are more mutually beneficial. Frequent interaction with someone helps ensure we’re continually on their mind – we’re on their front burner, not their back burner. The greater the physical distance, or the greater the time between contact with someone, the less likely we are to engage with them.
There is increased risk when we develop something or make a decisions solely on our own. Agile reduces this risk by providing frequent opportunities for people to collaborate and challenge each other. Agile development is successful in large part when developers and business people are constantly discussing and understanding needs, and then delivering valuable software that meets those needs.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Another key to Agile success is having teams of skilled professionals who care about the product they’re developing, and who are willing to learn from each other. They have the humility to respect each other and ask questions, and realize that people are a primary success factor in software development. They take pride in the quality of their work, refuse to be blocked, and give their best effort. Motivated, skilled teams don’t need babysitting, and management doesn’t need to spend time coaxing them to perform. They perform because they are professionals who were given a clear vision of where to go, they were given the right tools to get the job done, and they were given the trust and freedom to succeed.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. When it comes to effective communication, nothing beats a face-to-face conversation. Face-to-face discussion shortens the time between a question and its answer, and helps avoid miscommunication. When we communicate via email, instant messaging or even phone, we can’t see the recipients’ facial expressions or body language – we don’t see their eyes roll, or see them crossing their arms in a defensive posture. Agile teams often sit together to make it easier to ask questions and offer suggestions. When we need to talk about something, we’re right there – together, and we tend to go ahead and ask instead of putting it off, or forgetting about it, or diluting the message with an email. Each time you consider emailing someone who sits near you – STOP. Instead, go have a face-to-face conversation. Over the course of weeks or months you’ll be amazed at the time savings and how much more effective your communications are.
Working software is the primary measure of progress. There is no better way to measure development progress than by showing working, quality software that provides value to the customer. Producing status reports, Gantt charts, flow diagrams, and other artifacts are all secondary (and in some cases irrelevant) compared to producing working software that we show to our stakeholders. Software that’s almost done (still not working), or completely done except for ______ (fill in the blank with your favorite excuse) is not truly “done-done”. The only accurate measure of development progress is working software.
Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. Long term agility requires motivated people that deliver high quality work, and continually improve how they do things. The longer we work together as teams, the better we come to understand our potential and our limitations. Retrospection helps us continually improve our processes and practices, and helps us become more efficient and higher performing. This better understanding of ourselves and our teams, and these continual improvements tend to help us increase our sprint-to-sprint velocity over time… to a point. We want to eventually reach a point where we are delivering our commitments consistently, we are delivering high quality results, and we’re not killing ourselves in the process. Yes, there are occasions when we need to put in the extra time to get that last user story to “done-done”, but working extended hours shouldn’t be the norm. Excessively long hours for weeks or months at a time takes a toll on us, and often results in lower quality output and less motivated teams. Reaching and maintaining a good, sustainable pace promotes healthier team dynamics, higher quality code, and higher quality of life for us as team members.
Continuous attention to technical excellence and good design enhances agility. We all want to be proud of our code and the products we develop. Common myths about Agile development are that it is “cowboy coding” – shooting from the hip, it has little or no planning, it delivers fast but without regard for quality. Nothing could be further from the truth! The Agile values and principles promote effective planning and high quality that starts with good design and technical excellence. It's much easier to understand and maintain high-quality code than it is to work with poorly designed, poorly written code. Start with agreed-upon coding standards, adopt tools and processes that will foster good design/development such as Test-Driven Development, pair programming, frequent refactoring, continuous integration and collective code ownership.
Ensure that your product gets better with each iteration by writing code that you are proud of in every detail. Technical excellence is the responsibility of the entire team. Cultivate in yourself an attitude of life-long learning to acquire new knowledge and improve your skills, then apply that knowledge to your design and code delivery.
Simplicity – the art of maximizing the amount of work not done – is essential. Agile started out as a very simple concept. The authors of the Agile Manifesto came up with 4 values and 12 supporting Agile principles. Similarly, Scrum has a few roles, artifacts and ceremonies. The wealth of other Agile information you’ll find out there is an attempt to improve on the Agile philosophy. Some of those ideas are great additions and some just complicate the simple concept of Agile.
Agile teams focus on high value activities. We endeavor to maximize our stakeholder's return on investment. This mindset is not just about productivity; it’s also about simplicity – about “maximizing the amount of work not done”. We avoid doing things that don't matter, and we either simplify or automate mundane effort wherever we can. We determine what really needs to get done, and we remove non-value-adding activities. One example of maximizing the amount of work not done is the Lean UX technique “Feature Fake”. For example, to quickly test the viability of a potential feature without spending a lot of time and money, put a link or button for the feature on a page, that, when clicked, displays “This feature may be available soon… how likely would you be to use it? – Unlikely, Maybe, Likely”. Leave it there for a few days, then use the insights gathered to determine if you should build it.
Agile Developers also create a simple design. Having to reverse-engineer someone else’s code can be a complicated effort. Complexity hinders passion and slows progress. Keep it simple, focus on high value activities and maximize the amount of work not done.
The best architectures, requirements, and designs emerge from self-organizing teams. But what does “self-organizing” really mean? Does it mean that Agile teams are totally autonomous and can do whatever they want? No; it’s a mindset or team trait – an attitude of figuring things out, creating appropriate approaches and adapting to meet the challenges that arise in their environment. Management and other leaders associated with an Agile team help create an environment that fosters self-organizing teams, but they avoid controlling team behavior. In “The New-New Product Development Game”, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.” Mike Cohn adds, “Self-organizing is about the team determining how they will respond to their environment (and managers can influence that environment)”.
Agile teams don't wait around to be told what to do, or who does what. An Agile team’s job is to continually self-organize around the challenges, and within the boundaries and constraints put in place by management. Esther Derby states, “There’s a reason we use the term ‘self-organizing’ rather than ‘self-organized’ or ‘self-managed’. That’s because it’s a process and a characteristic, not something that is done once and for all.” Mature, long-standing Agile teams may evolve to the point when they themselves have more influence over their environment due to proven success, but there will always be constraints to work within. Great Agile teams use their self-organizing characteristic to adapt to constraints and challenges within their environment to deliver and perform well, and then continue to improve.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. A pillar of the Agile mindset is inspection and adaptation. This applies not only to the software we’re developing, but also to how we go about developing that software and working as a team. The Sprint Retrospective is one way we inspect and adapt. Each sprint, we look for ways to improve processes, simplify how we do things, increase code quality, work better together and improve the predictability of our results. We bring up issues and look for root causes and their solutions, and we celebrate what went well so we don’t lose sight of what has helped us succeed. Too often, though, a team will suspend conducting a Retrospective due to time constraints; similar to why we often forego software documentation – it is seen as a low priority compared to moving on to the next big thing. However, you can only have continual improvement when you pause to reflect on what’s working or not working, then make a conscious decision to adjust things. Little tweaks here and there can make the difference between success and failure.
Even the highest performing teams will find ways to improve. Every Super Bowl and World Cup winning team watches the game tape after they’ve won the championship to find areas to improve next season. Action without reflection leads to burnout, and reflection without action leads to cynicism. Conduct a Retrospective after every sprint, and then actually implement the valuable changes that come out of it. Agile is all about continual improvement, and with regular Retrospectives, improvement is never very far away.
So, even though the practices of Scrum, Kanban, and other Agile frameworks are important, practices alone can still lead to failure. The Agile values and principles, however difficult to incorporate, are what lead to more sustainable agility and improved software development outcomes.
So, what are your thoughts on Agile and do you think that the Agile values and principles will help with the overall software development process?