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
Agile Transformations and ROI
This question was asked recently on a social network Scrum group. I thought that it was very relevant and also a common request from executives that desire an evaluation of ROI for agile transformations. However, it is important to consider both efficiency and the effectiveness of your agile transformation. Read the rest of this entry »
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.
Remote teams and agile frameworks
In this article I cover various strategies and methods for effectively implementing and using agile Scrum and Kanban for globally remote teams (virtual workforces, telecommuters). I will also attempt to debunk the myth that Scrum may not be used for remote teams.
(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.