Scrum recommends timeboxing daily standup meetings at 15 minutes. If you can’t finish in 15 minutes, there may be something wrong with your format. Are you actually standing up? What are you talking about? Each person should answer three questions: What have you accomplished since the last meeting? What do you plan to accomplish between now and the next meeting? What, if anything, is impeding your progress? Focus on accomplishments, not just assigned tasks, i.e., don’t say “I’m working on A and I’m planning to work on B.” Don’t have discussions. Anything coming out at the meeting that needs to be discussed can be discussed after the meeting. Try saying this more often: Let’s talk about that after the meeting. Immediately after the meeting if necessary, without even leaving the room, but not during the meeting. Anyone in the meeting who is not responsible for accomplishing things during the sprint… Read more →
EppsNet Archive: Scrum
All Projects Should Be Early
From a Jeff Sutherland Scrum deck: You can maximize the value delivered per unit of time or cost by shipping when the value curve starts to flatten out. Read more →
It’s a Seller’s Job Market in IT Right Now, Especially for Agile
I recently concluded a 3-month job search. As part of my networking, I met a number of unemployed people in other fields who were having trouble not only getting jobs, but even getting interviews. I talked to a lot of people and averaged about an interview a day, including phone interviews, mostly for development manager jobs. For every development manager job, there are multiple development jobs, so if you’re a developer, your situation is even better than mine was. I live in Southern California, but the demand is not just local. I had multiple contacts from companies outside the SoCal area that can’t find qualified candidates. I’ve been working again for over two months, I no longer have an active résumé on job boards, and I still get emails and calls every day from recruiters all over the country. Agile and Scrum are in demand The situation with Agile and… Read more →
Customer Discovery and Customer Validation
Ask yourself these questions: Do these users in your user stories exist and have you ever spoken to them? How are these features helping your customers achieve their goals? Are these benefits based on any quantitative or qualitative data? — The Product Owner’s Dilemma | Scrumology Read more →
Aside
Jeff Sutherland: Scrum: Why Story Points Are Better Than Hours
The Essence of Scrum
Good short article by Tobias Mayer on the principles of empiricism, emergence and self-organization, and the mechanisms of prioritization and timeboxing. Read more →
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 →
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 →
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 →
Adventures in Agile: The Scrum Board
For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done. Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?” Ummm, I could, but it wouldn’t contain any additional information than what’s on the board. That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task. It never occurred to me that if you record information on Post-Its and stick them… Read more →
Why Would You Use Agile for Offshore Development?
More of my customers have been asking me how to use agile processes, particularly Scrum, to help them manage offshore development. Since offshore development undercuts many of the practices that promote agile productivity, I ask them why they don’t just increase the productivity of their teams by thoroughly introducing agility? It seems that offshore development, with its potential for lower unit costs (dollars per programmer day), offers management hope that their losses can be reduced. Since the project is probably going to fail anyway, let’s minimize our losses by lowering our investment by using lower priced resources. A more optimistic, agile, way of looking at this problem is to fix the problem at home and increase the probability of success. — Ken Schwaber Read more →
Essence of Lean
From Alan Shalloway: Essence of Lean for People Doing Scrum Lots of concurrent tasks cause waste Focusing on removing delays will remove waste Adding value and getting feedback quickly is important If you make a mistake and don’t attend to why you made the mistake, it will likely repeat itself Minimizing work in process (WIP) is a way of improving efficiency and minimizing risk Read more →
Scrum Doesn’t Do Anything
In the end it doesn’t matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. . . . Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That’s about it. But that is huge. — Tobias Mayer Read more →
Scrum Cheat Sheet
Read this doc on Scribd: Scrum Cheat Sheet Read more →
Waterfall: The USSR of Software
Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy. — Ken Schwaber Read more →
The Customer is NOT Always Right
Great sequence of posts on the scrumdevelopment Yahoo group . . . Person A says the number one rule of business is that the customer is always right. Person B says the customer is NOT always right, like his customer who wants an auction system like eBay on a budget of $1,500. Person A says Person B needs to shut up and listen to the customer. Person B says I AM listening. They want something like Ebay for $1500. They want me to build a full Ebay clone this weekend and then tweak it until they’re happy over the next two weeks. I have listened carefully and diligently and have confirmed multiple times. This is definitely what they want. They’d also like time travel, but they don’t need that until April. The point I’m making is that there are many reasons why just listening to your customer and giving them… Read more →
How Long Should it Take to Define a Project?
Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition. To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million. At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority. This reminded me a lot of an article I read a few days ago: What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher… Read more →