The good folks at Scaled Agile, the SAFe® community, Agile agnostics, consultants, and some in the “Agile” community are onto something incredibly important in defining the elusive and dynamic Agile End Game for organizations. Read the rest of this entry »
S_Fe is not Agile. S_Fe is not even Scrum. – Mike Beedle
In response to Mike Beedle on LinkedIn. Mike is wrong about the SAFe of course. And not just because of his childish method of attack. Facts, evidence, experiments, my experience and dozens of business case studies back up the experiments of the SAFe. Mike sounds a lot like project managers that swear the PMBoK/waterfall works better than agile for large scale “projects” with high complexity, significant uncertainty, many dependencies and new knowledge to be obtained to deliver the product. Project management works in those scenarios (fantasy). But not as well as Agile (reality). Read the studies (Chaos Report, Standish Group; State of Agile, VersionOne; others). A sea change is in play — right now. Customers want predictability, results — and truth. Not endless “Change Requests” and contract modifications for more time, more money and more people. One truth about the Agile Manifesto is that it is great guidance as a value system and principles for software development. The big problem is that it [Agile Manifesto] is STATIC. Relentless improvement drives us to go beyond yesterday. Study the Scaled Agile Framework for the enterprise and come to your own conclusions. Evolve or join the museum with the other artifacts of the information age.
Studying up on Lippitt / Knoster change models I learned about from Construx videos. Steve McConnell of course being one of the greatest software development thought leaders is the presenter. Interesting how these change theories are baked into some of the Agile frameworks and mindsets like the SAFe / Agile Manifesto. As a coach, these are useful strategies on how to build our approach to managing change (like fear, unknowns, budgeting/money, et cetera).
Get a Grip on Managing Change – Michael Nanfito
Agile Transformations – Change Model – Construx
Aside Posted on
Focus on family with an Agile mindset and Scrum.
I read a parenting article a few months ago about family dinner table discussions with your kids. It was great stuff. The recommendations centered around three questions. 1. What was the favorite part of your day? 2. What was the least favorite part of your day? 3. Is there anything else that you want to talk about? Amazingly, just like in the Scrum ceremony these questions generate amazing discussion (collaboration) with the family. My three children have become accustomed to the ceremony now. So, it is even more fun playing the experience through. Anything that I can do to bring my family closer together as a unit is premium! Sound familiar?
Try it out and report your findings here on my blog or at Microsoft LinkedTwo.
An epic in agile Scrum terminology is a group of related user stories or may appear as a “big” story. Epics generally cover an entire use case or work flow for a feature related to user interaction with a system in software development. Epics are completed when all the associated stories implementing the epic are done-done. While stories may be completed and delivered independently, epics are only complete when all stories are verified done.
(see also: Agile Moment: Equating Story Points to Time, Scrum Effort Estimation, Practical Guide Story Points Estimation, How Story Points relate to hours, Story Points vs. Task Hours, Planning Poker)
Estimating story points for user stories that implement features on the Scrum teams product roadmap or product backlog is a critical planning exercise. All Scrum teams should utilize planning methods to estimate engineering efforts for future work. There are many possible methods available to estimate effort. However, for teams that are using agile methods like Scrum, a proven, highly effective method of choice is Planning Poker. The overall goal of planning poker is to establish a clear consensus on an estimate for a given scope of work or user story.