Moving to the Agile can be challenging. It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However, many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues).
What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.
What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.
 |
| When "Fragile" happens... |
Some may ask, “why do I care if Agile is not quite right”. When a form of Fragile is applied, you
will not gain the business benefits of aligning better with customer value and
the many other benefits Agile can bring. When you see that you are not gaining
the business benefits of Agile, instead of blaming Agile, look to see how you
have implemented Agile and whether you are really aligning with its values and principles.
In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article. I present several areas which can be problematic if they are not in place and you are serious about Agile. So without further ado, "You may be FrAgile if":
In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article. I present several areas which can be problematic if they are not in place and you are serious about Agile. So without further ado, "You may be FrAgile if":
- ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail. The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.
- ...you continue to have the Project Manager or Functional Manager assign the work to the Team. The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.
- ...you continue to collect your requirements upfront and lock them in for the remainder of the project. The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it.
- ...you do not want to have a healthy balance of test/QA minded folks on the team. The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.
- ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.
- You measure productivity in story points
ReplyDelete- You commit to a certain fixed number of story points per iteration for the entire project in the beginning
- Someone else (not the team) estimates the size of the user stories
- You don't have a Product Owner who is available for the team as needed
- So many more ....
Thank you Anu!
ReplyDeleteCulturally, all these apply i would think...
ReplyDeletehttp://assarconsulting.blogspot.com/2012/02/thats-not-agile.html
- Management compares story points and velocity between Scrum teams
ReplyDelete- Project Management calculates ratios such as "R&D cost (dollar spent) per story point"
- Agile facilitator defines, during release planning, that "1 week of work = 4 story points, and mandates that employees estimate stories following this guideline for tracking and comparing purposes"
- Someone (typically offshore experienced architect) made a vague estimation of the stories during (prior) release planning (which is fine), but Scrum team members don't re-evaluate them (generally they are not confident enough: "if the architect wrote it's a 6, it must be true ..." mentality)
- the Scrum team members won't go for a beer together after work
- Product Owner does not consider suggestions from the scrum team members (either won't allow them to add stories to the backlog, or will groom them in a way that all internal suggestion will remain un-done "forever")
- When the Scrum team says that the Scrum team is too big, then the Scrum team is too big. That applies to whatever the Scrum team says: Managers should listen to the Scrum teams retrospectives and help! remove_roadblocks!. Because the Scrum team knows what is best for the Scrum team.
Hi Philippe, Thanks for sharing your thoughts on what is not Agile!
ReplyDelete- The confusion between classic project management and the agile project
ReplyDelete