It’s not uncommon to falter when trying something new, in fact, being a father of a six year old son who wants to be instantly great at everything, I find myself often giving advice that the key ingredient to success in just about anything is simply lots of practice. Ask any cyclist who has done a century ride to tell you how they did it and they will probably reply “Time in the Saddle!”. The same goes for any fantastic golfer, runner, or gymnast (you get the idea).
That being said, it is also true that when trying some things it is tough to understand whether you are not seeing the results you want to because you have mis-applied the art and science of the process, or because the process is just fundamentally flawed and should be discarded for another. What further complicates things is if you have no faith that the process you are attempting to apply SHOULD work.
I led my first Agile project circa 2009. I made some of these mistakes and have seen many other teams make them since. If you are having doubts about your success and truly want to turn things around I hope this offers some help.
1. You aren’t interacting with the business
Agile introduces an opportunity and framework for your team to partner with the business stakeholders more so than any other method of project delivery ever conceived. Rather than taking on an adversarial approach that discourages and punishes change, Agile projects are formed around the acknowledgement that change is inevitable and welcome it into the process. Are you exploiting this to your advantage to create an environment of trust, collaboration and success with the cooperation of your customers?
Are you getting up out of your chair and seeking those breakthrough moments that only come when you work through problems, get validation, and find solutions together or are you building on assumptions? Is your team is being ‘shielded’ from the business? Have you have established an IT product owner that ‘proxies’ the business? If so, watch out, you’re probably not building the right thing and you certainly aren’t building trust.
A representative of the business should be accessible and available. They should be in a position where they are set up to learn from the team and influence change just as much as the team can learn from them. Building a product for someone else is collaborative.
Eric Ries emphatically shouts in his book The Lean Startup, “get out of the office!” in order to encourage teams to get feedback and collaborate with their market so they can build the right product. This applies to you to. Remove all obstacles that keep you from having direct contact with your customer.
2. Your Scrum Masters have no backbone
Do your Scrum Masters exhibit the following behaviors?
- Allowing portions of the product backlog to go un-estimated.
- Letting the team go early on planning day (when planning is still incomplete).
- Allowing the team to pass off a story as complete in order to claim points when you know it doesn’t meet the team’s definition of done.
- Allowing your product owner to shirk the responsibility of acceptance or approval of ‘done’ user stories.
- Not requiring stories to be decomposed into tasks on planning day.
- Not doing retrospectives at all or taking them seriously as a process for improving the team.
- Allowing team members to have tasks in progress for an extended time before aggressively getting involved in removing their blocks or finding them help.
Let’s get one thing straight, the Scrum Master does not show up to work to be everyone’s best friend. If you are in the role of a Scrum Master you will inevitably find yourself making decisions that are impossible to build complete team consensus around. The outcome is that someone will be mad and that’s ok. In fact, if you aren’t occasionally making someone upset then you probably are in the no backbone category.
You set the pace for your team and if you are lackadaisical about enforcing rigor and discipline to the process, then this will be echoed in your team’s behavior.
3. You’re lying (to your team, your product owner and yourself)
Before Odysseus reached the island of Sirens he told his men to lash himself to the mast of his ship and to put wax in their own ears. Why? He knew he would be tempted by the seductive song of the Sirens and didn’t trust his future self to endure the temptation that had fatally ensnared less prepared sailors. As a Scrum Master, walk into the project knowing that you will be tempted and establish firm guards against that temptation.
The most common temptation that I’ve seen leaders succumb to simply boils down to lying. When the team is under the gun, and not showing much progress it can be incredibly seductive to pass something incomplete off as done in order to ‘claim the points’ that will positively influence the team’s velocity metrics. Often the team might file a bug in the product backlog to compensate, but to see this for what it is, you have to recognize that you (and your team) are representing knowingly representing something incomplete as finished and taking credit for something that you shouldn’t.
Lying inevitably leads to more lying to maintain the cover up, and bugs get filed. All of the sudden you are piling on technical debt. This false progress will erode into the team’s real progress to the point where you lose all trust between the team and the product owner. Establish guards against this by clearly communicating this scenario and how to recognize and avoid it to each of your team members. Have teams write up a clear and unambiguous “Definition of Done” before the project even starts and let them help you defend against this Siren.
4. Your deliverables have no business value
User stories should be focused on testable outcomes that are meaningful to users. A team that completes stories which don’t have these qualities will frustrate business stakeholders and train them to see markers of team progress like velocity as arbitrary and meaningless. Eventually they will ignore the team altogether or start questioning whether the project is producing anything at all.
What does this look like in practice? Often this looks like a story that either has no quantifiable output, or a story whose outcome represents an ‘intermediate work product’. An intermediate work product is something that is necessary to produce the ultimate deliverable, but in and of itself provides no direct business value. Things that fit into this category include design or architecture documentation, frameworks or infrastructure code, or back-end development that an end user cannot see or make sense of.
Most of the time, work on these sorts of things is better represented as tasks required to complete a story or in the team’s Definition of Done. You can avoid this by building your product in “slices” instead of “layers”.
Let’s get something straight about this though. This is generally unintuitive for most of us. This goes against the intuition of just about every developer / designer I have ever known (including myself at first). There is a pervasive idea ingrained in all of our heads that you must know the design and relationship of ALL parts of the system before you can do meaningful implementation work on ANY part. This is reinforced when we watch more concrete things than software being built. Things like airplanes, houses, ships, and drilling rigs can’t be built one room or compartment at a time or their structural integrity would suffer. You will do well to recognize that software is different, and in fact well engineered software thrives on the balance of cohesion and coupling and generally weathers building a feature at a time well.
Beyond the nature of software constructing being different though, what we are ultimately after when taking this approach is not raw efficiency but faster feedback and validation loops. We will put working software in front of our users more often in order to learn from their reactions and tune the results. You simply can’t do this if you build the system layer by layer instead of slice by slice.
I have heard many arguments that paint Agile project methods as creating inefficiencies. Most of these focus on the inevitable rework that results from developing cross-cutting concerns in a piecemeal fashion. What I’m about to say next will shock some of you. Most of these arguments are valid. That’s right… Your team will revisit and refactor parts of the product that you have already implemented if you build in slices rather than layers.
Assuming we are comparing this to an alternative method which is perfectly efficient yet never refactors and adjusts using customer validation, Agile still wins in macro efficiency. Why? Agile doesn’t focus on building the planned product with maximum efficiency, it focuses on building the right product efficiently enough.
I will always trade a perfectly efficient system that produces misaligned outcomes most of the time for one that is inefficient yet reliably produces well aligned outcomes.
5. You don’t know what you’re building
The odds are, from what I’ve observed that your product backlog is an absolute mess. Your stories contain duplicated and overlapping ideas, they aren’t organized into themes or epics, and they aren’t ordered in terms of business priority. Stories aren’t estimated so you’re not tracking empirical data and you can’t possibly project what’s left to do and when you’ll be done.
Remember that a healthy backlog is the cornerstone of your success as a team. It forms the backbone of what is in and out of scope, it will be the basis of any and all disagreements you have with your customer and defines when the project is done. Neglect in this area will bite you back ten fold in EVERY other area of your project. Allocate someone (at least one person) to a full time role of managing, grooming and perfecting the backlog.
The payoff for doing this is immense. Considering that the project plan in its simplest form is team velocity combined with the backlog, simply maintaining the backlog affords your team a well defined scope, estimate, and plan all in one.
6. Your team is just a bunch of individuals
One of the companies I worked for had a motto that I really liked and eventually committed to memory. Simultaneously goofy, and pithy, it was: “None of us is as smart as all of us“. I liked it because it clearly assigned value to working as a group and discouraged the hero mentality.
Although I’ve never seen the perfectly cross-functional team where everyone has interchangeable skillsets, a little effort in this category goes a long way. Are your team members focused on individual specialization instead of doing what it takes to create a great work product? Do you have boundaries that make it uncomfortable or penalizing for team members to step out of their practice area or discipline? You’d be surprised at how much productivity this might be costing you.
Encourage team members to assist other teammates in completing higher priority stories before moving on to start work on lower priority stories. What you’ll find is that you can concentrate your team’s horsepower and complete consistent quantities of work at a high quality as opposed to quasi-completion of large quantities of work at a low quality. For more information research “limited WIP”.
I like big low-tech information radiators as aids to help with this. Things like physical Scrum boards and Kanban boards have a unique ability to very publically highlight opportunities to pitch in and help other team mates for the greater goal of delivering product.
7. You are expecting failure
As much as I hate that this sounds like I’m encouraging you to develop a religion around Agile, you have to believe in the process. If you don’t, you will be weak in your enforcement of its principles, you will lack the discipline to implement the process properly and ultimately your attitude of failure will be self fulfilling.
Expect success! This will require getting out of your comfort zone, getting training, seeking enrichment from many great sources, and yes, drinking the Kool Ade.
The software and technology world is full of very smart people who are used to thinking for themselves. There are plenty of people in the field who have a career history of seeing things in a unique way and solving problems that others have failed to solve. Avoid the temptation to re-engineer whatever Agile method your team is employing before you have tried best practices first. Definitely approach the problem of optimizing your team’s use of the method, but not without a great deal of humility. Remember that team and people dynamics are probably a different kind of engineering than the one you are degreed or certified in. Endeavor to understand why a ceremony or practice is suggested before you discard it.
aaron murrell 