October 12, 2017
IT Leadership Meeting Recap: Agile in the Real World, Debunking Common Myths
Last Friday, we had the pleasure of having Elan Gibbons, CSM, CSPO, CSP, SPC and Project Manager at Sansoro Health facilitate on Agile in the Real World, Debunking Common Myths. Transforming to Agile is an incredibly hot topic in the IT community and we touched on the three myths below during our most recent IT Leadership meeting.
Myth #1: There’s no planning in Agile
Most Agile frameworks in fact require frequent planning and there are many ways to implement it. Elan discussed the five levels of planning in Agile; they are as follows:
- Product Vison: Every product you are going to develop needs a vision; this will most likely span over a year or more.
- Product Roadmap: This is used to categorize requirements, prioritize them, and determine a time table for the release date. The roadmaps should be updated every six months by the product owner.
- Release Planning: Release planning cycles can last anywhere from three to six months and are used to set a timeline of incremental releases of features to the internal customer.
- Sprint Planning: Each Sprint should begin with a two-part Sprint planning meeting; the first being a review of the product backlog, the second being the Sprint backlog. Backlog management plays a key role in planning.
- Daily Planning: Having a daily Scrum meeting is an important part of a Sprint. This will keep employees on task and your product moving forward.
Myth #2: It’s okay to have a big bang release at end
There is a significant risk involved when Agile is applied in a big bang approach. Organizations often make the mistake of implementing a big bang release and taking no further action. Agile transformation can fail because companies are stuck in what’s called “w’agile” – waterfall pretending to be Agile. They expect different results when they haven’t made the full transformation into Agile.
Myth #3: Agile is not possible in a highly regulated environment
False. Agile is possible in a highly regulated environment. What do regulators require? It’s not difficult to fulfill. The software developer should determine the specific approach and techniques to be used, and it is recommended that software validation and verification be conducted throughout the duration of the software lifecycle.
What other Agile myths do you think need to be debunked?