- Click to share on X (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
- Click to share on Mastodon (Opens in new window)
- Click to share on Facebook (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on LinkedIn (Opens in new window)
- Click to email a link to a friend (Opens in new window)
- Click to print (Opens in new window)
EppsNet Archive: Software Development
How’s That WBS Working for You?
Michael James posted this annotated job listing in the Scrum group on Yahoo . . . [Redacted] is looking for a dedicated and experienced application developer [blah blah blah] to ensure delivery of high quality artifacts, to adhere and to follow [Redacted]’s SDLC. This is an excellent opportunity [blah blah blah] well-known Fortune 50 company. Tasks and responsibilities [clip] Provide accurate and timely estimates (work breakdown schedules) Must have proven ability to provide project estimates and work-breakdown schedules And you know these guys are getting great results from their precise WBS and SDLC because of these lines: Must be extremely responsive, able to work under pressure in crisis with a strong sense of urgency 24/7 on call responsibilities on a rotational basis Read more →
Software Development is Capable of Much, Much More
If there is one message I would like to communicate, whatever your job title and however your work is touched by software development, it is this: software development is capable of much, much more than it is currently delivering. — Kent Beck, Extreme Programming Explained Read more →
The Word “Requirement” is Just Plain Wrong
Software development has been steered wrong by the word “requirement,” defined in the dictionary as “something mandatory or obligatory.” The word carries a connotation of absolutism and permanence, inhibitors to embracing change. And the word “requirement” is just plain wrong. Out of one thousand pages of “requirements,” if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not “requirements”; they weren’t really mandatory or obligatory. — Kent Beck, Extreme Programming Explained Read more →
The Simplest Thing That Could Possibly Work
I ask people to think about the question, “What is the simplest thing that could possibly work?” I’m not asking you to think about what is too simple to work, just to bias your thinking toward eliminating wasted complexity. — Kent Beck, Extreme Programming Explained Read more →
Change Isn’t the Problem
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change. — Kent Beck, Extreme Programming Explained Read more →
Visibility and Feedback
Forgive my ignorance. How do increased visibility and tighter feedback loops manage and reduce risk? Get in your car. Drive to a winding road. Get up to a decent speed. Close your eyes for two minutes. Then come back and ask your question again. — Ron Jeffries, Yahoo Groups (kanbandev) Read more →
Making Work Visible
Great post on Kanban. The balloon idea is genius! http://blog.flowkaizen.com/why-physical-card-walls-are-important Read more →
Don’t Know What You Don’t Know
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you. Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their… Read more →
Agile Manifesto 2.0
I’ll share with you what I do in one of my standard presentations — I play with the class or with the audience a game called “Rewrite the Agile Manifesto (link) with your thoughts and feelings now.” Here is one of the outcomes: Beyond individuals and interactions to hyper-productive swarming jelled teams and communities of practice. Beyond working software to high-quality, well architected and well-tested user-centered software services. Beyond customer collaboration to user collaboration and user involvement. Beyond responding to change to prioritizing and optimizing for change. — Mike Beedle Read more →
Kanban, Scrum, User Stories, System Design
Scrum-ban Kanban bootstrap Elements of taskboard design A Kanban System for Software Engineering Naked Planning Explained – Kanban in the Small Kanban Development Oversimplified The new user story backlog is a map Read more →
Kanban and Scrum: Making the Most of Both
Free download courtesy of Henrik Kniberg, Mattias Skarin and InfoQ.com. The book includes: Kanban and Scrum in a nutshell Comparison of Kanban and Scrum and other Agile methods Practical examples and pitfalls Cartoons and diagrams illustrating day-to-day work Detailed case study of a Kanban implementation within a Scrum organization Read more →
A Longstanding Absurdity
Is the bad-software problem really caused by bad requirements definition, which we could fix by doing a better job up front, if only we were more diligent and more professional in our work? We have made this our primary excuse for bad software for decades. If this was really the problem, and if processes focusing on early lockdown of requirements provided the needed solution, wouldn’t we have solved this by now? A process that requires us to lock down decisions early will maximize our risk, not manage it. — Cem Kaner Read more →
Customer Engagement
You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it. — James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development Read more →
Outsourcing
Contracting hordes of itinerant trainees to write important software, and guiding them from a distant point in time and space. — Ron Jeffries Read more →
Ask “What Would the User Do?” (You Are Not the User)
We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias . . . Users don’t think like programmers. They don’t recognize the patterns and cues programmers use to work with, through, and around an interface . . . — Ask “What Would the User Do?” (You Are Not the User) Read more →
The Illusion of Control
More paperwork does not ensure greater information reliability or accuracy — it only adds to the non-value-added cost. It only seems that adding more measurement and reporting means better control. The illusion of control may partially explain an obsession with control. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →
Stand Up for Your Opinion
In areas critical to the success of the project, stand up for your opinion. When necessary, challenge senior management and negotiate project objectives or the resources needed to accomplish them. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →
Optimal Solutions
Even in situations where information is missing and changing, and when there is a great demand for speed, it is essential to identify areas where the search for optimal solutions is worthwhile. Being selective is the key. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →
Convergence
The distinctive conduct that marks successful project teams is this: They know there is a time to diverge and a time to converge. That is, in each of the project planning phases (e. g., feasibility, conceptual, definition, execution), the team first moves outward (diverge) to gather information and ideas and to generate alternatives — only then does the team move inward (converge) to focus, evaluate, and select. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →