<sigh/> Once more with feeling! Stories are NOT a code word for "a bit of work of some sort." A story is a few sentences that describe a user of your system performing some work that they find valuable IN THE DOMAIN. The are literally stories in the dictionary sense. 1/3
Stories do not describe a computer program. Stories do not describe programmer tasks or activities. They describe your user/customer's work, not yours. "Implementing a story" means that you do whatever you need to do to help the user get their tasks completed. 2/3
The point is to focus planning on value to the customer. You figure out your work—e.g. implementation tasks—just before (minutes) you start actually implementing. These tasks are not a story, nor are they any aspect of the story. 3/3
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let's start the new year with a rant on SAFe. (Hey, low-hanging fruit 😄). SAFe is a perfectly good process, but it's in no way an Agile process. We could start with "Individuals and interactions over processes and tools." SAFE is clearly very process heavy. 1/6
That comes with too much complexity, which flies in the face of "Simplicity—the art of maximizing the amount of work not done—is essential." Then there's "Responding to change over following a plan". Planning is a big part of SAFe, and the plans are much too long range. 2/6
The whole notion of a PI is a waterfall concept with an up-front plan. I could go on. SAFe violates most of the values and principles of the Agile Manifesto. 3/6
I've seen two approaches for maintaining architectural integrity in a large system. One is the "architecture committee," which meets periodically and sits in judgment of all architectural changes. You can't make a change unless they approve. 1/4
It's a model built on distrust and the assumption of incompetence. I see no place for that in an agile organization. 2/4
Then there's the "guild" approach. The guild is made up of representatives from all the teams and one or two full-time architects. The entire guild makes architectural decisions. You go to a guild meeting to work collaboratively, not to get permission. 3/4
Sometimes, a skill is specialized enough that it doesn't make sense to fully integrate it into a team. Take Architect. You don’t need one on every team, and in fact, a single Architect for an entire product helps with coherence. The architect has two main jobs. 1/7
(1) Diffuse their knowledge out to the teams, assuring that everybody has architectural skills at whatever level makes sense for them. They teach. They work with individuals. They review the team’s work & make suggestions. 2/7
(2) They work with all the teams for a given product to assure system coherence. They say things like “this is good, but if we do it this way instead, it will work better with what team 2 is doing.” 3/7
IMO, the "Sprint" is one of Scrum's biggest flaws. Just dump it. When you're done with the current thing, metaphorically walk over to your backlog and pick the next-most-valuable thing to work on. There's a lot of waste in Scrum surrounding the packing of Sprints. 1/4
Getting rid of the Sprint gets rid of the waste. 2/4
That doesn't mean, by the way, that cadences aren't useful. Putting everything on the same cadence is not, however. 3/4
I keep hearing about people who want to track the progress of an Agile adoption. What are you going to track? Agile is about "responding to change over following a plan." Tracking towards a goal implies an up-front plan and a definite destination. 1/4
There is no destination to Agile, though. It's a process. You constantly improve. You never arrive. 2/4
The way to keep improving is with a continuous-improvement culture, which is evidenced by things like regular retrospectives that come up with concrete improvements that actually happen. That's not the only way, though. 3/4
I think it's worth distinguishing between a prototype and a mock up. The prototype is the first one. It's a test bed that engineers make changes to until they have the best results. The production versions are exact copies of the prototype. 1/4
I think of all software is a continuously evolving prototype. You never throw away prototypes. 2/4
A mock-up is not a real thing at all. It's something held together with duct tape and cardboard just to see if an Idea can work or not. You throw away mock ups. What people call "paper prototypes" are actually mock ups. 3/4