I really should know better by now, but I still remain surprised that people in the Agile business seem to miss the fact that there is more than one agile methodology when they are claiming "You're not agile unless...".
The current subject of my angst is a blog posting (10 Signs that Your Team Isn't Really Agile). For the record, I actually do think it is a thought provoking commentary for teams that are beginning the adoption of Scrum and looking for guidance on whether they are coloring within the lines or not.
Where I take issue with the article is the fact that the author cites examples of practices and techniques that are primarily associated with Scrum and claims that if you're not following them as prescribed, you're not agile.
Well, I'm not quite ready to turn in my agile secret decoder ring just yet.
I chose to dissect this specific article because right off the bat it was a particularly egregious violation of the agile equivalency principle. Yes, I know it's a math term, just bear with my nerdiness for a moment here.
Right in the opening paragraph the author states "With all the hype in the software industry about Agile, Scrum, and so on...". Or, in formulaic terms:
Agile = Scrum (false - Scrum is an instance of agile, not a peer)
Scrum = So on (false - 'So on' is undefined)
OK. Now that I've appeased my inner math nerd, let's get to the interesting part, dissecting the 10 points raised in the article.
Important Note: It is entirely possible that I misinterpreted what the author wrote, so I'd invite you to read the original blog so you have both sides of the story.
1. Your team is not responsible for the whole story.
In the article the author discusses both the fact that Agile teams should be cross-functional and that no value is delivered to the customer until the full story is delivered. All good so far. But then the author makes the statement that although it is possible to have a successful development process without cross functional teams, it simply isn't agile.
Every agile methodology in current use has some means identified for scaling up teams. Many studies have concluded that the optimal Agile team size is somewhere between 4 and 8 members. Teams working on larger projects (especially within enterprise settings) will frequently own different parts of a single user story. As long as the teams deliver on their parts and collaborate as needed to insure the full story is delivered there is nothing un-agile about shared ownership of a story.
2. Testing is done by another team.
In the description it says "code complete is not done". Looks good so far. Next it states that if QA is another team the team isn't cross-functional. No argument here. Work that isn't tested and integrated isn't considered done. Also looks good.
But that's it. It isn't stated directly, but the implication certainly seems to be "if QA is a separate team, you're not Agile".
In checking the Agile Manifesto, I don't see a thing in there about QA has to be on the same team. Is it a good idea? Absolutely - the whole point of frequent iterations is to maximize feedback that the team can then act on to correct/improve their work. QA has pretty important feedback.
But to claim that a team isn't Agile unless QA is integrated with the team simply isn't true. It does require more investment into communication and does slow feedback loops, but it does not prevent the team from delivering working software on a frequent basis, nor does it prevent the team from adjusting priorities as needed.
3. You are not INVESTing in your user stories.
INVEST is an acronym that identifies properties of a good user story. It stands for Independent (of other stories), Negotiable (in scope to fit in a sprint), Valuable (to end user), Estimable (by team), Sized appropriately (for a sprint), Testable.
It's a good acronym. But it assumes that the team is a) working in user stories, b) those stories are expressed in INVEST form, and c) the team is good enough at generating these stories so that the team can perform useful work on them.
What if you're not working in user stories? There are any number of alternatives (use cases, requirements documents, etc) that seem to work just fine for many teams. Sadly, the author misses a golden opportunity to sell the ultimate cross-functional team solution - having the customer as part of the team itself. User stories are a record of a conversation (usually between the customer and product oriented roles). If all of the roles (dev, QA, etc.) are right there for that conversation it is less important to have a detailed record of the conversation, especially if the customer is ON the team and can re-engage in that conversation as needed.
4. Tasks are assigned to team members by a manager
Blog: "In a truly agile team, each member can pick which tasks he or she will work on next, as long as it pertains to the next most valuable user story.".
Yes, some teams do indeed work this way, assuming that the team members have a good understanding of what the "next most valuable" story is. Not all teams work this way.
Many highly agile teams trust their project and product managers to do their job and properly queue up work for the team. Why did they trust the product and project management to queue work properly? Because they were directly involved in the requirements gathering and prioritization activity as it happened and were part of the decision making process.
5.Team is told how much work to commit to
No argument here. If the team did not generate the estimates of work, they aren't valid, regardless of how much the stakeholders hope or expect to the contrary.
6. You are reporting rather than discussing your progress
There's not one but two assumptions made here about what an agile team should be doing. The article first mentions stand-ups and then goes on to claim that the questions inherent in the format are not there for the manager to keep tabs on the team, but to elicit another team members thoughts.
Stand-ups are a communication technique. The three questions mentioned in the article are a further refinement of that technique. Stand-up meetings are actually a replacement communication technique for teams that do not have a better means of communication (e.g. osmotic). The three questions mentioned in the article are a refinement of the stand-up technique to teach teams what is important to discuss in the context of the whole team.
Don't get me wrong, I am a fan of stand-up meetings, and the same question format outlined in the article. But to claim that a team isn't agile if they aren't doing both highlights a lack of recognition that there are other equally valid communication techniques.
7. Not focused on completing the most important user story
This one is too vague to dissect in detail. There is no definition on the definition of "most important" in the article, only the statement that if you don't focus on the most important task (however defined), you're not being agile.
In my experience there are many different ways to define most important - revenue, customer request, production fault, technical debt - the list goes on and on.
At any given moment you may have several "most important" tasks to choose from to work on, depending on the stakeholder perspective you are using. If your means of selecting work ignores less visible priorities (e.g. technical debt), you run the risk of making life much harder for the team as the application ages.
8. You changed to agile last year, and haven't changed a thing since
No argument here, especially considering the condition set up by the sign is a team new to agile. Teams that have been doing agile for some time may go for long periods without significant changes to their process, but adjustments to process for novice teams are critical to long term success.
9. You are not ready to release on time with an incomplete scope
Overall, I agree with the author on this issue as well. In the article the author focuses on the value of done-done story completion and proper layering of the stories so that if the team isn't done with the current layer, they can deliver the previously completed layer and still realize business value.
But consider this. Not all software projects are driving to a specific delivery date. Take the gaming software company Blizzard Inc - their long-standing policy has been to only deliver when they have reached a certain level of feature completion. There is nothing inherently un-agile about basing your release on feature completion as opposed to a specific date as long as your team is aware and managing the trade-offs this approach presents.
10. You are not getting customer feedback every sprint.
This one is a bit misleading. My expectation on reading the sign was that the importance of frequent customer feedback (e.g. every sprint) was the key. But the author's explanation focuses on whether the team incorporates feedback from the demo into the upcoming sprint. If not, you're not agile.
Regarding the assertion that you are not agile if you are not incorporating that feedback into what you are building I'm in total agreement.
I think that the point would could have been better reinforced if the explanation focused on the value of feedback from actual customers. Customer feedback is the single most important feedback loop there is. If you aren't getting direct feedback from the people (institutions, whatever) you expect to buy your product, how do you know if you are building the right thing? Don't assume that your customer research teams or marketing group are an adequate proxy for your customers - find a way to get real customers a room with the team and watch them use the software.
In closing as strange as it looks from the dissection above, I appreciate the fact that the author posted this article. Obviously we disagree considerably on what the boundaries of agile is, but without postings like his we miss the opportunity for dialog on what exactly this agile thing is that we are so passionate about is.