The Agile Manifesto for Software Development was first released into the world in 2001, 18 years ago, and anyone that has either dabbled or professionally pursued Agile Development is familiar with this doctrine.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
For the full manifesto click here.
The benefits that Agile boasts about certainly give us all warm and fuzzies. Decreased time-to-market, happy stakeholders, visibility, feedback, collaboration, etc. So why do projects that adopt Agile methodologies still sometimes turn out unsuccessful? What causes us to take a perfectly sound theoretical concept and fail to deliver? It’s important to note that while there is a high percentage (you can Google that, I believe in you) of IT projects that fail, using both traditional and agile methodologies, the benefit with Agile is identifying failure quickly and remediating for success. In this blog post we will address some of the common causes of Agile project failure and we will revisit the fundamentals of Agile to help put us back on a path towards success.
Albert Einstein once said, “Learn from yesterday, live for today, hope for tomorrow...the important thing is not to stop questioning”. Consider this statement and how it applies to failure and Agile, the only way to improve is to inspect and adapt. We must continuously assess our failures and document our successes if we ever hope to reach a desired state of perfection. This is true for almost every aspect of our lives, but for today, specifically, our Agile practices. After all, if we are not constantly seeking to improve and optimize, are we even truly Agile?
Let’s first assume your organization has already fully adopted and continuously supports Agile frameworks. This means that every project has management support for Agile implementation and your organization has already undergone an Agile transformation. We could spend an entire blog discussing why change management is the core of Agile projects failing within your organization and we’ve beat that horse dead lately. Instead, we will focus on other aspects of Agile project implementation that may be causing an issue in your team’s delivery.
Velocity > Value
Velocity is important to the agile process, it tells us how much work our team completed in one sprint or iteration. Velocity is something that is continuously monitored by Stakeholders, Product Owners, and Scrum Masters to ensure that project deadlines, sprint goals, and necessary objectives are being met. As iterations are completed and the team begins to sync and settle, velocity is expected to increase. Accurately noting a team’s velocity will also help the team properly estimate iterations or sprints moving forward.
Sounds swell right? Sure, but consider this - is velocity truly value? Maybe, but not always. How do we measure value? After all, according to the founding principles of Agile the goal is to deliver business value often and iteratively. So what happens when that doesn’t necessarily align with velocity? In other words, the number of items completed in a sprint may not directly correlate to true value for Stakeholders. Story points for estimation often correlate to complexity, but complexity does not often equate to business value. Do you see where this is headed? If success equals value, not velocity, why do we spend so much time focused on velocity? Additionally, how can we properly measure business value?
A reason that Agile products often derail, or even fail, is because value is not being demonstrated to the Product Owner or Stakeholder early enough in the process. Soon budgets get cut and funding is dropped because management doesn’t see the need in proceeding. They aren't getting what they feel is fair value for compensation. It is important to note that Velocity should continue to be tracked for project success. However, Agile teams should also discuss and understand the value of the stories they are trying to deliver. If the option is 21 story points with minimal value or 8 story points with maximum value the team should choose the 8 story points.
Measuring value is a difficult practice and is not always straightforward, however, the benefits of value driven sprints or increments is insurmountable to success. Remember complexity does not equate to value and velocity does not equate to success! Change your perspective that high velocity equals success and begin to understand the value of what your Agile team is producing.
Requirements? We don’t need those...it’s Agile
I’ve lost count of how many times I’ve heard that we don’t need defined requirements for our project because it is Agile. After I cringe a little, take a deep breath, and re-center I try to explain how Agile actually works...and how it’s actually successful when there are requirements. How is a team expected to deliver value, and therefore success, if they have not determined what it is they are building? Agile implementation does not mean chaos, uncertainty, or a lack of planning. Please read that last sentence again.
As a Scrum Master, this is one of the biggest issues I have faced in software development. The notion of “we’ll figure it out as we go” is not equivalent to Agile success. User stories, user acceptance tests, workflows, detailed requirements, success criteria, and wireframes are all part of an Agile implementation. Without any one of these requirements begin to lose value and project success begins to deteriorate. Despite common myth, planning and structure are essential to Agile, it is why we estimate, sprint plan, and prioritize stories based on complexity and value.
We are flexible. Just not right now
Guilty as charged! Of course I don’t want to add your feedback to my in progress sprint. That will affect my team’s burndown and it will definitely ruin everything ... or will everything be just fine? Everything will be just fine. Promise. No really, I promise. Hear me out. Feedback is absolutely critical to Agile development, right? If it wasn’t our development teams would just go sit in a room for 8 - 12 months and then deliver the wrong thing. It’s why we switch from SDLC models, such as waterfall, to Agile in the first place. Early and often feedback helps us ensure that we are delivering precisely what our clients need, adding value (there’s that word again) in all the right places. So if your Product Owner approaches you midsprint and says I took a look at development so far and I really feel like if we add feature x into this sprint it will make a huge difference. Don’t panic! As much as you want to, don’t panic! Have a healthy discussion with your team. If we add feature x can we take out feature y? If we need both, what does this mean for the sprint. You don’t have to always say yes to modifying your sprint, but you should always say yes to having the conversation. Be flexible enough to adopt early feedback, or consider being proactive and building a little wiggle room into your sprints as development progresses to allow for mission critical feedback. After all, if we practice what we preach as Agile Coaches, the Agile Manifesto tells us we should respond to change over following a plan.
Small Manageable Chunks
Another area that could be causing detriment to your project could be your work items, sure you’ve got them documented in your backlog, but at what level? Your work items should be small enough to deliver quick value to your customer and gather valuable and consistent feedback from stakeholders. Working larger items, or features, for a month instead of smaller items over weeks enables a loss of value. Be sure to take the time you need to sit down with your development team and break items down into smaller tasks, it’s worth the time in the long run and will show so much more value and delivery for your stakeholders. Afterall, value is more important than velocity but we still love those velocity charts and burn down graphs!
Team Dynamic
So let’s talk about your team, developers, project managers, stakeholders, product owners, tech leads, sponsors, the whole squad. They’re great right, theoretically your team is one well oiled machine, working together to deliver nothing but success. A perfect world! However, there is this other world called reality, where we actually live and things are never that perfect. So let’s break this down into smaller more manageable chunks (see what I did there?).
Product Owners
I can testify that I have never, I mean it, never, worked on a project with a real dedicated Product Owner. I’ve experienced Product Owners that were volunteered for the position, and therefore were either checked out or had no idea how to perform the duty at hand. I’ve had Product Owners that were too busy with other high priority obligations to focus on my project, and best of all projects where there was absolutely no appointed Product Owner, because either there wasn’t anyone available or they didn’t feel the role was necessary. I’m not going to sit here and preach to you about the obligations and responsibilities of a Product Owner, there are plenty of ways for you to find that information on your own. What I will tell you is that an ideal Product Owner understands business needs and product vision. They have technical and domain expertise and are user focused. They must exist and more importantly, they must be engaged. Always, always advocate for an engaged, knowledgeable Product Owner.
If you are blessed with a disengaged Product Owner, there are a couple things you can try. Try coaching your Product Owner. Work alongside them and give them guidance on what their role is on the team. Often times Product Owners are disengaged because they simply do not know or have not been made aware of how they are supposed to be engaged. If that doesn’t work, step up. Don’t be afraid to take over the responsibilities of a lackadaisical Product Owner, just be sure to keep things as transparent as possible with your entire team. Since you are not the domain expert for your client be sure reach out and gather intel from as many people as you can to cover the role.
Development Team
Oh yes, the Development team, the bread and butter, the Most Valuable Players, nothing would get done without them. So how do you, as a Scrum Master, keep your team working efficiently and effectively, all while keeping them happy? It’s tough. They juggle code, test cases, multiple environments, business meetings, sprint planning, retrospectives and much, much more. As a Scrum Master you must empower your team to work and pace as they see fit. Afterall they know these requirements, and they know what it’ll take to build an item, test, and release - so why not listen to them. The worst thing you can do for your team is hyperfocus on burndown and begin to micro-manage. Trust your team. Communicate with them early and often. Let them run their show, self-organize and set their pace. They participate in planning, so allow them to take ownership of their work commitments.
However, Development teams are not all perfect, we’re human, they’re human. Developers have good days and bad days just like everyone else, they don’t always get along, or find it necessary to communicate often, most times they just want to sit and work. In any software development model, Agile or any other, there is a large human aspect of failure that we often forget about. We sometimes fail to look beyond the process and as a result, fail to proactively manage the people producing the work. There are certain things pertaining to Agile that you should look out for with your Development team. Are they giving honest and thorough status updates during the daily standup? Are they communicating impediments early and often? Do they ask for help when they need it? Do they pull in additional stories if they finish up early? Do they feel resentment amongst other members of the team that may not appear to be working as hard as they may be? These are tough questions that every Development team has to face, and they often lead to tough conversations. In order to be successful, the human side of your Development team needs to be carefully facilitated, but it all goes back to empowerment and support. Have the tough conversations, support your team, and make sure that you are giving them what they need to trust you as their Scrum Master.
Scrum Master
Yup, you too. None of us are perfect. You know your role on this team, you provide support, empowerment, block interruptions and remove impediments. It is your job to ensure that the pace of your development team is sustainable and your team isn’t burning out at the end of each sprint. The last thing you want your Development team doing is spending the last 48 hours of a sprint, tiger teaming in a conference room, where you’re buying dinner for them, work items aren’t tested or reviewed, code quality is decreased and everyone begins to pick and fight. That is not sustainable for any single person in that room and certainly does not provide any value to your Stakeholders. As a Scrum Master, be mindful, a happy team is a productive team. Commit to reasonable deadlines and be transparent, use your daily standups to gauge velocity and when feedback is received, accept it.
Encourage your Development team to work together and ask for help, as a Scrum Master, you are the cheerleader for your team. Provide encouragement, give them purpose, make sure they understand the value of their work and what it is providing the Stakeholders. Otherwise you may end up with silent, resentful developers, missed deadlines, and ultimately a failed project (I know that escalated quickly)!
Ceremonies
Sprint Planning, Retrospectives, Sprint Reviews, Daily Standups these are all useful ceremonies for a successful Agile project. So why do we start getting comfortable and start slacking? First they get rescheduled and then they become less frequent and before you know it they are dropped all together. Remember the fundamentals: Feedback, Communication, Transparency. In order to be successful, we must inspect and adapt. The moment your team starts telling you they’d like to skip a Retrospective because “everything is fine” and they’d rather “spend those hours on development” your project has begun to fail. Everything is not fine if your Development team feels like they need more hours to finish a planned sprint. Everything is not fine if you are not optimizing after each sprint. It is highly unlikely that your team has zero improvements to make.
The same can be said for all the other ceremonies, take the time to commit to the process. It works for a reason. It’s not necessary to meet for several hours on end to optimize. Make your meetings efficient, get what you need, and move on.
Tools
The last area we will cover in this (already too long) blog are tools. This may be the easiest thing for your team to modify for success. Often times your tools are failing you. You are likely overcomplicating your process with time-consuming tools that may not fit the needs of your project size and team structure. Don’t be afraid to say goodbye to something that isn’t serving your team effectively. Afterall, the Manifesto states we should place individuals and interactions over processes and tools. Find a toolset that is fit for use don’t use Jira just because it’s there.
Certainly this is not everything that causes a project to fail, these are just some simple reminders that we all, as Scrum Masters, have heard and been trained to be cognisant of during project implementation. Add the real world, pressure, stress, budgets, deadlines, and staffing and things get hectic quickly. Just remember to take a deep breath, lean on your training and your experience, and never be afraid to reach for your fundamentals in Agile. When things begin to feel a little off the rails use the manifesto, print it, place it somewhere your team can see it. Remind yourself of the fundamentals of Agile. Feedback, Communication, Transparency, Trust
